Cheers all. Inform n00b here, all excited, banging my head against one Inform puzzle after another. My problem: I have an object which I want the player to figure out that they have to pry open (because there’s a thing in it the player needs, obviously). Thus I’m using a container. I know how to write the ‘instead’ rules which let me handle checking that they can open it only with a tool. But:
When the container (let’s call it a florb, as in ‘a florb is a kind of container’) is listed in inventory, it says (closed) after it! This sort of ruins my puzzle. I know I can use the “Rule for printing room description details of a florb: stop” trick so it won’t say this when it’s in the same room, but how do I override this when it’s in inventory? I found the ‘Oyster Wide Shut’ example and tried making “A property-aggregation rule for the florb” as per that (Ex.414) (Yes, I tried this in a test project where the florb wasn’t a kind but a specific container) but it doesn’t work. I tried:
However, it says on compile:
Is that example rule something that only works because it’s being declared as part of a wholesale replacement for the inventory listing rule? Is there a way to only override this info for this item, ideally for this item kind?
So…can anyone offer me hints on how to not give away to my player the fact that the florb is a container until they manage to open it? Many thanks indeed in advance.
The reason for the compile error is that you didn’t create a property-aggregation rulebook, so Inform could recognize property-aggregation rules. But then you’d need to invoke that rulebook for the rules in it to run. In “Oyster Wide Shut” that is done from the new print inventory rule that the example puts in the carry out taking inventory rulebook.
In short: yes, the property-aggregation rule will only work as part of the whole parcel.
But in this case there may be an easy way. Containers that are not openable will (thankfully) not be listed as closed. So maybe you could start out with your florbs closed but unopenable, and then make them openable when the players do what they need to do to understand that a given florb is a container that could be pried open.
[code]The Lab is a room.
A florb is a kind of container. A florb is usually closed.
The box is a florb.
The player carries the box. In the box is a beetle.
Instead of examining the box: [(or opening the box or attacking the box or unlocking the box with the crowbar or whatever)]
now the box is openable;
say “Hey! Looks like you could possibly pry this thing open.”
You, sir, are a scholar and a gentleman. Now I can finally go to bed and stop obsessing. It works! Hooray. I did something slightly different:
Instead of opening a florb:
if the noun is open, say "That's already been opened." instead;
unless the player is carrying a tool, say "You don't have anything to open it with." instead;
say "You pry open the florb.";
now the noun is disassembled;
now the noun is openable;
now the noun is open.
Since opening it damages it (it won’t close again, because I have an instead of closing rule that prevents disassembled florbs from being closed) I need to make sure to check that it’s disassembled once they’ve opened it. Also, I check to make sure they are carrying an appropriate tool (kind of thing).
many thanks again. Onwards! Now to try to shoehorn my game back down into Z-Machine memory limits. Just, you know, 'cuz. I know I’ve done flabby stuff, here.
It’s great that you found a solution that works, especially because it looks like you don’t want the florb to be openable at all!
Just for reference, if you wanted to accomplish this while still having the container be openable, I think you’d do this by using something like the following lines [ETA: mistake fixed]:
Rule for printing the name of a closed florb while taking inventory:
say "[printed name of the florb]";
omit contents in listing.
Rule for printing room description details of a closed florb: stop.
See sections 17.10 and 17.15 of the documentation, respectively. You’d probably also want to write some code that kept track of whether florbs had ever been opened, so you could make sure that after a florb had been opened and closed it would say “(closed)” after it.
But, as you’ve found out, if you just want the florb to be opened once and never closed again, making it unopenable is the way to go.
Matt - I want florb to only admit that it’s a container when the player figures out they need a tool to open it. After that, it’s a normal container (other than that you can’t close it once open).
The code you offered doesn’t quite do that - if the container is ‘openable’ then whenever you list inventory it’ll say (closed) after the florb’s name, which sort of gives away the puzzle. (A florb is an object not usually thought of as a container, in my case a plastic tag, and there’s a chip ‘embedded’ in it the player needs).
Once they’ve opened it once, it admits that it is open and I want it to indicate if there’s a chip in it. The description says “It’s been pried open, the plastic cut” and I use
Instead of closing a florb:
If the noun is open, say "That won't close. The damage looks permanent." instead;
Right, your code should work for what you want to do. I was trying to indicate a more general solution, though I got it wrong.
If you test this (which defines a single florb rather than a kind):
Test room is a room. The florb is a container in the Test room. The florb contains a fleeb. The florb is openable. The florb is closed.
Rule for printing the name of the closed florb while taking inventory:
say "[printed name of the item described]";
omit contents in listing.
Rule for printing room description details of the closed florb: stop.
then the florb won’t show up as “florb (closed)” in the room description or inventory. You’ll be able to open it and close it, since it’s defined as “openable,” but it’ll only reveal its container status once it’s open.
Oh, derp, I had totally missed your (more specific) room description rule. Which I only realized because sure enough I ran up against exactly that just now, and said “Wait, lemme see what he said again…”