Grr… Probably most simple, but I don’t get it. I have an “entry gate” and a “gate key”, and I’d like to keep those names, if only to understand some mechanics.
(the gate key with the gate key)
That doesn’t seem to be something you can unlock.
unlock entry gate
(with the gate key)
That doesn’t seem to fit the lock.
1.) How do I sort or prioritize items so that the first assumption (“unlock gate key”) is replaced by a better one (“unlock entry gate”)?
2.) How do I overwrite the system report (“doesn’t seem to fit”) with something different (“Although… doesn’t match… perhaps…”)?
Have you looked at the Locksmith extension? That might help with some of your issues.
As for disambiguation, that’s just a matter of hard work. It’ll always be hard to disambiguate - to the extent where I might even leave the word “gate” out of the actual object name:
The gate-key unlocks the gate. The printed name of the gate-key is "gate key". Understand "key" as the gate-key.
You might want to check out Jon Ingold’s Disambiguation Control extension.
A quick way to keep the parser from trying to unlock something with itself if other interpretations are available:
Does the player mean unlocking the noun with the noun: it is very unlikely.
Thanks for the answers. I’ll be needing enough extensions later on, so I’ll try the latter one.
In this particular case it might be good to be more specific:
Does the player mean unlocking the gate with the key: it is very likely
Will this actually produce any different results? Or is it just better from a standpoint of source-code readability?
And shouldn’t something like the former be a part of the Standard Rules? Or is that too specific?
The first one doesn’t distinguish between unlocking the gate with the key and unlocking the key with the gate.
I’d probably add an additional rule as well (or instead) for trying to unlock other things with the key:
Does the player mean unlocking something with the key: It is very likely.
I would hope that the Locksmith extension would handle things like this - I think that’s the reason it’s included in the I7 distribution.
For the second issue:
An instead rule should do it. I think the required conditions for when it should fire would be as follows:
Instead of unlocking something with something when
the noun does not provide a matching key or
the matching key of the noun is not the second noun,
say "Although... doesn't match... perhaps...".