If this is a bug, it’s minor, but it’s still bugging me:
[code]The Study is a room.
The Desk is a supporter in the Study. The description is “A solid desk.”
a piece of paper is in the study. “A blank piece of paper is lying on the floor.”.
Instead of examining a supporter:
say “[description of the noun]”;
try searching the noun;
if the noun supports a not handled thing:
say “[initial appearance of a random not handled thing on the noun]”;
Every turn:
say “[The paper] is [if paper is not handled]not [end if]handled.”;
test me with “look / put paper on desk / x desk / take paper / look”.[/code]
This turned up because I was reading the “handled” property when listing the contents of supporters. If you implicitly take an unhandled item and put it on a supporter (or in a container) elsewhere all in the same turn, it never gets marked as handled. This can look very weird, as you see here.
I’m guessing from this that “handled” actually means “was in the player’s inventory at the end of a turn,” which isn’t exactly what you’d expect it to mean. Is this worth reporting or should I just work around it somehow?
That would work. I decided to go with an “after taking something not handled” rule, but maybe this would be better:
Definition: a thing is moved if it is handled or we have taken it.
It makes me wonder, though: Is there a concept of “the original state” of a thing? How does restarting the game work? Is it something really low-level like saving the initial z-machine state, or does it happen by rerunning all the code that’s not stuck in other rules? The game I’m working on has a “checkpoint” system where we often reset everything to a particular state, but continue the current scene instead of starting at the “when play begins.” I’ve had to duplicate the initial state of every object in a reset phrase because I’m assuming I can’t access the state that’s described in the source. I’m also consciously avoiding anything like “[one of]fee[or]fi[or]fo[or]fum[stopping]” or “blank out the whole row” because as far as I know, there’s no way at all to reset that.
Yeah, the interpreter saves the startup state as a snapshot of all of memory. The same is true of save files and undo snapshots. They’re not accessible by the game.
There’s currently no better way to checkpoint a state than the way you’re doing it. You might be able to write code to copy out a lot of low-level memory state – all the state representing an object’s properties, for example. But I7 stores state in a lot of little arrays here and there. Locating it all would be tedious.
(I had to do something similar, in Inform 6, for Spider and Web. But I6 is simpler. I was able to ensure that all important game state was in object properties and attributes.)
The concept of game-controlled checkpointing comes up fairly often. Maybe it’s worth adding to the Glulx spec? A repository of undo snapshots that are not in the regular user-controlled chain, but can only be reached by game request?
The problem is, this is a total solution. Any information that you didn’t want restored would have to be written into a protected array. I think the more likely request is “I want to checkpoint these objects and tables and string-things, but those over there should be left alone.” That’s a much harder problem for I7 as it stands.
Doesn’t Jesse’s extension Hypothetical Questions walk this ground? With some tweaks, all the game leading from the last checkpoint could be done ‘hypothetically’, until the next checkpoint where you can reify it.