Good points.
Check presenting something (called the presented) to someone (called the presentee) when the presentee encloses the presented: instead say "[The second noun] [seem] familiar with [regarding noun][them]."
Check presenting someone (called the presented) to someone (called the presentee) when the presented is the presentee: instead say "[The second noun] [seem] familiar with the subject."
But there are probably other issues I also haven’t thought of.
Here’s what I have so far. It seems to work:
Understand the command "show" as something new.
Presenting it to is an action applying to two things. Understand "show [something] to [something]" as presenting it to. Understand "show [something] [something]" as presenting it to (with nouns reversed).
To show is a verb.
Check presenting it to:
if the second noun is not a person:
say "Not surprisingly, [the second noun] [show] little reaction." instead;
else if the second noun is the noun:
say "I'm sure [the second noun] [are] already self-aware." instead;
else if the second noun carries the noun:
say "[regarding the second noun]It's not hard to guess that [the second noun] [are] already aware of [the noun]." instead;
else if the noun is yourself:
say "You're already visible." instead;
else if the second noun is yourself:
say "You already seem to know about [the noun]." instead.
To nod is a verb.
Report presenting it to: say "[The second noun] [nod] politely."
This is not quite right, because of the tricky grammar around the player character:
>show me the screwdriver
It's not hard to guess that yourself are already aware of the screwdriver.
Nonsense removed.
edit: Nonsense reinstated, since it had been replied to:
Is this:
Instead of showing Mount Fuji to Mr Vance:
try asking Mr Vance about Mount Fuji.too simplistic?
[Quite apart from Jim’s considerations below, it wouldn’t work because asking someone about requires a topic, not a thing. And there would be no advantage over solutions already given above anyway.]
It would work in many situations, I’m sure. In the particular moment in the story I’m constructing, no. It would be a spoiler to explain why, but showing (as in, pointing out something that’s in the room) is necessary.
I can’t read your mind, but this reminds me of our other small exchange about faking it under the hood. @jrb 's suggestion seemed to immediately make sense in that light. (EDIT: but it doesn’t answer a bunch of other problems apparently…)
In this case, if the player types SHOW MOUNT FUJI TO MR VANCE and the game runs an ask-about command you prepared for this instance under the hood instead but responds as if the PC had pointed to that object in the room, why would that not be equivalent?
I may be in the minority but “wacky verb terminology” is part of the fun of I7 for me…
Inform’s expected syntax is:
The carrying requirements rule does nothing when <condition>.
The condition can be formulated in various ways, including the general case (when showing).
See also the example “Lollipop Guild” in the documentation at 18.34: Implicitly taking something, which covers what seems to be this scenario (overriding the implicit taking in the course of showing something to someone).
Some variants for illustration:
The Lab is a room. Alice is a person in the Lab. Bob is a person in the Lab.
The machine is in the Lab. The machine is fixed in place.
The apple is in the Lab. The apple is edible.
The carrying requirements rule does nothing when showing the machine to Alice.
The can't show what you haven't got rule does nothing when showing the machine to Alice.
[or:]
[The carrying requirements rule does nothing when showing the machine to someone.
The can't show what you haven't got rule does nothing when showing the machine to someone.]
[or:]
[The carrying requirements rule does nothing when showing something to Alice.
The can't show what you haven't got rule does nothing when showing something to Alice.]
[or generally:]
[The carrying requirements rule does nothing when showing.
The can't show what you haven't got rule does nothing when showing.]
The block showing rule does nothing.
Report showing:
say "[The second noun] [say]: 'Hmm, interesting.'"
Test me with "show machine to alice/show bob machine/show machine to me/show apple to alice/eat apple".
If I remember right, many conversation extensions handle this the “presenting” way: making a new action to show something that doesn’t require it to be taken.
Personally, I’d disable the rule “when the noun is not portable”.
The can't show what you haven't got rule does nothing when the noun is not portable.
This means you still have to pick something up to show it if it’s portable, but can point at it without picking it up if it’s too big. I think the default conception of “showing” involves picking something up in your hand and holding it out to the NPC, but pointing at it in the distance makes just as much sense to me.
You could just redirect the player to use POINT AT, I guess?
The can’t show what you haven’t got rule does nothing when the noun is not portable.
This doesn’t buy anything: one is still up against the Understand lines and action specification.
Understand "show [someone] [something preferably held]" as showing it to (with nouns reversed).
Understand "show [something preferably held] to [someone]" as showing it to.
Showing it to is an action applying to one carried thing and one visible thing.
You’re referring to this, I assume:
The showing it to action translates into I6 as "Show".
Can anyone tell me what this line in the Standard Rules actually does, if anything? All the code for the built-in actions (or most of them, at any rate) is right there in the SR, so I’m not sure what the references to I6 are needed for.
By the way, the specification for the showing it to action begins:
Anyone can show anyone else something which they are carrying, but not some nearby piece of
scenery, say - so this action is suitable for showing the emerald locket
to Katarina, but not showing the Orange River Rock Room to Mr Douglas.
So it looks like you’re expected to create a new action to do what you want to do.
I took Jim to be referring to the carrying requirements rule (The carrying requirements rule translates into I6 as "CARRYING_REQUIREMENTS_R".)
Or leverage the existing definition and override the carrying requirements rule and the can't show what you haven't got rule, as per my post above and the example Lollipop Guild from the docs.
It’s basically the same as the lines translating I7 variable names to I6 variable names. If you look through the Actions template you’ll see ##Go, ##Look, etc. ( I6 uses the ## sigil to indicate an action identifier). So this just establishes that the action I7 calls the showing it to action is the same thing as the action that I6 calls ##Show.
Author-created actions get them too, with uglier names like ##A_singing. And the template layer/kits actually only refer to a few of these for some special-case purposes. That’s why it’s never seemed like you were missing out on anything by not having the equivalent in your code – you weren’t.
If one also adds an override for the carrying requirements rule as per the variants I mentioned above (which I thought Draconis to be tacitly assuming/endorsing), it does achieve the desired behaviour, as far as I see?
This is the key, yeah. Some of the kits invoke specific actions from I6 code, and to do that, those actions need fixed names in I6.
I haven’t found anywhere that ##Show is invoked, and Github’s search function ignores the # character which makes it hard to find. But it’s possible it’s just given an I6 name in case it’s needed in the future (or in a custom kit).
Thanks Zed, Draconis; so it sounds like most of these lines are effectively redundant. I thought that might be the case.
Ah yes, of course. (Jim’s post is completely clear, but I confused myself.)
Yes, the Lollipop Guild example is making the “showing it to” action do the exact thing which the action specification says it isn’t suitable for.
Finding solutions to things like this in the documentation, particularly when mentioned only in the examples rather than the main text, is definitely a skill with a learning curve.
In this case, searching the documentation for ‘carrying requirements rule’ would have immediately led to the ‘Lollipop Guild’ solution…
Yeah, you’re right, the docs are a bit contradictory/misleading in that regard.