I didn't understand your explanation. Nevertheless, I thought I should let you know that I have used set_sentence, but not in the way that I originally intended, and it seems to work well.
When you have some spare time, would you mind explaining how this works? It would seem that the original sentence is replaced and reparsed in order to determine the new verbs and nouns, then processing of the event handler continues. I suspect that there could be some gotchas if not used carefully.
It works as this:
(1) The command is parsed and split into different logical sentences. Each set of text that has been detected to be an independent command is iterated over and parsed. During iteration the sentence is stored in the runtime state as "logical_sentence".
(2) The local on_command {} block for the current location is executed followed by the global on_command{} block, for each logical sentence.
(3) If set_sentence is encountered, then the sentence is split and parsed. If there is more than one sentence in the replacement text (inside set_sentence) then it is ignored. There can only be one logical sentence in set_sentence. If the sentence is exactly one logical sentence, then the logical sentence in the runtime state is overwritten with the new parsed sentence.
(4) Downstream matches and ifs compare against the updated logical sentence, not the original logical sentence. No new ticks are performed. It resumes execution precisely after the set_sentence.
(5) set_sentence is automatically "masked", i.e. it doesn't stop the default handlers from running (if nothing has executed in place of them).
(6) submit_command is different because it queues up a new command in a new tick. That command was primarily written for gamebook or gamebook hybrid mode, and I'm leaving it as it is.
