Summary: Is there a way to send OOB data and not get a CS response and without updating CS rejoinders and the rest?

detail:
I have a new use case I have been struggling with.

The front end is sending data to CS in real-time, from different sources.
CS receives the OOB data, parses it and either creates user facts or updates variables.
This stream will be somewhat constant.
95% of the time, the OOB does not need to trigger a CS response. 

I have been unable to figure out how to send OOB to CS and have CS not send a response and update all of the internal variables, like the current and pending rejoinder and the rest.

The OOB would be processed and the rejoinder would not be changed and the current and previous topics would not be changed. 

I am hoping there is a simple solution to this, if someone knows. Usually when I get stumped, I give it a few days and I usually recall how to do something, but in this case, I am stuck.

Any advice would be appreciated.

here is a simple example, all send CS replies:

u: ( \[ ping \]) 

u: ( \[ ping \])  ^setRejoinder(input $lastrejoinder)
u: ( \[ ping \]) Pong nofail(TOPIC ^respond ($lastrejoinder))

for your first 2 examples, It’s not the rule that sends the reply, its the control script detecting nothing has been said and putting out something as a last ditch, i presume

CS can certainly “return” a null message if that’s what you want and script for.  For your ping i would do:
u: (\[ ping \]) ^end(INPUT)

Though nominally I would expect ping to return a real message that the system checked to confirm communication worked.

As for not updating rejoinders.  The ping answer can come from postprcessing.  Ping at my company uses a specific username so it does not impact any real users.  Otherwise you may have to set a variable on postprocessing to current rejoinder and restore it on next input (after ping may have interfered)

OK. I reworked it and this is how I implemented it.  I will test it this weekend. I tried it with a basic test and it worked.

In preprocessing, I am doing this:

#  Check if the rejoinder needs to be reset to last rejoinder
u: ( $fixlastrejoinder ) $fixlastrejoinder = null   ^setrejoinder(input $lastrejoinder)

#  Look for a special incoming string, process the JSON, set flag to fix the rejoinder, and end input
u: OOBDATA ( some specific string _*  ) 
some code to intepret the incoming jason _* here
[ ack to the avatar,  transmission accepted ] 
$currentlocation = “kitchen” 
$fixlastrejoinder = 1  
^end(INPUT)

In post-processing, I am doing this.

# save off last rejoinder if I need it later.
t: ( * ) $lastrejoinder = %inputrejoinder

Thank you for your help!!!!!

as a minor pointer t: (*) == t: ()  since you are not memorizing the wildcard

more importantly: ( some specific string _*  )  where you talk about having json string to interpret out of the *.
Ideally JSON comes in as the first thing in the input because then it is automatically converted by CS into json structure. This auto conversion is important (if you turned on auto convert) because CS limits a sentence to 254 words which for complex json means it may get broken apart. autoconversion bypasses this and can handle any size json.

Ah, so this notation puts the sentence into a pointer or something, so it can be used?
t: (*) == t: ( _0)  ?

Does t: (*) adds to the memory footprint at run time? It is probably really small.

I cannot think of a reason why I would want to use this notation. I would rather use this
t: ()
u: ()

I always add the _ when I use it
t: ( _* )
u: (_* )

t: (_*)  memorizes. there is never memorization without the _

and obvious a pattern that says (*)  which means find 0 or more words always matches, but then so does ()  which says I dont care what to match. There is no value in (*) notation by itself, which does add an unnoticeable cost to the data file (a couple of bytes) and to the execution speed, and makes visual scanning of it stumble a bit more for a human reader

also json should not occur after something else (unless encased in double quotes) because spell check will try to operate on it as normal user input, whereas spell check does not try to work inside a leading OOB input of any kind.  So the cs std input is
[ some oob data of some flavor which may ONLY json or it can be other stuff]  user input sentence

If your oob data is entirely a JSON structure (array or object) then it can be processed by cs tokenization into json directly.
[ {"field1":"value1", "field2": [ {...},{...}]}]

FYI unless you need the quotes to contain blanks in a value or field name, CS doesnt require the quotes at all (just the outside world uses it)
[{field1:value1,...}]

t: (*) == t: ()  and
u: (*) == u: ()

But u: () and t: () is better.  This changed altered 1.7K lines of code on my end, thank you.  Mostly c: (*)

Thank you for the note on the OOB and field quotes. I will probably end up just taking in JSON, and modifying this. 

I have not put together the interface yet for the avatar OOB, the front end developer is still organizing which events to send and what values to send.  We are still working on the avatar API.

Thank you for the note on JSON. I have something, more like a stub, I have to make sure it works once I get the api data.

[ {"field1":"value1", "field2": [ {...},{...}]}]