I had thought that if a thing was not in a location, it couldn’t be taken. But while testing it I have found that if the player just types ‘Take [thing]’, it will become taken. So is there a way to have something hidden in a room and untakable until the player performs certain actions?
After pushing the Snake button:
say "A long rectangular section of the wall here pops open revealing a knobby wooden cane";
Now the Knobby Wooden Cane is in the location.
I’m sure there are better ways, but I can think of 2:
1.) A check rule:
A thing can be revealed.
After pushing the snake button:
now the section of wall is revealed.
Check taking the cane:
if the section of wall is revealed:
continue the action;
otherwise:
stop the action.
2.) Moving the cane to the location after the wall is revealed:
There is a cane. The description is....
After pushing the snake button:
now the cane is in the location of the player.
Or giving the cane itself a revealed property.
Now that I’m looking at this, option 2 presents this problem: if the player ever pushes the snake button again, the cane will go back there. So you’d have to address that.
Just changing to “after pushing the snake button for the first time” should fix that. Also wanted to flag that when implementing this for real, there should definitely be Say commands laying out what’s happening (or, in the case of the stop the action command, not happening) to make sure the player knows what’s going on.
Going back to the original question, it is the case that the player can’t take an object that isn’t in the same location unless there’s a special rule that’s allowing it. So if you’re running into this issue, I’d definitely do some testing to figure out what’s going on – is the object not where it’s supposed to be, or do you have some other rule putting it into scope inappropriately? If so, you might run into issues beyond just this one you’ve identified!
As Amanda and Mike pointed out, the After rule you wrote will always move the cane to the location even if the player has already found it and thrown it off the Cliff of Despair. Mike’s “for the first time” works great in an After rule. Another solution would be to remove the button from the location after the player finds the cane just so they won’t mess with it again.
After pushing the Snake button:
say "A long rectangular section of the wall here pops open revealing a knobby wooden cane.";
Now the Knobby Wooden Cane is in the location;
say "The cane falls out and clatters on the floor as the rectangular section of the wall closes. It and the button both vanish as if they were never there.";
Now the Snake button is off-stage.
Mike’s suggestion is probably right why things are moving around mysteriously - one of your rules is likely moving an object at a time when you’re not expecting it to. This can notoriously happen if you change world state with INSTEAD rules since they skip other normal checking and parsing rules.
How do I give a thing a revealed or unrevealed property?
With “now ... is revealed”, as Amanda said:
But just to be clear, “revealed” is not a built-in property of things. If you try that approach, you’ll have to add rules to tell Inform what should happen or not happen with regard to (not) revealed things.
Amanda’s second solution (starting with the cane out of play, and simply moving it to the location at the right time) is, as Mike and Hanon have also said, a good way to proceed in your given scenario, and simpler than adding new properties and rules.
It should definitely work, and I’ll reiterate the advice that if the player can somehow take an object that’s not in the location, then that’s something you should try to troubleshoot, preferably with a minimal example that’s showing the strange behaviour.
Here’s a minimal example where it works as it should (that is, you can’t take the cane until it’s actually in the location):
The Lab is a room.
The cane is a thing.
After jumping for the first time:
say "A cane materializes out of nowhere!";
now the cane is in the location.
Test me with "take cane/jump/take cane".
I don’t know what I’m doing wrong. Here’s another example that apparently isn’t keeping anything not revealed either.
Any ideas where I’ve misstepped?
Locke's Hand is part of the statue.
Locke's Hand is a container.
Locke's Key is a thing. It is inside Locke's Hand.
Locke's Key can be revealed.
Locke's Key unlocks the dirty door.
After examining Locke's Hand for the first time:
now Locke's Key is in the location;
now Locke's Key is revealed.
With this line, you are placing the key inside the location again. The idea was to start out with the key completely out of play. And you don’t need the “revealed” lines.
Try this:
The Lab is a room.
The dirty door is a door. It is locked. It is east of the Lab and west of the Annex.
The statue is in the lab.
Locke's Hand is part of the statue.
Locke's Hand is a container.
Locke's Key is a thing.
Locke's Key unlocks the dirty door.
Before examining Locke's Hand for the first time:
now Locke's Key is inside Locke's Hand;
You can make objects without putting them in any location. Just say:
There is a key. The description is...
or
The key is a thing. The description is....
The key is now part of the game, but it is not in any place yet. When you’re ready for it to appear, move it to where you want it to be.
I had a hard time with this, too.
The revealed property doesn’t do anything until you implement code to make it do something. Here’s an easy way to make it do something:
A thing can be unrevealed or revealed. A thing is usually revealed.
Rule for deciding the concealed possessions of a thing when the particular possession is unrevealed (this is the unrevealed concealment rule): yes.
There are two principal built-in methods to keep a player from referring to something: concealment, and having it not be in the same room as the player at all until you want the player to be able to refer to it. If either of these apply, the player will get a “You can’t see any such thing.” error, same as if they typed take snthcrhuc.
I’ll note for completeness’ sake and a cautionary tale, that there’s also a straightforward way to let the player refer to absolutely any thing in the game, even if it’s out of play…
Understand "take [any thing]" as any-taking.
Any-taking is an action applying to one visible thing.
Before any-taking, try taking the noun instead.
With that code in place, if you try taking something not in the location (even out of play) you’ll get a “That isn’t available.” error. If you try taking a concealed thing that’s touchable, it’ll simply work (unless there’s some other reason you can’t take it).
Scopability by Brady Garvin is the most surefire way I know to absolutely positively keep something out of scope… which can be handy to absolutely positively guarantee that disambiguation questions can’t telegraph the existence of something. This generally shouldn’t be necessary if you haven’t written any Understand lines with [any thing] and are keeping things you don’t want the player referring to out of the location or making sure they’re concealed. And if things have names the player shouldn’t know about, make the Understand assertions regarding those names conditional (e.g., assuming discovered is something you’ve defined):
Understand "magic/wand" as the plain old stick when the plain old stick is discovered.
Without changing other things, concealed things do reveal or imply their existence in a couple of places:
The most unfortunate is that if you take a supporter or container that conceals things, the concealed things will be listed by name in your inventory. They’re still not in scope and the game will tell you you can’t see any such thing. This is an issue worth fixing if you have portable things that conceal things.
And then there are a couple of things that telegraph information, but only to some I7 coders: a scenery supporter with only concealed things on it gets its own paragraph in room descriptions to say it has nothing on it. If you examine a container or supporter with only concealed things you get “In/on the (whatever) is nothing” in addition to their descriptions, if any; if it truly has nothing in/on it, you get “The (container) is empty” for containers and no additional statement for supporters. And if you open a closed container containing only concealed things, you get “You open the (container), revealing nothing.”; if it’s truly empty, you get “You open the (container).”
Thank you! Now I understand! Totally worked.
Probably worth also mentioning that the concealment rules get checked a lot. I’m not sure at what point in the real world it might become a pain point, but it seems possible that a generic concealment rule like I gave above could eventually slow things down if you had a lot of NPCs/containers/supporters in a location.
If only a couple of discrete things in the game ever conceal things, I’d give those things by name their own rules “for deciding the concealed possessions of” instead of using a generic rule like above.
This seems to do the job:
The print standard inventory rule is not listed in any rulebook.
Carry out taking inventory (this is the concealing print inventory rule):
if the first thing held by the player is nothing begin;
say "[text of print empty inventory rule response (A)][line break]";
else;
say "[text of print standard inventory rule response (A)]";
list the contents of the player, with newlines, indented, including contents, giving inventory information, with extra indentation, listing marked items only, not listing concealed items;
end if.