Section 4 - Resurrection
[In versions 1-4 of the game, it was possible to die instantly in assorted ways. On an interpreter with working UNDO, it was possible to take this turn back, but a) some novice players may not realize this and b) some interpreters choked on trying to undo things given how very large the game state is.]
When play ends when the story has not ended finally:
wait for any key;
say "That is, that's what would have happened if [you] had done something so foolish. Shall we suppose [you] didn't? >";
if the player consents:
resume the story;
try looking.
Removing this would disable the feature.
As for what’ s going wrong, §9.4 of the manual says:
When the player dies, it’s usually accompanied by a change in the game state (e.g., a deadly object comes into being). So, the sequence of events would be: (1) player types a command, (2) the game state changes and the game decides that the player should die, (3) the code says end the story, (4) the resurrection rule runs and resumes the story, making it “as if no end the story phrase had been used” BUT whatever state changes happened in step (2) beyond changing deadflag remain. To fix the issue, they need to be undone; it’s not enough to just not kill the player and go on as if nothing happened.
In the Bureau specifically (where players are having more than cosmetic problems), we have code like:
now already caught is true;
say "[redacted to prevent spoilers]";
end the game saying "Our arrest goes badly";
Resurrection leaves “already caught” set to true erroneously. When it’s set, the rule that allows completion of the Bureau entrance sequence is effectively disabled. (I don’t understand why the variable exists, since it’s only set immediately before death.)
Seems like that would be the easiest solution. We could remove the feature entirely, but Emily’s comment shows that she’s concerned about novice players who don’t know about undo. Neither of these solutions addresses interpreters that can’t deal with a large undo state. Depending on how performance tuning goes, the undo state might shrink enough for this not to be an issue.
Very embarrassingly, the version of Ultra Undo CM currently includes doesn’t actually work. I just noticed the repo still has the old version, so I’ll update it and double check it works. Once that’s in place, all undo problems should be solved.
We should be able to use Zarf’s new Blorb data chunk feature to speed up the launch time.
Btw, if anyone is on Windows and would like to build the 6G60 version without messing up their 6L/6M Inform folder, I’ve tried the Portable Inform 7 app, and it works great. You’ll just have to copy the extensions into the InformPortable\App\Inform\Inform7\Extensions\ folder.
Thanks for taking initiative on this. I’ve commented on your patch. Please take a look, make any changes that you want, commit, and push the branch again. It should automatically update the pull request.
Update: Angstsmurf’s patch has been merged into the repo.
I made another pull request where I tried to fix the “Shall we pretend we didn’t do that?” issue mentioned above, by replacing the Ultra Undo version and using undo instead of “resume the story”.
I couldn’t actually find a Mac interpreter where standard Undo doesn’t work in this game, but I temporarily hacked Ultra Undo to always use external files, and it seemed to work as intended, although it left a lot of .glkdata files behind.
There seems to be a separate issue where the internal Inform interpreter hangs when you try to restore or undo no matter what, so I had to do all testing with external interpreters, but this is not affected by Ultra Undo at all.
The non 2MB undo version of Gargoyle should have the problem: github.com/garglk/garglk/releases
But you’ll have to ensure that you’re running Git not Glulxe, though that is the default so you shouldn’t need to change anything unless you modified garglk.ini yourself.
Thanks for fixing the issues! Someone, perhaps myself tomorrow, will merge them in soon. I would like to check myself that Ultra Undo is working properly before we publish version 6. I just have a vague feeling that I left one situation unaccounted for.
Yeah Glulx/Glk don’t give story files the option to specify where to store a file. It might be possible though to make the undo files start with a period, which would hide them in Linux and OSX. I’ll give that a try, and see if it works reliable across different terps. I might ask you to check it on OSX too before we publish version 6, if you don’t mind.
An advantage of putting files in a standard OS temporary folder is that it (at least in theory) is wiped clean between system restarts. A problem with the current implementation is that it might leave files behind, which might end up using quite a bit of disk space on small devices.
Would it be possible to have a feature that looks for stray undo files when the game starts and deletes them all?
I wouldn’t recommend using a temporary folder for this, even on mobile devices. Especially on mobile, I should say – that’s an environment where the user might relaunch the app a week later and expect undo to still work.
Good point. My other idea, deleting all undo files on game start, is probably also more trouble than it is worth when I think about it. A lot of work to save a couple of megabytes at most.
Ultra Undo tries to delete them when the game is restarted or restored. But Glk doesn’t give you a file list, so it can’t be certain it’s found them all.
I was thinking that I would upgrade it to 6M62 by chopping it into many files and doing it little bit by little bit. I’d want a game like this to use multiple files anyway, one giant file is too unwieldy. But I won’t have time to do that for another couple of weeks. If you do manage to get it working then we should just use your code. My one request would be to rebase it off the master branch rather than the undo branch.
I don’t know what the best way would be to incorporate this into the main Github repo, but I have at hunch it might be a good idea to rewind a bit and start with the 6M62 branch.
In the meantime, does anyone have any idea why it crashes after the first command (“Run-time problem P31: Attempt to use a property of the ‘nothing’ non-object: property description”)? For a while things kind of worked up until the cinema, then all of a sudden this began to happen. My prime suspect is the hashing functions in Counterfeit Hashing.i7x.
EDIT: The major bugs seem to be fixed. It might even be possible to finish now. It is just very slow; a mistyped command can take a full minute to parse.
EDIT 2: I got rid of most of the slowdown by replacing the new Threaded Conversation extension with a modified version of the old one that the original code used.
I haven’t looked much into the differences between the two, so I hope we don’t miss out on a lot of bug fixes in the new one.
Perhaps we could get more speed back by doing something similar with Smarter Parser.
EDIT 3: Finally got it to compile on 6M62! That took much too long. Apparently Sequential action is buggy on 6M62 – When I commented out the line in Locksmith that adds (- Constant SEQUENTIAL_ACTION; -) the compiler suddenly stopped crashing. No doubt disabling this will cause trouble elsewhere, but at least it’s playable at last. And it is fast!
EDIT 4: I noticed this was reported already: http://inform7.com/mantis/view.php?id=1838. Apparently it is the declarations of (- Constant SEQUENTIAL_ACTION; -) in both Locksmith and Facing that clashes.