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âŚâ
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:
Now I can finally go to bed and stop obsessing. It works! Hooray. I did something slightly different: