[I7] Stopping the "Obituary" Question From Appearing

What I’m trying to do is allow an end of story scenario to play out but once the obituary part occurs, to stop it. This is for some unit testing tools I’m doing where some actions do lead to an end of game but I want the end of game output to be accepted but then simply nullify that the end of game occurred.

More specifically, I want to stop the question “Would you like to RESTART, RESTORE a saved game, QUIT or UNDO the last command?” from being asked as that kills any unit testing tools in their tracks.

Just to see if I could get avoiding the question to work at a simple level, I tried this:

Rule for printing the player's obituary: say "Avoid Death" instead.
That doesn’t work. The question is still asked.

I tried:

Rule for printing the player's obituary: end the printing the player's obituary activity.
That doesn’t work. The question is still asked but you get:

*** Run-time problem P13: Tried to abandon an activity which wasn’t going on

Then I tried:

After printing the player's obituary: end the printing the player's obituary activity.
That doesn’t work, you get:

Glulxe fatal error: Stack overflow in function call.

I also tried to abandon – rather than end – the activity and the same errors mainly still occur. For example, I tried this:

After printing the player's obituary: abandon the printing the player's obituary activity.
The question still gets asked but you get this set of errors:

[** Programming error: tried to write to -->-1 in the array “activity_parameters_stack”, which has entries 0 up to 19 ]
Programming error: tried to write to -->-1 in the array “activities_stack”, which has entries 0 up to 19 **]

I also tried to just fail the rule, like this:

Before printing the player's obituary: rule fails.
No errors come up but it doesn’t do anything. The question is still asked.

Basically if you try to do anything with “Before” or “Rule for” with this activity, you get an error about how the activity wasn’t going on or nothing at all happens. So it seems like you have to handle things in the “After” part of the handling, but that leads to various types of errors.

So maybe the better question here is how you can entirely subvert how an end of game (“obituary”) part of Inform works.

Any ideas?

You can skip the final question step; the interpreter will then proceed to quit.

The ask the final question rule is not listed in the shutdown rulebook.

If you want to cancel death entirely, and instead return to the parser loop, you can instead add:

When play ends: 
	resume the story.
1 Like

Ah, interesting. Okay, I needed to be looking at the shutdown rulebook, which probably should have been obvious to me.

I do like the “cancel death entirely” part as I do need the interpreter to continue since there may be more tests to run. And then, given that, I think I may have to change my extension a bit. Specifically, I’m referring to the i7Spec.i7x extension. And by change it, I mean I wonder if I should make the spec processing an activity instead.

And I say that because I would only want the “cancel death entirely” part to be operative when the spec processing is running. During normal play – including with the “test” command built in to Inform – I would want the end of game style functionality to work as it should. So I would need the “When play ends: resume the story” part to be conditional upon a context, which it seems would be more suited to an activity.

I note that I do all my Inform unit testing with a framework around the interpreter, not in-game extensions. I don’t want to worry about the in-game test code changing the game behavior in an unexpected way.

I realize that there are many valid testing approaches, of course. :slight_smile:

Totally understood on that! The main reason I’m doing this is because I use Inform 7 for teaching about testing itself: spotting test and data conditions, for example, as well as how and when to combine tests (and when not to). Just to give you an idea, here’s what I produce in the source text with that extension:

context “player can’t take the message if the box is closed”;
verify that “take message” produces “The glass box isn’t open.”

context “player can’t open the glass box and accidentally kill themselves”;
verify that “open glass box” produces “You’re deterred by the swirling bottle-green mist within.”

context “player can’t examine the message if they’re not holding it”;
verify that “examine message” produces “You need to be holding it before you can read it.”

context “Kitty can take the message without opening the glass box”;
verify that “Kitty, get the message” produces “As her hands pass through the glass box, Kitty Pryde picks up the message.”;
verify that “examine box” produces “In the glass box are some poison gas.”

context “Kitty won’t take the poison gas when asked”;
verify that “Kitty, take the gas” produces “Kitty looks at you as if you were an idiot. ‘How exactly do you expect me to do that?’”

context “the player is killed in the presence of Kitty, who observes”;
do “kitty, open the box”;
verify that “wait” produces “Time passes.[paragraph break]The poison gas has reached your lungs.[line break]Kitty seems to take a disturbing interest in your writhing spasms.”;
These are really more meant to be acceptance tests than unit tests because I can string together a series of commands. That last scenario is a case in point of where the action of Kitty opening the box and then waiting one turn causes death. That text being verified is the final text the player sees but that’s also what produces the question and the end of game scenario. It’s that part that I’m trying to deal with.

All that being said, none of that negates your statement and may in fact be a point in favor of it. Perhaps I should be looking to do this more outside of the game itself. The reason I glommed onto this approach is because I did like Inform’s built in test mechanism and wanted to augment it a bit. Also, I can have my classes just look at a source file and have them enter scenarios in their own example source and then we see what does (and doesn’t) make sense.