[UPDATE: climbingstars’ solution seems to work for this particular case, but I think mine is more robust – and if preventing time from passing when you reject a command in Waitingville is important, it seems to do that.]
Well, I wouldn’t put too much stock in it until it’s been looked over by someone who really understands what’s going on. But here’s what I think is going on, looking at the chart of what rules are consulted in what order:
Ordinarily, the turn sequence rulebook starts with the “parse command” rule, which in turn begins by running the “reading a command” activity and then does other parsing. Then the turn sequence rulebook runs the “generate action” rule, which among other things runs the before rulebook, the instead rulebook, and the specific action-processing rulebooks (check/carry out/after/report for the action in question). Then in the turn sequence rulebook we have the “every turn” rulebook, and other stuff.
However when you have a bunch of commands joined together by dots, it seems as though the “reading a command” activity only happens once, even though the “parse command” rule fires every time through the turn sequence rulebook.
[spoiler]Try this:
[code]
Lab is a room. After reading a command: say “Command: [the player’s command].”
This is the new parse command rule:
say “Parsing!”;
follow the parse command rule.
The new parse command rule is listed instead of the parse command rule in the turn sequence rules.
Test me with “z. jump. sing . get foo. x me”.[/code]
As you can see, the new parse command rule fires once for each command, but the after reading a command rule only fires once. You can also see that the parser error interrupts the chain of commands.[/spoiler]
So what I did was set “executing first command” to true in the “after reading a command” stage, to make sure it stayed true the first time through the turn sequence rules. Then I set “executing first command” to false in the every turn rules, so that if we go through the turn sequence rules again without going through the “reading a command” activity again, “executing first command” will be false. This should only happen when we’re executing the second or later command in a dot sequence, I hope.
Of course it doesn’t matter whether we’re executing a dot sequence unless the rule that moves us to Actionville has run, so I used the “moved to Actionville” truth state to keep track of that.
Then I wanted to interrupt the turn sequence if we’d moved to Actionville and weren’t executing the first command. That’s what the “interrupt the turn when moving to Actionville” rule does – and since I want it to stop everything, I put it in the turn sequence rules instead of in the action-processing rules. So the “instead” in that rule stops the whole turn sequence rulebook. (This happens for each dotted command, which is why we need the business with “stopping” in the message that gets printed.) So the every turn rules don’t run, the advance time rule doesn’t run, none of that stuff.
One issue is that if you trigger a parser error, like “z.z.z.z.z.z.z.foo”, the parser error message will still print. That’s because parser errors happen in the “parse command” rule, and that fires before the “interrupt the turn” rule. (I tried putting the “interrupt the turn” rule before the “parse command” rule, but it led to an infinite loop; which may be because I didn’t take care in setting the initial values of my flags.) You could take care of that by writing a special rule for printing a parser error when moved to Actionville is true and executing first command is false, but you’d have to make sure that it prints out the relevant text if and only if you haven’t already printed it with the interrupt turn rule.
Well, I hope that made some sense, and anyone who understands this better than I did should totally chime in.