Uh, now, my new puzzle is recreating its Undo function.
Undo works well per se with Zarf’s Unified Glulx Input, which I’m using. But its built-in method has ben my sole method of undoing.
I know we semi-had this discussion here before about what the ‘immediately undo’ rule does and when. But my problem at the moment is:
Player chooses option which ends game (that’s their move)
I attempt, within the same turn, to print a final question menu and get a keypress on it directly. I’m not using accepting or handling rules for this keypress. In other words, I try to avoid obvious turn mechanics. I’ve also tried doing this menu as an in-code action, and as an activity.
Trying to follow the ‘immediately undo’ rule from the menu at this point does nothing.
Where I want to be if the player chooses UNDO is just before step 1.
Do any of you have any ideas or workarounds? Thanks much.
Hm, I think I overthought this problem. I actually do need to go to a new turn, then immediately be ready to undo to the previous turn, which will be back to just before step 1 in my chart. I will go try some form of this.
EDIT: OK, I rediscovered something I left a comment about in my source previously and forgot since. I was never able to UNDO after launching a menu before, which is why I forbid UNDOing from my options menu - it’s just too late, especially if I’m generating hyperlinks to ask YES or NO confirm questions, and the player is choosing different menu options and/or backing out of them.
So what I’m going to try to do is save the game upon victory, then move into a new turn which has the options menu, including an UNDO. And at this point, the UNDO will be reloading a game saved one turn ago rather than using the UNDO mechanism.
Grrrr, it’s too late to save, too. The game saves the fact that the player just performed the winning action.
I can’t work out how to do this. I need to be able to follow a bunch of rules and respond to keypresses right after the winning action (EG the CYOA equivalent of Final Question) and then, UNDO back to the last turn before they took the winning action, if the player wants that. I’m opening the floor anew to suggestions!
I am experimenting with saving the game every turn. I wasn’t crazy about doing this to people online, but it seems not to be a speed problem.
Unfortunately the game recovers differently after the fake undo (actually a game restore) in the Mac IDE and in Gargoyle than it does online.
In Quixe, an additional ‘look’ is required to kick the game along after the restore, or the player sees no options. Offline, the additional look causes the options to appear twice in a row over two turns. I will experiment and see if timing in the turn sequence of the save command can correct this.
There should be no difference, so there is probably a subtle bug in your code somewhere.
This whole mess should be less of a mess, obviously. The last go-round, I added the notion of “set input non-undoable” to UGI. I hoped that would cover the situation but I wasn’t sure.
Here’s how it should work: every input after the fatal move (game-ending option) is non-undoable. So the last undo state will be right after the fatal command is entered but before it is executed. The ParserInput function then detects this case (i == 2) and discards the entered command, putting you back where you want.
(Apologies if you already figured all of this out and it doesn’t work.)
Hm. Well, there is no difference if I save like a civilised person. That is to say, at the exact moment a game would usually save the data, like when the player just typed, or chose to ‘save’ as their action for the turn. In such cases, online and offline recover just fine.
I’ve noticed if I move the placement of the save moment around within the turn sequence, that can cause Quixe to issue no complete default look upon the restore. It just prints the room name, and I checked and saw that it is not actually running the room description body text rule. Offline, the IDE seems OK.
I should qualify that I have written a lot of extra code into the LOOK sequence, but it sort of sits atop it. I haven’t removed any rules, just replaced them with versions that also cope with the CYOA stuff.
Ah, I remember seeing that, but I forgot about it in the meantime… I think because I expected it would only work before the player entered a command?
ie Can I set things to non-undoable AFTER seeing the player has entered the fatal command? Otherwise I can’t anticipate when it will happen. I want to ask you this before I try it, as to make it happen I will need to write some new input context code and such. I’m assuming the approach would be:
See player enter game-ending command
Set input non-undoable. Say ‘game over’.
Player fiddles in end menu…
Eventually player chooses undo. This is caught by ‘Checking undo input rule’ and we return to just before 1.
You don’t need to anticipate anything. What you need is for all the post-death and final-question inputs to be marked non-undoable. (This replicates the behavior of the standard library, which never saves an undo state during the final-question loop.)
OK, I’m not even that close to checking if non-undoability works yet as I’ve yet to work out how to fire the UNDO mechanism from within the end game menu.
While moving around in this menu collecting input, the checking undo input rule is not being visited automatically, and it’s only via that rule succeeding that I’ve had UNDO’s happen in this project.
I deliberately tried just following the checking undo input rule out of turn to see what would happen, first setting up a definite match that would have it succeed, and I see that the rule was visited when I do ‘rules all’, but it still didn’t cause an UNDO to happen.
EDIT: Oh man, I think I got it working. I used my gooey I6 hacking instincts to make a (- Perform_Undo(); -) command. I called that directly and it went back to where I wanted it to. Now to push it around a bit!
EDITEDIT: Nth qualifier - I haven’t worked with 'set non-undoable 'yet. I just managed to get an UNDO to happen without the checking undo rules. But in reaching this point, I found I didn’t need to set non-undoable, because as I’d suspected,I hadn’t yet gone more than one turn away from the place I wanted to UNDO to. Buuut, I still hope to use set-non undoable, so will report back on how it goes.
Therefore it was some other change that got it working. I think when it wasn’t working, I was trying to get the checking undo input rule to succeed to make it happen. And that rule wasn’t even being called as a matter of course at this particular point in the turn.
All I’m doing now is - awaiting input in a particular context, then accepting some input, then manually checking if the player wanted to undo, then perform_undo-ing. (No handling input). The fact this may be after multiple accepts of input (yeses, noes, menu stuff) doesn’t seem to impede the trip back to the undo point, presumably because I never let the turn end? I think I just kept bouncing from action to action and using ‘insteads’ and such.