Unable to make rule for locking?

I have this source code:

The Warehouse is a room.

A crate is a container in the Warehouse.
The crate is openable and lockable.

Instead of locking the crate:
	try closing the crate.
Test me with "lock the crate".

Whenever I try to run this I get an error:

Problem. You wrote ‘Instead of locking the crate’ , which seems to introduce a rule taking effect only if the action is ‘locking the crate’. But that did not make sense as a description of an action. I am unable to place this rule into any rulebook.

I’m not sure what I’m doing wrong, though. This is a variation on something in the manual.

The built-in locking it with action takes two nouns as in “lock crate with key,” so if you want to use it you have to say “Instead of locking the crate with something:” If you want the game to respond to “Lock the crate” you can define a new action that only applies to one thing and then redirect that to closing the crate. This code is untested:

Keyless locking is an action applying to one thing. Understand "lock [something]" as keyless locking. Instead of keyless locking the crate: Try closing the crate. Instead of keyless locking: say "You can't lock that."

…if you actually have things in your game you can lock normally, with keys, you’ll need to be a bit more sophisticated here to avoid annoying your player when they try “lock the door” and they need to try “lock the door with the key.”

Thanks. That makes sense. It seems odd that Inform makes it more complicated to lock/unlock something that doesn’t require a key (like a latch or something). The manual says that it tries to make the fewest possible assumptions and in this case the fewest assumptions is the need for a key. So that’s what tripped me a bit. But got it working now. Thanks.

There’s a separate extension (Locksmith by Emily Short) bundled with the IDE that adds more features for doors and locks, including keyless (un)locking actions.

Good to know. Thanks. I guess this is where intuitively I would have expected an extension to provide the more “complicated” behavior of requiring a key, versus what is to me the less complicated idea of not needing one. I’m getting a better feel now for what to start looking for. Thanks for the pointer.

I have a hunch that Inform considers a lock that requires a key the standard situation and latches and so on the special case, considering that the Inform library was written in a more puzzle-oriented time. Treasure chests that can be unlocked without a key don’t make very good puzzles.

I can see that. I guess I treat “locking” in a puzzle sense as more than just treasure chests. You can have locks that are electromagnetic, locks that are based on a keypad, locks that are based on magic spells, and so on. I guess that was my point. “Locking” can be very specific to an implementation of a puzzle so I would treat “locking” as a very generic action initially. But I see your point too. You may just have to pick some implementation and go with it and in that case “traditional lock with key” seems the best choice.

Well, it seems like a lot of those cases require the object to have the “locked/unlocked” property, but the locking it with action won’t do much for those. For the keypad, typing “UNLOCK DOOR” might not do anything; you want to have the player type “ENTER 123 on KEYPAD” or something. For the spell, you might want “CAST UNLOCK,” though maybe “UNLOCK DOOR” would work once the player has the unlock spell. For the electromagnetic lock – well, it would depend on the details, but you might want to use the same “UNLOCK DOOR WITH KEYCARD” action as if it had a key.

Now, in many of these cases if you have the key and type “UNLOCK DOOR” you get a very annoying message, “What do you want to unlock the door with?” (The key, duh.) I think Locksmith helps you take care of that – thanks for suggesting it, Juhana.

Anyway, I think you’re right; they had to pick something.

The built-in key behavior is copied from the Inform 6 library. Probably could have been rethought from scratch when I7 was being designed, but you can’t rethink everything from scratch.

(Even though I7 was a new language, the world model came from I6 and has been updated incrementally rather than being rebuilt.)