Making a door lockable/unlockable from one side only

Firstly, I’m new here, so hello!

Secondly, my question is basically what I put in the subject: I want a door to be lockable and unlockable from one side but not the other. That is, there is not even a keyhole or lock on one side of the door, so it should act as it were not lockable at all from that side.

I have been able to achieve the basic functionality with a Before statement–that is, preventing the player from locking or unlocking the door from one side–but the problem is that the game still runs the command clarification before doing this. So, for example, if I type “unlock door” while standing on the wrong side, the game will either come back with “What do you want to unlock the door with?” or it will give me a command clarification parenthetical before printing the message that there is no lock on this side. Desired behavior is for the game to reject all the attempts to unlock the door from that side, before even running a clarification check. So when I type “unlock door,” it should immediately come back with “There is no lock/keyhole on this side of the door.” or “The door can’t be unlocked from this side.” To the best of my knowledge, though, nothing comes before “Before,” so I’m not sure what I need to do here to circumvent the standard behavior.

I did take a look at Emily Short’s Locksmith extension to see if I could figure something out based on that (particularly the locking/unlocking keylessly stuff), but unfortunately my Inform Fu is weak (that is, I’m still trying to get a handle on the language). I imagine that this can’t be too hard to do, since it seems like a pretty basic thing. After all, all doors in rooms meant for detaining the occupants act this way.

Thanks in advance for any help, and apologies for asking what is probably a stupid question.

This isn’t trivial at all. The problem is that you’re trying to affect the way the parser operates, rather than adjust the world model. The parser is the murkiest and least tractable part of Inform, or at least I find it so.

There are (at least) two activities you need to modify. The first is the “asking which do you mean” activity, which is the one which asks things like “Which do you mean, the iron key or the brass key?” when you type an ambiguous command (such as “LOCK DOOR WITH KEY” when you’re carrying two keys).

The Cell is a room. The iron door is a door in the cell. The iron door is north of the cell. Through the iron door is Freedom. 
The iron door is locked. The matching key of the iron door is the iron key. The player carries the iron key.
The player carries a brass key.

Rule for asking which do you mean when locking with in the cell:
	say door refusal.
Rule for asking which do you mean when unlocking with in the cell:
        say door refusal.

To say door refusal:
        say "There's no keyhole on this side."

(Unfortunately we can’t specify which door the rule applies to, because the parser hasn’t yet worked out the details of the action at the time this rule fires. This might be an issue if there are two doors in the cell.)

Then there’s the response you get when you just type “LOCK DOOR” without including a second noun at all. By default the parser will just print “What do you want to unlock the door with?”, unless you’re only carrying one thing, when it will say e.g. “(with the iron key)”; in either case, there’s no opportunity for you to intervene. So to bring this command into the scope of our rules, we have to define new grammar tokens:

Understand "lock [something]" as locking it with.
Understand "unlock [something]" as unlocking it with.

Now when the parser receives “LOCK DOOR”, it refers it to the “supplying a missing second noun” activity, which we can write rules about.

Rule for supplying a missing second noun when locking the iron door with in the cell:
	say door refusal.
Rule for supplying a missing second noun when unlocking the iron door with in the cell:
	say door refusal.

The other activity which might come into play is the “clarifying the parser’s choice of something” activity, which reports which object has been chosen in ambiguous cases where you’ve given the parser explicit guidance what to do in your code. So this won’t arise unless you’ve written a rule such as “Does the player mean unlocking the iron door with the iron key: it is likely.”

Thanks! That’s some great information!

I’m glad to learn that this is non-trivial, because I feel slightly less stupid now. I’m also glad that I can parse your instructions. I don’t think I would have been able to figure that out for myself, though.

Thank you again!

As far as I can tell, the only easier alternative is your “before” rule. :stuck_out_tongue: Possibly with some clever wording to conceal the messiness. (“You look closer and discover there’s no keyhole on this side.”)

You could make a special keyless unlocking action that only gets parsed on the wrong side of the door, like this:

[code]Jail cell is a room. Jail corridor is a room. The jail door is a closed locked lockable door. Jail door is outside from Jail cell and inside from Jail corridor. The player is in jail corridor.

The player carries a key. The key unlocks the jail door.

Keyless unlocking is an action applying to one thing. Understand “unlock [something]” as keyless unlocking when the location is the jail cell.

After closing the jail door in the jail cell:
say “The door snicks locked. Maybe that wasn’t such a good idea…”;
now the jail door is locked.

Instead of keyless unlocking: say “You can’t unlock that.”
Instead of keyless unlocking the jail door: say “The jail door can’t be unlocked from this side.”
Instead of keyless unlocking the open jail door: say “The jail door is open, and even if you shut it, you couldn’t unlock it from this side.”

Keyless locking is an action applying to one thing. Understand “lock [something]” as keyless locking when the location is the jail cell.

Instead of keyless unlocking: say “You can’t lock that.”
Instead of keyless unlocking the jail door: say “The jail door can’t be locked from this side.”
Instead of keyless locking the open jail door: say “The jail door is open, and even if you shut it, you couldn’t lock it from this side. Try it and see!”

test me with “open door/unlock door/in/lock door/shut door/unlock door”.[/code]

This could be made more generalizable–you could make the rules apply to lockable things instead of specifically to the jail door, and you could give rooms a wrong-side-of-the-door property that you could use in the Understand statement if you’ve got more than one. And if you can have another unlockable thing (like a safe) in a jail cell, you’ll have to be a bit subtler. If you have a room that’s on the wrong side of one door and the right side of another, you’ll have to be a lot subtler.

Ah, I hadn’t thought of doing that–writing a “keyless unlocking” action–but it seems rather obvious now that you’ve shown me!

I have multiple rooms that I want to apply this, too, but I think the basic idea here is sound and can be built on. I played with the code a bit and came up with this:

[code]A jail cell is a kind of room. A cell door is a kind of door. The matching key is the master key.

West cell is a jail cell. Jail corridor is a room. The west door is a closed locked lockable cell door. West door is east from West cell and west from Jail corridor. East cell is a jail cell. The east door is a closed locked lockable cell door. East door is west of East cell and east of Jail corridor. The player is in jail corridor. The player carries a master key.

Keyless unlocking is an action applying to one thing. Understand “unlock [something]” as keyless unlocking when the location is a jail cell.

After closing a cell door (called the portal) in a jail cell:
say “The door snicks locked. Maybe that wasn’t such a good idea…”;
now the portal is locked.

Instead of keyless unlocking: say “You can’t unlock that.”
Instead of keyless unlocking a cell door: say “The jail door can’t be unlocked from this side.”
Instead of keyless unlocking an open cell door: say “The jail door is open, and even if you shut it, you couldn’t unlock it from this side.”

Keyless locking is an action applying to one thing. Understand “lock [something]” as keyless locking when the location is a jail cell.

Instead of keyless locking: say “You can’t lock that.”
Instead of keyless locking a cell door: say “The jail door can’t be locked from this side.”
Instead of keyless locking an open cell door: say “The jail door is open, and even if you shut it, you couldn’t lock it from this side. Try it and see!”

test me with “open west door/unlock west door/w/lock door/shut door/unlock door/gonear jail corridor/unlock east door/e/shut door”.[/code]

I’ve tested it and it seems to work as expected. We’ll see what happens when I plug it in later, but I don’t see why it wouldn’t work.

I’m kind of smacking myself on the forehead right now, because this solution was in Locksmith (there is a “locking/unlocking keylessly” action), but I couldn’t see it for some reason. Thanks for the help!

Ah, but the above needs a little tweaking, because you can still unlock the jail cells from within with “unlock west cell with key”. That will obviously need to be tweaked, but breakfast first!

You’ll need to add rules to prevent normal locking and unlocking (UNLOCK DOOR WITH KEY) since these won’t be diverted to the keyless-unlocking action (edit: as you’ve spotted).

Instead of unlocking a cell door with something in a jail cell:
          try keyless unlocking the noun.

Another small point is that you may get “which do you mean” prompts, if you’re carrying two keys. (Which do you mean, the iron key or the brass key?) If you want to get rid of these you’ll need to use asking which do you mean rules.

Yup.

Good point.

I’m going to have to play around with your original solution, too, and see which I like better. I suspect that your code might turn out to be more elegant, although I haven’t had the chance to implement a test yet. And that will have to wait until later (probably a while later), as I have to get some work done now.

At any rate, thanks again for the input!

This will happen by default for anything, unlockable or not–if you type UNLOCK FICUS WITH KEY the game will ask “Which do you mean, the iron key or the brass key?” before telling you you can’t unlock it. Which doesn’t mean you shouldn’t write a rule to eliminate it! Particularly if your players are likely to run into this kind of problem.

Also, my bad on forgetting about “unlock door with key”!

I should mention that if your game produces “What do you want to unlock it with?” and the answer is “key,” Jenni Polodna will be sad. (Locksmith takes care of this, I think.)

Yes, true. If you’re going to eliminate it for the cell door, then for consistency you should probably eliminate it wholesale (except for doors you actually can lock).

Hmm. Yes, that is true.

Yes, I did think of that! I will have to be careful about not producing such unwanted clarification messages. :smiley:

I think I’m going to need to spend a little time with this and see if I can work off of Locksmith, because that extension does have functionality that I would like to keep. I think if I combine the “jail cell” kind of room and “cell door” kind of door with what Locksmith already does, I should be able to get something to work by “hijacking” the unlocking/locking keylessly actions, since Inform always carries out more specific rules before more general rules. So, for example, while Locksmith has something like this:

Before locking keylessly an open thing (called the door ajar) (this is the closing doors before locking keylessly rule):

I should be able to have something like this:

Before locking keylessly a cell door (called the door ajar) when the location is a jail cell (this is the closing doors before locking keylessly rule):

and have that override the default Locksmith behavior for that specific instance.

Anyway, thanks! Now I need to turn off email notifications for this forum, or I am never going to get any work done!

For the sake of completion, here is a version that includes Locksmith and works off of that:

Include Locksmith by Emily Short

A jail cell is a kind of room. A cell door is a kind of door. The matching key is the master key.

Cell 1A is a jail cell. The west door is a closed, locked, and lockable cell door. It is east from Cell 1A and west from the Corridor. Cell 1B is a jail cell. The east door is a closed, locked, and lockable cell door. It is west from the Cell 1B and east from the Corridor. The front gate is a closed, locked, and lockable door. It is south from the Corridor and north from the Yard. The matching key is the warden's key.

The player is in the Corridor. The player carries the master key and the warden's key.

Instead of unlocking keylessly when the location is a jail cell: say "You can't unlock that."
Instead of unlocking keylessly a cell door when the location is a jail cell: say "[The noun] can't be unlocked from this side."
Instead of unlocking keylessly an open cell door when the location is a jail cell: say "[The noun] is open, and even if you shut it, you couldn't unlock it from this side."

Instead of unlocking a cell door with something in a jail cell:
		  try unlocking keylessly the noun.
		
Instead of locking keylessly when the location is a jail cell: say "You can't lock that."
Instead of locking keylessly a cell door when the location is a jail cell: say "[The noun] can't be locked from this side."
Instead of locking keylessly an open cell door when the location is a jail cell: say "[The noun] is open, and even if you shut it, you couldn't lock it from this side."

Instead of locking a cell door with something in a jail cell:
		  try locking keylessly the noun.
		
test me with "open west door/w/close door/lock door/lock door with master key/e/lock west door/gonear cell 1b/unlock door/unlock door with master key/gonear corridor/unlock gate/s/lock gate".

In retrospect, this seems rather simple: All I had to do was piggyback off of the existing “(un)locking keylessly” rules in Locksmith, making my rules more specific so that Inform would follow them first. I don’t know if the code above will work perfectly in all instances, but it will suit my needs, and I suspect if I run into any glitches it will just be a matter of making sure a situation I hadn’t foreseen is covered by my rules.

Once again, thanks to all who contributed to this thread and helped me make sense of this. Your help is greatly appreciated.

Apologies for the necroposting, but I thought it necessary to add to my above post–or, more accurately, to subtract from it. Locksmith has quite a bit of functionality already, including a default message for when the player attempts to lock/unlock something that is not lockable. This eliminates the need for the first (catchall) “instead of” rule. Locksmith also automatically closes doors that players are attempting to lock/unlock, so if we are fine with this behavior we don’t need the third “instead of” rule, either, as that situation will never happen. So, in the end, the only extra rules we need are the rules preventing the player from locking/unlocking while inside a jail cell. For the sake of completeness, the code is as follows:

Include Locksmith by Emily Short

A jail cell is a kind of room. A cell door is a kind of door. The matching key is the master key.

Cell 1A is a jail cell. The west door is a closed, locked, and lockable cell door. It is east from Cell 1A and west from the Corridor. Cell 1B is a jail cell. The east door is a closed, locked, and lockable cell door. It is west from the Cell 1B and east from the Corridor. The front gate is a closed, locked, and lockable door. It is south from the Corridor and north from the Yard. The matching key is the warden's key.

The player is in the Corridor. The player carries the master key and the warden's key.

Instead of unlocking keylessly a cell door when the location is a jail cell: say "[The noun] can't be unlocked from this side."
Instead of unlocking a cell door with something in a jail cell:
		  try unlocking keylessly the noun.
		
Instead of locking keylessly a cell door when the location is a jail cell: say "[The noun] can't be locked from this side."
Instead of locking a cell door with something in a jail cell:
		  try locking keylessly the noun.
		
test me with "open west door/w/close door/lock door/lock door with master key/e/lock west door/gonear cell 1b/unlock door/unlock door with master key/gonear corridor/unlock gate/s/lock gate".

In the end, it turned out to be rather simple after all.