I’ve included Locksmith by Emily Short in one of my games, but something in the extension is giving away one of the puzzles.
When the player types “open box” a rule called “the second noun autotaking rule” kicks in and tries to take the matching key of the box which is in another container that is itself closed and locked. The container is not transparent and the player should have no idea that the key is in there, yet the extension ploughs on heedlessly and tries to open the second container.
There seems to be nothing in the second noun autotaking rule that checks whether the second noun is visible. So I’d like to alter it, but I don’t know which rulebook it’s in.
Here’s some code which reproduces the problem:
"Hotel Safe" by "J. J. Guest"
Include Locksmith by Emily Short.
The hotel room is a room.
A safe is a locked container in the hotel room.
The matching key of the safe is the safe key.
The player carries a cashbox. The cashbox is locked. The safe key is in the cashbox.
Here’s the resulting output:
>open safe
(first unlocking the safe)
(first taking the safe key)
The cashbox isn't open.
Without holding the safe key, you can do nothing.
Sorry, on way to work. Should be self-explanatory:
Include Locksmith by Emily Short.
The hotel room is a room.
A safe is a locked container in the hotel room.
The player carries a cashbox. The cashbox is locked. The matching key of the cashbox is the red key. The player carries the red key.
The strange key is in the cashbox. The description is "[one of]Looking at it closely for the first time, you realize it must be [or]It is [stopping]the safe key.".
After examining the strange key for the first time:
now the matching key of the safe is the strange key;
continue the action.
test me with "open safe / open cashbox / unlock safe / x strange / unlock safe / x strange."
Now that I’m home (on break) I see a hole in the implementation. Trying to unlock the safe with the strange key before examining it results in a “The strange key does not fit the safe” message, which of course won’t do. Adding this takes care of that situation:
Before unlocking the safe with the strange key when the strange key is not the matching key of the safe:
say "Holy smokes! The key fits.";
now the matching key of the safe is the strange key;
continue the action.
test key with "open cashbox then get strange / unlock safe / unlock safe with key / strange".
Note that this rule only fires when the key is explicitly tried. Locksmith won’t try it implicitly until it is actually declared the matching key.
Ok, not perfectly. I forgot about when the key is visible but doesn’t successfully get implicitly taken. For example when it’s in a locked, transparent container, the rule will fire even if the key hasn’t been obtained, making for a nonsensical response. Nix that last before rule I added above and replace with:
The cashbox is transparent.
Before unlocking the safe with the strange key when the strange key is not the matching key of the safe:
if the strange key is carried or the strange key is touchable:
now the matching key of the safe is the strange key;
[we don't want to print anything here because with the implicit actions it will be out of order]
continue the action.
After unlocking the safe with the strange key:
say "[one of]Holy smokes! The key fits.[or][run paragraph on][stopping]";
continue the action.
test key2 with "unlock safe with strange / open cashbox / unlock safe / unlock safe with strange / lock it / unlock it".