I have a tree with an up connection so that I can climb up the tree. This also has a barrier to prevent me going up the tree until I've met a condition.
Question: How do I implement CLIMB TREE as a synonym for UP so that it is subject to the same condition? Or should I just do my own thing and not use barrier{} in this instance?
If I use submit_command, there is a parameter stop_tick = "true". I imagine that serves the same purpose as the stop_tick statement. Correct?
Anyway, this appears to work, except that it redisplays the prompt and the submitted command. Is there any way to avoid that? I couldn't discover any extra parameters. I took a stab at quiet = "true", but that didn't work.
Added a command called:
: set_sentence "your replacement sentence here";
This will change the current parse sentence instantly.
Note that this command does not registed as a command that does work, so using it will not tamper with downstream system handlers for particular commands.
e.g.
If I place this at the top of the on_command {} block, then whatever I type, the save dialog will be displayed.
: set_sentence "save";
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.
