If you end up wanting your own inventory-fiddling code, Emily’s recommendation of Jon Ingold’s Written Inventory extension is a good one. If you need further hacking (as I did), you might find my Fragile Shells source (ifarchive.org/if-archive/games/s … Shells.txt) helpful. Look for “Chapter 4 - Updated Inventory”.
Thanks everyone, particlarly Emily for such a detailed explanation. Much appreciated and sorry it’s taken so long for me to get back to you:
- I began working on the suggestions and lost track of time,
- It took me a while to locate this thread again
My first project is taking shape, slowly but surely, and as intended I’m learning things along the way.
Still running over some bumps with the syntax and vocabulary however. I have one particular rule that I need to create, and it has baffled me for months even though it ought to be very simple. I’ve put it aside and worked on other things (making considerable progress), then come back to it and tried again, re-visited Inform7’s inbuilt documentation, and tried every variation that I can think of.
I know I’m going to feel like an idiot when I see the answer, but how do I achieve this?
I have a fire extinguisher case with a glass front. Player has to find an object suitable to break or cut the glass case to reach the extinguisher. Obviously I don’t want the player taking anything in or out of the case while the glass is in the way.
The code I’ve tried
First part works fine:
[code]Glass is a kind of thing. Glass can be intact, shattered or cut.
A small metal case is in the Kitchen. The small metal case is fixed in place. The case glass is part of the small metal case. The case glass is glass and intact.
A fire extinguisher is inside the small metal case.[/code]
Below is the code that I’ve been unable to get to work:
Instead of taking a thing out of the small metal case when the case glass is intact:
say "The glass front of the case prevents you reaching inside."
Instead of putting a thing inside the small metal case when the case glass is intact:
say "The glass front of the case prevents you reaching inside."
This is the error, every single time:
You wrote ‘Instead of taking a thing out of the small metal case when the case glass is intact’ , which seems to introduce a rule taking effect only if the action is ‘taking a thing out of the small metal case when the case glass is intact’. The part after ‘when’ (or ‘while’) was fine, but the earlier words did not make sense as a description of an action. I am unable to place this rule into any rulebook.
In place of “a thing” I’ve tried “anything”, “any object”, “(whatever - a thing)” and some others I’ve forgotten now.
In place of “out of the small metal case” I’ve tried “from the small metal case” and “from out of the small metal case” and “remove a thing from the small metal case.”
I know this is going to turn out to be something embarrasingly simple. 
This looks a lot less embarrassingly simple than you think. The action you want for “taking it out of” is “removing it from,” I think, but if you look up “removing it from” in the index (under the Actions tab) it warns you not to write rules about it – you can only remove things from things by TAKING them, and the removing action is used to provide error messages. So for the first rule, what you want I think is something like:
nstead of taking a thing when the small metal case encloses the noun and the case glass is intact:
say "The glass front of the case prevents you reaching inside."
(I originally had “when the noun is in the small metal case” but I wanted to catch cases where you had something that was in a container that in turn is in the case, or something like that. Haven’t tested those cases.)
For the other rule, the name of that action is “inserting it into” – this is one that trips me up a lot – so you can write
Instead of inserting a thing into the small metal case when the case glass is intact:
say "The glass front of the case prevents you reaching inside."
Haven’t tested these too much but at least they work in the basic cases!
Thank you Matt w, most appreciated and yes you’re right; I don’t feel foolish at all after seeing that. I haven’t yet encountered the phrase “encloses the noun” in the instructional documentation and I wouldn’t have figured that out on my own any time soon. Cheers! 
I’ve tested both the taking and the inserting, and each one works!
Merry Christmass everyone - have you noticed that today, the 25th Dec when Inform7 reports an error it displays a broken christmas decoration? 
Well, the “encloses” part isn’t really necessary – you could write “Instead of taking a thing when the noun is in the small metal case and the case glass is intact:” and it would probably work for your case. “Encloses” just takes care of things that are parts of things in the case, or in things that are in turn in the case, if you want to implement them. “Encloses” is discussed in section 3.25 of the Inform docs.
Merry Christmas to you too! It’s not December 25th in the States yet, but I’ll be sure to give myself a compiler error tomorrow.
I’ve been coding tonight (Dec 25th) as well… and Inform 7 rewards you with a giant, shiny red bauble (unbroken) if your code compiles correctly! 
Hurrah for the Christmas I7 elves!
FWIW the glass case is a textbook example of a situation where you could use the built-in transparent property. If you make the container closed and transparent, the player can automatically see what’s inside but can’t do anything to them that would require touching them. This has the added bonus of taking care of any other commands you might want to limit (touching, pushing etc). When the glass is broken make the container open and the player can interact with the things inside.
Ah, I had thought of that but decided it might be duplication of effort, since you probably want to write special rules (or parser error messages?) for reaching inside the case anyway. But preventing pushing and touching is a good idea anyway.
(What I mean is, if I comment out my instead rules and add this code:
[code]The small metal case is transparent and closed.
Instead of attacking the case glass:
say “Crash!”;
now the case glass is shattered;
now the small metal case is open.
[/code]
then I get this response:
where the first two responses are annoying. In fact, even if we add the “Instead” clauses back in we get this, because taking the extinguisher fails the basic accessibility rule before the “Instead” rule fires, so getting a nice message back in this case is going to require something more.
BTW, some unrelated user-friendly things – it’d probably be a good idea to understand “front” as the case glass and to redirect attacking the small metal case to attacking the case glass.
[Awesomeness: When testing this I got the following parser error:
with the special Dec. 25 broken ornament over it! Cool.]
Fair point. Fortunately “something more” in this case is just using a before rule, which fires before the basic accessibility rule. Or if you want to use accessibility rules (this might actually be the cleanest solution):
[code]A reaching inside rule for the metal case:
say “The glass front of the case prevents you reaching inside.”;
rule fails.
A reaching inside rule for the metal case when the case glass is shattered:
rule succeeds.[/code]
Oh, duh, thanks.
Looks neat – I’d forgotten about the reaching inside rules. The original author probably wants to code the first rule as “when the case glass is intact” and the second as the general rule, since I suspect you can reach inside the case when the glass is cut. In this case I guess we can write “allow access/deny access” instead of “rule succeeds/rule fails”?
Thanks Guys and Gals.
Is there a way to substitute “break” / “breaking” instead of “attack” / “attacking” the case glass?
It would be the more obvious verb for the player to figure out, but it seems that breaking is a word already in Inform7’s vocabulary, and it seems reluctant to alow a rule to override it. “Attacking” works just fine, but “breaking” produces the error:
You wrote 'Instead of breaking the case glass' , which seems to introduce a rule taking effect only if the action is 'breaking the case glass'. But that did not make sense as a description of an action. I am unable to place this rule into any rulebook.BTW I’ll be travelling from the 8th Feb to the 16th March and probably out of touch during that time. When I return I’ll commence a thread specifically for the project that I’ve been working on all this time - it’s taking me too long to suss out Inform7’s little quirks on my own. I’ve appreciated the friendly and generous assitance you people have given me, and hopefully it will be fun to involve you in the project more directly. (Albeit with the consequence of the end result not being the surprise that I’d planned, but what the hey. )
Actually it’s the opposite: breaking is a word that Inform doesn’t know and therefore doesn’t know what to do with it.
If you want only the command BREAK GLASS to work you have to make your own breaking action, but I wouldn’t do that: the attacking action already includes BREAK as a synonym, along with many others, so the BREAK GLASS command already works. If you make a new breaking action and the player types HIT GLASS or SMASH GLASS or something else they get the rather misleading “Violence is not the answer” response.
To elaborate a little, and hopefully accurately, there are two kinds of vocabulary here: The words that show up in your source code and the words that the player types. (The TL;DR is that “break glass” should work already; let us know if it doesn’t.)
In the source code, you have (for instance) names of actions, like “attacking.” If you wanted to use “breaking” in the source code you’d have to define a new action by saying something like “Breaking is an action applying to one thing” and then defining rules for it. But you don’t need to, because…
It doesn’t matter to the player whether your source code calls the action “attacking” or “breaking.” The player never has to directly deal with the words that appear in your source code, or the names of your actions. The words that the player types get translated into actions by the parser. Understand statements tell the parser how to do this translation. That’s why you often see code like this:
Twirling is an action applying to one thing. Understand "twirl [something]" as twirling.If not for the “understand” statement, the parser wouldn’t know that the command “TWIRL MUSTACHE” was meant to be translated into the action of twirling the mustache, and twirling would never happen.
In this case, as Juhana points out, “BREAK [something]” is already built in as a synonym for “ATTACK [something].” So your game will automatically understand “BREAK GLASS” as attacking the glass, unless you tell it not to. So you’re set.
(Specifically, this is the relevant part of the standard rules:
Understand "attack [something]" as attacking.
Understand the commands "break", "smash", "hit", "fight", "torture", "wreck", "crack", "destroy",
"murder", "kill", "punch" and "thump" as "attack".
The “Understand the commands…” part means that those words get mapped onto “attack” with all the attendant syntax. I suppose Graham could’ve put in
Understand "break [something] as attacking. Understand "smash [something] as attacking. [etc.]but it would obviously have been more tedious, and maybe there’s a difference I’m not picking up.)
Well said!
The difference is that “Understand the command…” makes the words themselves synonymous, regardless of the action. So if you created your own “attacking it with” action you could just define one grammar line, “Understand “attack [something] with [something]” as attacking it with”, and all the other verbs would automatically work with this new action as well.