Grammar lines in wrong order!

I can’t believe I never encountered this problem before. Maybe I did, and just forgot how I dealt with it.

I want to create an action for “show X to Y” that doesn’t have a carried requirement. But this fails to override the builtin grammar lines:

[code]Section - Pointing it Out To

Pointing it out to is an action applying to one thing and one thing.

Understand “show [something] to [something]” as pointing it out to.
Understand “show [someone] [something]” as pointing it out to (with nouns reversed).
Understand “point out [something] to [something]” as pointing it out to.
Understand “point [something] out to [something]” as pointing it out to.

Report pointing something out to:
say “You indicate [the noun] to [the second noun].”

The specification of the pointing it out to action is “This action is like showing it to, but it allows the player to show something that is not carried.”

Section - Test Scenario

Studio is a room.

An easel is fixed in place in Studio.

Bob is a man in Studio.

test me with “show easel to bob/point out easel to bob”

What can I do?

Understand the command "show" as something new.

Thanks, Jim!

There’s something slightly counterintuitive about “something new.” I had gotten to the point where I was thinking that all it did was destroy command synonym links. But it appears to do more than that. Can anyone explain exactly how it works?

For example, if I declare “show” as something new, will it ever match the original “showing it to” grammar lines? Can I recreate my own “showing it to” action, leaving out the carrying requirement?

Hmm… “present” and “display” still match the grammar lines for showing it to. So I guess “something new” does two things: It splits the word out of the synonym set it belongs to, and it also removes it from any grammar line it was in before.

To fully recreate the grammar, I have to do this:

[code]Understand the commands “show” and “present” and “display” as something new.

Pointing it out to is an action applying to one thing and one thing.

Understand “show [something] to [something]” as pointing it out to.
Understand “show [someone] [something]” as pointing it out to (with nouns reversed).
Understand “point out [something] to [something]” as pointing it out to.
Understand “point [something] out to [something]” as pointing it out to.

Understand the commands “present” and “display” as “show”.[/code]

This is one of the weaknesses of Inform 7, in my opinion. In Inform 6 you can simply add your own grammar line to a verb and make it the first line, so that the player’s input will be tested against it first, after which, if there is no match, the parser will “fall through” to the existing library grammar. To get the equivalent functionality in I7, you have to obliterate the library’s grammar lines for that command and then recreate manually the functionality that you have obliterated.

I could be misrepresenting the situation. It’s been a while since I did anything with I7. I’m sure someone will swiftly correct me if I’m wrong. But that’s my best recollection of what “understand … as something new” does.


Could also do it this way. Not sure which is better, but this takes care of PRESENT and DISPLAY automatically.

[code]Procedural rule while showing:
ignore the carrying requirements rule;
ignore the can’t show what you haven’t got rule.

Understand “point out [something] to [something]” as showing it to.
Understand “point [something] out to [something]” as showing it to.

Instead of showing something to someone:
say “You indicate [the noun] to [the second noun].”;
rule succeeds.[/code]

Far be it from me to make a judgment, but I think the fact that they’re deprecated would indicate that using procedural rules is worse.

However, identifying those two rules might be enough to replace them within their rulebooks. I was a bit hazy on those early action-processing rules. When the “does not apply” rule syntax comes out, it will perform the same function as procedural rules, so your solution will work very well with a minor syntax change.

Trojo has inspired me to come up with a more general solution:

[code]Eating is flexible about touchability.

An action-processing rule (this is the flexible carrying requirements rule):
If flexible about touchability, continue the action;
abide by the carrying requirements rule.

The flexible carrying requirements rule is listed instead of the carrying requirements rule in the action-processing rules.

Wimbledon Stadium is a room. A giant blancmange is a fixed in place edible thing in Wimbledon Stadium.

Test me with “take blancmange/eat blancmange”[/code]

That is a very sweet solution. Do you think it would be worth packaging into a tiny extension?

I’ve been thinking about that all afternoon. Questions:

Should I split up carried noun and carried second noun requirements into separate rules, so they can be overridden separately?

Should I create similar KoAs that cause accessibility rules to be overridden as well? It looks like accessibility requirements are handled slightly differently.

At one point I went off on a wild tangent, thinking about rewriting the entire Actions.i6t in I7… “if Ron can rewrite the whole parser, I can do it with one little template!” But then I looked over the file and saw how much low-level stuff I’d have to reimplement for no particular gain. If I were going to rewrite anything, I think it would be the builtin actions in the Standard Rules.