I’ve had this problem a number of times, and I can’t remember if I’ve ever solved it. I think I’ve always just looked for a way to avoid doing it.
I’d like to define a verb “finding” that acts upon things that exist in the game. Obviously, you only try to find things you can’t see. But Inform worries about the fact that it can’t be seen before even moving on to my custom code.
[code]Finding is an action applying to one thing.
Understand “find [thing]” as finding.
Check finding: If the player can see the noun, say “It’s right here.” instead.
Carry out finding: say “Let’s have a look around.”[/code]
I’ve tried “Before finding” and “instead of finding when” and “Finding is an action applying to one invisible thing” and everything else I can think of.
I thought of using topics instead of things, but then I can’t differentiate responses for items that are and aren’t present.
When defining an action, the word “visible” means “in scope”, not literally visible. It includes objects which are placed in scope using a “Deciding the scope of something” rule as well as those allowed due to the use of the “any” token in a grammar line. (Ex. 268 “Introduction to Juggling” and uses this technique.)
However, you’ll probably want to qualify things to prevent the player from getting too much unintended information when finding things. Below I used a known / unknown property which just marks things as known the first time a player sees them. Also, I changed the parser error when finding to something a little more helpful.
(Edit: Now that I’ve built it, I see that ex. 360 “WXPQ” does most of the below as well – with the exception of the known / unknown bit.)[code]A thing can be known or unknown.
After printing the name of something (called it) while looking: now it is known.
Finding is an action applying to one visible thing.
Understand “find [any known thing]” as finding.
Check finding: If the player can see the noun, say “It’s right here.” instead.
Carry out finding: say “[The noun] is in [the location of the noun].”
Rule for printing a parser error when parser error is noun did not make sense in that context:
if we are finding, say “I don’t know what that is or how to find it.”;
otherwise say “That noun did not make sense in this context.”.
The lab is a room. The blue ball is in the lab.
North of the lab is the back. The red ball is in the back.
test me with “find ball / find red ball / find bicycle / n / find ball / get it / s / drop ball / n / find ball / red”.[/code]
I guess one could argue that “visible” does in fact mean literally visible (to the PC in the game) and that objects which are placed in scope using a “Deciding the scope of something” rule and those allowed due to the use of the “any” token become visible as a result.
After printing the name of something (called it) while looking: now it is known.
Can I use the word “it” like that in more than one rule, or will they interfere with each other? I’m always thinking of stupid words for those rules (like After printing the name of something (called the printedthing)) and “it” certainly does read better…
Yes. Variables created using “called” are local, i.e. created, used, and then destroyed by the rule in question. I usually use something simple like “it” when the rule is a one-liner and the meaning is clear. In more complex rules, I use more descriptive names like you mention above.
[code]A thing can be known or unknown.
After printing the name of something (called it) while looking: now it is known.
The player is carrying a turtle.
Finding is an action applying to one visible thing.
Understand “find [any known thing]” as finding.
Check finding: If the player can see the noun, say “It’s right here.” instead.
Carry out finding: say “[The noun] is in [the location of the noun].”
Rule for printing a parser error when parser error is noun did not make sense in that context:
if we are finding, say “I don’t know what that is or how to find it.”;
otherwise say “That noun did not make sense in this context.”.
The lab is a room. The blue ball is in the lab.
North of the lab is the back. The red ball is in the back.
test me with “find turtle / i / find turtle”.[/code]
Hm. I understand that the rules for when a thing is known could be tweaked a little, to include things that are carried and things that have been examined. And I can handle that part. However, why is it firing the default parser error instead of the “finding” parser error?
Edit: This fixed it.
Finding is an action applying to one visible thing.
Understand "find [any thing]" as finding.
From here I guess I can tailor responses or check statements according to whether the thing is known.
Ahh, no, I think that’s not correct. “visible” means “visible somewhere in the model world”. It specifically doesn’t relate to scope. The usage is simply backwards from what one would expect. You can test this with the following code:
[code]Acquiring is an action applying to one visible thing. Understand “acquire [any thing]” as acquiring.
Check acquiring:
if the player holds the noun, say “You’ve already got that!” instead.
Carry out acquiring:
now the player carries the noun.
Report acquiring:
say “As if by magic, you find yourself holding [the noun].”[/code]
This magic spell will acquire anything in any room, even rooms distant from the player. But: If you comment out the word “visible”, you’ll get an error message that the player can’t reach into the distant room.
Ergh! I said I could handle it, but apparently I lied.
None of these things work to make a carried thing known?
[code]After printing the name of something (called it) while taking inventory: now it is known. [not desirable anyway, would rather it was already known before taking inventory]
Carry out taking something (called it): now it is known.
After the player taking something (called it), now it is known.
This is the carriedthing rule: If the player carries something (called it), now it is known.
This is the carriedthing rule: If the player is carrying something (called it), now it is known.
This is the carriedthing rule: If the player is carrying a thing (called it), now it is known.
This is the carriedthing rule: If a thing (called it) is carried by the player, now it is known.
Definition: A thing is known if the player is carrying it. [works but makes other rules not work, which makes sense][/code]
This works:
Carry out examining something (called it): now it is known.
The “After printing the name of something” rule wasn’t working well enough for me, because I copiously use “Rule for writing a paragraph about the front door: now the front door is mentioned.” so that I can integrate descriptions into my narrative.
Actually, Mike is right. The “acquire [any thing]” creates a new scope routine for this grammar line, which means that the definition of scope is temporarily altered. When you remove “visible” from “applying to one visible thing” you’re saying that it’s not enough that the noun is visible, it must be touchable as well. The scope routine puts all things in the game in scope, but since the action is defined as requiring a touchable noun you get an error (like “You can’t reach into the distant room” if the noun is in another room, or “You can’t, since the glass container is closed” if it’s inside something).
I’d just like to point out a trap here. When the parser error is about to be printed, the action variables haven’t been updated: they are still set to whatever they were on the last turn. So we can’t test whether “we are finding”, but must instead do something like “if the player’s command includes “find”, say…”
What’s annoying about this situation is that by inserting an extra qualifier (“visible”) in your code, you’re actually removing a qualifier that is active but only implied in the code, not stated. I can see why Graham would have done it this way – to save typing by letting the user write simple code for the most common situation. All the same, it’s bass-ackwards.
That’s right SJ, my bad. This is why Shae wasn’t getting it to work right above.
As far as this:
This works fine for me, although I’d probably shorten it to:
Carry out taking: now the noun is known.
However, you’re right that is doesn’t cover all the bases. I haven’t tested this extensively, but an after doing something rule to make all visible things known (see below) seems to work. (I made it a "first rule so it wouldn’t be circumvented by any other after rules. Also make sure to “continue the action.”) I also added a when play begins rule to cover things enclosed (directly or indirectly) by the player at the start of the game. This will cover things initially enclosed by the player but not visible because they’re inside a closed container, but not stuff inside similar containers which are picked up later until they are revealed by opening the container. Is this better?[code]A thing can be known or unknown.
First after doing something:
now everything visible is known;
continue the action.
When play begins: now everything enclosed by the player is known. [note “enclosed” – not carried]
Finding is an action applying to one visible thing.
Understand “find [any known thing]” as finding.
Check finding: if the player encloses the noun, say “You’re carrying it somewhere on your person.” instead.
Check finding: if the player can see the noun, say “It’s right here.” instead.
Carry out finding: say “[The noun] is in [the location of the noun].”
Rule for printing a parser error when parser error is noun did not make sense in that context:
if the player’s command includes “find”, say “I don’t know what that is or how to find it.”;
otherwise say “That noun did not make sense in this context.”.
The lab is a room. The blue ball is in the lab. The purse is a closed, openable, opaque container carried by the player. The coin is in the purse. The box is a closed, openable, opaque container in the lab. The bat is in the box.
North of the lab is the back. The red ball is in the back.
test me with “find box / find purse / find coin / find bat / get box / find bat / open box / find bat / find ball / find red ball / find bicycle / n / find ball / get it / s / drop ball / n / find ball / red find bat”.[/code]
I should have clarified. Yes, it works for taking something, but it wasn’t working for a thing that the player carried from the start of the game. I had announced the thing in the intro, so it was silly to let it behave like an “unknown” item.
I will try what you added, which should handle that case. Thanks so much for all the help!
