I’m trying to figure out how to make an (out of world) action “invisible” to UNDO. Like, so that it doesn’t even register in the “queue” of actions that undo goes back through. For example, take this code:
[code]Test Chamber is a room. West Chamber is west of Test Chamber.
Blagging is an action out of world. Understand “blag” as blagging. Carry out blagging: say “Blag.”[/code]
(Sorry, couldn’t include a “test me” because undo isn’t allowed in test scripts.)
If you type “GO WEST. BLAG. UNDO,” the UNDO command will undo the BLAG, and you’ll still be in the West Chambetr. I want UNDO to skip over the BLAG entirely, so that UNDO takes you back to the Test Chamber.
The documentation for Undo Output Control by Erik Temple says it can do the following:
Each turn, after the player has entered a command but before the command is parsed, Inform saves the state of the game into memory. This is the saved state to which the next UNDO command will revert. We can stop the game from saving the undo state, if desired. Once we’ve disabled saving, an UNDO typed later will revert back to the last saved state. If there are no saved undo states available, a message will print (“You cannot undo any further” by default).
It looks like there’s a native way to do this in Unified Glulx Input:
…OK, now that I’ve tried to implement this and looked at the documentation a bit more, I think that this won’t get what you want out of the box. It looks to me as though (maybe) the very same I7 flag tells UGI whether to allow UNDO and whether to save an UNDO state, so it might not be possible to use this to allow undoing past BLAG. Or maybe the problem is that by the time the game has understood the BLAG command, it’s too late to flush the UNDO state? Not sure. But I’d guess if you want to hack something up the place to look would be around the code for this in UGI rather than the code in Undo Output Control
Yeah, I think this was the problem with my original goal. UGI decides whether an undo-state is saved well before the command is parsed, before the “player’s command” snippet is set, even.
However, I went back and re-examined my situation and realized that I only needed to make BLAG non-undoable in a certain, specific context – which is something UGI is designed to handle, so problem solved.
My recollection is that this is the underlying problem. It’s been a while since I looked at UGI, though.
There’s no “flush” feature at all in the VM, so really what you have to do is not save the undo state in the first place. But this occurs right after (or right before?) input, so there’s no chance to discriminate based on command.
(The flag documented above is really for dealing with inputs like the arrows keys that scroll around in a help menu. You don’t want those to be undo stages, but you know in advance that you’re doing menu-keystroke input.)
For my own curiosity, I wonder why this doesn’t seem to do anything:
Include Unified Glulx Input by Andrew Plotkin.
Black Room is a room. There is a bottle of poison in Black Room.
Undo disabled is a truth state that varies.
Instead of drinking the bottle of poison:
now the printed name of the bottle is “empty bottle”;
say “You drink down the poison in a single draught! That probably wasn’t very smart.”;
now undo disabled is true.
Setting up input when undo disabled is true: set input non-undoable.
Every turn when the printed name of the bottle is “empty bottle”:
say “[one of]Your cheeks burn[or]Your teeth hurt[or]Your belly twists[or]Your vision fades[the end][stopping].”
To say the end:
end the story saying “You have died”.
Check saving the game when undo disabled is true:
say "Maybe it would be best to UNDO your terrible mistake before saving. Are you sure you want to save now, while you’re dying? ";
if the player consents:
continue the action;
I can see from zarf’s comment that this isn’t the intended use, but shouldn’t it at least prevent some of the undo states from getting saved?
There’s a default setting-up input rule, the “standard parser input line request rule,” which sets undo disabled to false at the start of every turn. Since your rule is more specific (because it has a when condition attached), it get sorted immediately before the standard parser input line request rule, which sets the input back to undoable.
If you specify that your rule is listed last, or at least after the standard parser input line request rule, I think your example should work.
Hmm, there was a reference to that sort of thing in zarf’s documentation, but I didn’t really get it at the time. I think maybe “UNDO” doesn’t get parsed through the normal set of understand rules. If you shut down undoability through UGI, you also shut down the game’s ability to recognize the word.
What I did, more or less, was check the input for the word “undo” at the after reading stage, then follow the “immediately undo rule” (which what the game uses in the “final question” mode at the end of the game), then reject the player’s command. I tried testing that in your example, though, and it didn’t behave as expected.