I’m still trying. I really want this to work. But I still can’t get “does the player mean” to do what I want. Here’s a bizarre situation:
[code]Kitchen is a room.
Freezer is a room.
The steel door is a door. It is lockable. It is west of the Kitchen and east of the Freezer.
A steel key is in Kitchen. The steel key unlocks the steel door.
The player carries a chef’s knife and a beef tenderloin.
The carrying capacity of yourself is 2.
Does the player mean locking or unlocking the steel door with the steel key: it is very likely.
test me with “lock door/drop knife/lock door”[/code]
I’ve tried adding other “does the player mean” rules, and I’ve tried using a couple rules from Disambiguation Control, but nothing seems to make a difference. How can I get the game to ALWAYS choose the steel key?
The grammar for the locking action specifies that it applies to a carried thing, and it seems that Inform thus looks only at the player’s inventory for potential disambiguation matches. One solution would be to hack the grammar for the command so that it could apply equally to carried or visible things.
Understand "lock [something] with [steel key]" as locking it with.
Understand "unlock [something] with [steel key]" as unlocking it with.
In the general case, where you have a lot of keys: make a “key” kind, and use
Understand "lock [something] with [a key]" as locking it with.
Understand "unlock [something] with [a key]" as unlocking it with.
What’s happening in your situation is that some of Inform’s internal disambiguation rules are firing in an order that overcomes your own disambiguation rules. It’s trying to match against a carried object in the player’s hand, and when there’s only one of those, it doesn’t check does the player mean to further grade carried objects vs uncarried objects; it just chooses the tenderloin.
A way to get around this is to make a more specific grammar line. Because “a key” or “the steel key” is more specific than “a preferably held thing”, Inform will try to match the grammar lines to do with keys first. Only when those failed would it go to trying out the tenderloin. So the player can still type UNLOCK DOOR WITH BEEF if he’s sufficiently hard-headed, but Inform won’t assume that any more.
Or make the library’s grammar line more general, which is what ektemple suggested.
My experience is that trying to force disambiguation at the grammar level (rather than the “does the player mean” level) always causes more problems than it solves.
Well, the library grammar in this case has caused this thread with its further workarounds.
If you mean “this case” as in your solution, I don’t know of anything that will go wrong with it. But it seems like the more you pre-empt library disambiguation with grammar, the more you have to keep doing it. I think it also leads new authors to create “newverb [myobject]” grammar which is not backstopped by a general “newverb [something]” verb, which is definitely bad.
My experience is just the opposite – that the method I suggested reliably gets me what I want to have happen when I know exactly what kind of object I want plugged into the player’s command; there’s enough potential overlap between the effects of “does the player mean…” rules that I prefer to use that only for fuzzier cases, or where I’m establishing a preference to work across multiple verbs.
I think you’re both right. Every verb should have a fallback grammar so you see “you can’t frob a grubnitz” instead of “that noun did not make sense in this context,” or a ridiculous disambiguation situation. But once a fallback grammar is in place, a more specific grammar can only help.