Instead of going northwest while player is in Lavatory:
if player has not held comb:
say "Your hair is mussed up";
stop the action;
otherwise:
if player has not held razor:
say "Really, man, you got stubble the size of asperagus.";
stop the action;
otherwise:
if player has not held toothbrush:
say "Are you kidding? Stanley Kowalski has better breath than you do right now.";
stop the action;
otherwise:
if player wears foam:
say "Your haven[']t dealt with the Burma-Shave yet.";
stop the action;
otherwise:
continue the action.
Transcript:
actions
Actions listing on.
se
[going southeast]
Lavatory
All the modern conveniences are here, or at least as many as you can afford, which ain’t much.
You can see a sink (on which are a razor, a comb, a tube of toothpaste, a toothbrush and a can of Burma-Shave) here.
[going southeast - succeeded]
There’s no dice in this game. MOVE!
nw
[going northwest]
Bedroom
Your bedroom is stark, but otherwise not elegant. That’ll change someday. You can go east to the closet, southeast to the lavatory, southwest to the kitchen, or north to Union Street.
You can see a leather case (closed), a bed, a small stand (on which are a trophy and a clock) and a bedstand (in which is a drawer (closed)) here.
In my testing, the “has not held” condition seems to do nothing. It compiles, but has no effect. Possibly I’m wrong about this, but that’s what I’m seeing. A more knowledgeable Informer will have to weigh in on this problem.
So I never actually use formulations like “if the player has not held…”, but if they’re not working for you one thing you could do is give the player a bunch of properties that get set at the appropriate time and check those properties. Like.
The player can be unshaven or shaven. The player is unshaven. The player can be unbrushed or brushed. The player is unbrushed.
And then you make sure that you say “now the player is shaven” and “the player is brushed” at the appropriate times, and you can check “if the player is unshaven” and “if the player is unbrushed” when you want to.
This doesn’t explain why the formulation you’ve been using isn’t working, but it could get be a workaround.
And here’s something new: the code is not working as it previously did in describing a can of Burma-Shave or the button on top of it, and it’s not letting the player push the button any more.
[code]The description of Burma-Shave is “It’s the brushless shaving cream. There’s a little button on the top of the can.”
A button is part of Burma-Shave.
The description of the button is “It[’]s the button on top of a can of shaving cream. Surely you[’]ve seen one before.”[/code]
Slight correction: “the player” isn’t an object, it’s a variable (to allow “now the player is Alice” and such). You’d need to say “yourself can be unshaven or shaven” and “yourself can be unbrushed or brushed”. Once the adjectives are defined though you can use “now the player is shaven” and such without a problem.
“Yourself” is the default object created to be the initial state of the “player” variable. I think it’s called something like “your former self” if you later change the variable in the course of the story.
EDIT: As in, if it appears in a room description or something, it’s called “your former self”. The internal name is always “yourself”. Sorry, pronouns are a bit weird here…
Anyone who has ever done any computer programming feels that way from time to time! If it’s any consolation, you’re not alone.
That said, my general observation is that you’ll have an easier time of it if you’re able to be more patient about thinking through the logic of what you’re writing. I7 is seductive in that it invites the author to assume that he or she can just write stuff and that the computer will magically understand what’s written. But that’s not the case at all. I7 is a computer programming language. Its rules for how to get things to work are very rigid. Trying to apply code fixes without having a clear understanding of the details of the syntax of the language is more than likely to produce unintended consequences – which you are now experiencing.
The puzzles you’re developing, such as the toothpaste and Bryl-Creem business, are complex. There are several ways that this could be done in I7. Some of the suggestions you’ve gotten from more experienced I7 authors may hint at other approaches to implementing those puzzles, but the suggestions you’re given don’t invariably provide full-on explanations or complete solutions. If you add one of those hints to your existing code without noticing the implications, the results are not guaranteed to be pretty.
I think it’s a level of I7 I don’t wanna go near, just yet. 