Cool idea! The problem is that at the “after reading command” stage the command has not yet been parsed, so the current action is set to the null value of waiting. You can solve this by using a truth state to keep track of whether you’ve just cut “continue” from your command:
[code]The player’s-ongoing-action is a stored action that varies.
Starting ongoing action is a truth state that varies.
Before reading a command:
now starting ongoing action is false. [This resets the flag every time we read a command.]
After reading a command:
If the player’s command includes "continue ":
cut the matched text;
now starting ongoing action is true;
[continue the action;] [you don’t need this in “after reading a command” rules; as long as you don’t have “reject the player’s command” parsing will continue]
First before when starting ongoing action is true: [this should fire before trying any action whatsoever]
now the player’s-ongoing-action is the current action;
if the current action is not waiting:
say “You begin [the current action] and will continue trying to do so until you specify otherwise.”;
otherwise:
say “Waiting while you do something else is the same thing as doing something else, so we won’t report it.”
Every turn when the player’s-ongoing-action is not waiting and starting ongoing action is false: [we need the second part so we don’t try the action twice on the turn when we start ongoing action]
say “([player’s-ongoing-action])[command clarification break]”;
try the player’s-ongoing-action.[/code]
Now, when we do something that depends on “after reading a command” rules in kludgy fashion like this, they tend to produce bad results when the player enters more than one action with the same command, such as “continue n. w” or even “continue take all”. Our code won’t know not to keep trying all of those actions every turn.
One thing you could try is disabling the continue mechanism when the multiple object list is nonempty or when more than one turn happens in a single command; this thread might give you some ideas for how to do the latter. That’d end up producing awkward results, but could at least allow you to print a failure message that tells the player what happened. (“I’m sorry, I can’t understand ‘continue’ when more than one command has been entered on a line, so I will just try the first action and stop processing.”)
Another thing you could try is a different kludge. Define an NPC, say “continuant,” who is omnipresent (could be part of an omnipresent backdrop). Use the after reading a command to replace “continue” with "continuant, " so that “Continue w” gets turned into “Continuant, w”; namely, a request to continuant to go west. Then redirect any action of continuant’s so that it becomes the player’s-ongoing-action. (Editable Stored Actions by Ron Newcomb would let you do that.) And Bob’s your uncle! [ETA: This thread has more suggestions on how to let the player take over an NPC’s actions.]
By the way, I’d probably use the syntax “begin to walk west,” because it’s more natural (“continue walking west” yields its own set of headaches). And you’d want “stop” and similar things to allow the player to reset the ongoing action. And, as you can see, this probably turns out to be much more complicated than useful. But it’s a cool exercise!
(Another thing you could do is set certain kinds of action – like going, perhaps, but not dropping – so that when the player tried them the game would ask if she wanted to keep doing them. Then you wouldn’t have to worry about parsing.)
…I feel as though it is irresponsible for me to send a newbie haring off after all this esoteric stuff. This is definitely more in the service of tinkering for its own sake rather than getting stuff done. But tinkering is fun!