Another issue - If statements?

instead of examining the crack: if we have not examined the crack: say "As you look at the mirror a bit closer, your eyes float over to the crack in the corner. You notice that there looks to be a small space behind the crack."; if we have examined the crack: say "You guide your hand gingerly through the small opening. As your hand searches the small space, something metallic brushes your fingertips."; wait for any key; say "Your fingers close around the small object"; the player now has the key;

As far as I can tell, this SHOULD work, but it doesn’t. all I ever get is the same first line, as if this is the first time looking at it. Ideas?

-Ok, so I think the issue here is that I’m saying INSTEAD of examining this thing, do this, and thus, the thing never actually gets examined.

I believe you’re right. The quickest fix may be to add “rule succeeds”:

instead of examining the crack: if we have not examined the crack: say "As you look at the mirror a bit closer, your eyes float over to the crack in the corner. You notice that there looks to be a small space behind the crack."; rule succeeds; if we have examined the crack: say "You guide your hand gingerly through the small opening. As your hand searches the small space, something metallic brushes your fingertips."; wait for any key; say "Your fingers close around the small object."; now the player has the key;

Nice! Thank you!

Are you sure the code is the right way round here? It looks like this will cause the key to be moved to the player every time you examine the crack after the first time.

What kind of a syntax is this “if we have examined the crack” anyway? Who are “we” here? Does this actually check “if the player has examined the crack” or “if the crack has been examined” (neither of which are valid I7 check)?

I take back what I said about my problem with I7 being I don’t know how to map I7 constructs onto a standard OOP or other programming paradigms; this, right here, is my beef with I7. Suddenly you throw these kind of statements in there, which look smooth, but which really do not make sense. IMHO.

Coming from a programming background myself, I agree! I used “if we have examined the crack” from an example I saw, and it does work.

The only mention I can quickly find of this syntax is in the built-in docs is in ch. 9.16 (The review of the chapter on time). IIRC it’s true if any player character has successfully performed the action. (Instead rules by default stop the action in failure.)

There are other ways to do what you want that may or may not be more Informish such as:

Instead of examining the crack for the first time:
	say "As you look at the mirror a bit closer, your eyes float over to the crack in the corner. You notice that there looks to be a small space behind the crack."

Instead of examining the crack when the key is not handled:
	say "You guide your hand gingerly through the small opening. As your hand searches the small space, something metallic brushes your fingertips.";
	wait for any key;
	say "Your fingers close around the small object.";
	now the player has the key.

(Things are flagged as ‘handled’ as soon as you have, well, handled them.)

You are trying to set a condition here, so it’s worth remembering that the simplest way to do it would be something like:

The crack can be ever-examined.

Instead of examining the crack when the crack is not ever-examined:
    now the crack is ever-examined;
    say "...";

Instead of examining the crack:
    say "...";

With this plan you don’t have to worry about “rule succeeds”, or whether you’re using check or instead, or the mechanics of the “handled” property, or the exact meaning of the “we have examined…” predicate. You define a flag and use it.

All the rest is shortcuts, based on higher-level features of the I7 world model. You can use them or not. (I find action history predicates to be fiddly and not really worth the debugging time. You may disagree.)

I hardly ever bother with the past tense, since you need to know what you’re talking about (in this case, the crack) at compile time; this makes writing general code impossible. You can’t, for instance, write this:

Instead of examining when we have examined the noun:

Sure you can. What gave you the idea that you can’t write that?

There is a passage in the built-in docs that suggests not that it is illegal but that it’s bad form:

Hrm, that passage is troubling for a number of reasons. First, it’s utterly confusing, especially for a newbie. It would be easy to interpret this as saying that no generalized code that makes use of global (or rulebook) variables is a good idea. It could also be read as saying that there’s something about past-tense conditions that makes them get “confused” by the use of globals. But neither is true. (There is also the problem of the use of the “in the past, things could have been very different” construction, which really muddies things up.)

There is nothing practically “unsafe” about writing (to follow NYKevin’s example):

Before examining something when we have examined the noun: say "You have another look at [the noun]. [run paragraph on]"; continue the action.

You have to be aware of what might happen on action redirection or manual/parsed changes to “the noun”, but that’s just as true for any other use you might make of “the noun” and similar variables…

Oh, I was confusing it with the other past tense:

Before when the noun was open: Do nothing.Inform doesn’t like the above at all.