Hi,  I have the following problem:

I am calling my bot every second to sync oob data information.
Because of that the controlscript is called multiple times without user input and in between of the actual user inputs. It’s just generating oob data during this calls and not calling ^respond() or ^gambit() and so on

This generates the problem that the ^rejoinder isn’t executing the rejoinders if there is one of those oob syncs in between.

So is there a way to keep the rejoinder in case that the control script is called without user input?

In a postprocessing topic, grab the output rejoinder when there is one, save it on a permanent variable. Then on input in your control script, when there is a user input (either %more is true if you had oob or there was no < \[ on the first input), reset the rejoinder with something like this ^setrejoinder(copy $holdrejoinder)

Bruce Wilcox - Dec 19, 2016:

In a postprocessing topic, grab the output rejoinder when there is one, save it on a permanent variable.

By that you mean %outputrejoinder?

I did as you suggested, but the rejoinder is not executed.

I did some reasearch in the manuals and this is how I understand my problem now:

When executing a rule which has an rejoinder, the chatscript engine sets the rule id of the first rejoinder to %outputrejoinder. Than at the next volley the last outputrejoinder is the new input rejoinder, which is used for ^rejoinder().

This is problematical in my case, because %inputrejoinder is than only set when I check my oob data and null again for my next user input.

So woudn’t it make more sense to execute ^setRejoinder(input $holdrejoinder) and then call ^rejoinder()?

I tried that, but somehow this call fails and input is terminated during the call.

I did say use ^setrejoinder(copy not ^setrejoinder(input

The thing about input rejoinders, is that there are two ways to set it. When you use ^setRejoinder(input…) you are naming the encompassing rule. Internally, CS sets a rejoinder mark on the first rejoinder itself. When you get a “copy” of the rejoinder from %outputrejoinder, you are getting a tag to the internal location. using ^setrejoinder(copy ...) says to use the copy, not believe that you are naming the rule.  Typically you have a label attached to the encompassing rule and dont bother to label the first rejoinder. Saying ^setrejoinder(input is saying I want to pretend I am at this rule and now use rejoinders from there.

Two things to point out here.

^setrejoinder() must reference the parent of actual rejoinder rule and this command will fail if the rule doesn’t exist or that rule doesn’t have any rejoinders.

You can only call ^rejoinder() successfully once per volley. Calling it a second time will fail unless you failed those first rejoinder rules.

I don’t actually agree with Andy’s comments.

Bruce Wilcox - Dec 20, 2016:

I did say use ^setrejoinder(copy not ^setrejoinder(input

I know, sorry. But this wasn’t working for me.
The rejoinder isn’t executed.
What is working is setting %inputrejoinder directly however.
Now I have the behavior I want.

But I suppose this is a bad solution, right?

OK, Bruce.
Which statement, or both?

This was on my mind because I actually went through this very code in the engine last week.

I said comments because I meant BOTH.  Check this code in RejoinderCode:
  if (inputSentenceCount) // this is the 2nd sentence that failed, give up

and we had already been discussing using ^setrejoinder(copy ...) where ... is a reference to a REJOINDER, not the higher rule.

Setting %inputrejoinder directly is very bad (its sort of permanent).
You could, of course, actually write your own rejoinder processing code (building it using ^refine(), but the basic thing should work already.

If you have gotten the outputrejonder in volley 5, you can save it on a variable in postprocessing, and set on a different variable the volley id + 1.  Then in control at start you can see if current volley id matches and if so, do ^setrejoinder(copy for EVERY sentence in your input (since at start of control script).

Our postings (3 and 4) were posted at about the same time, and both in response to Tobias - I didn’t see your posting till later and therefore your reference to copy. I was referring to ^setrejoinder(input ...).

So the point I was making was that ^rejoinder() can only be called, and handled successfully, once in the volley. The unusedRejoinder variable takes care of that and that is only reset when the entire topic system is.

I was outlining the common scenarios in which a ^rejoinder() call can fail - either the rejoinder rule is not found or there have been several calls (or the unlikely scenario of calling from post process).

I understand. I merely disagreed with your statements.
And ^rejoinder can be called for EACH sentence in a volley, and it will react to the first 2.