Falling back on command being overridden when the overridden command has a different number of parameters

Authoring Inform 7
1

Let’s say I implement a new action that overrides a built-in command (in this case “unlock”):

a door has a direction called doorInDirection. The doorInDirection of a door is usually inside.
a door has a direction called doorOutDirection. The doorOutDirection of a door is usually outside.
a door can be keyful or keyless. A door is usually keyless.
Understand "unlock [something]" as unlocking keylessly. Unlocking keylessly is an action applying to one thing.
Check unlocking keylessly:
	if the noun is not a door, say "[The noun] is not something you can lock." instead;
	if the noun is unlocked, say "[The noun] is already unlocked." instead;
	if the noun is keyful:
		try unlocking the noun instead;
	if the direction of the noun from the location of the player is the doorInDirection of the noun, say "The door is locked from the inside." instead.
Carry out unlocking keylessly:
	now the noun is unlocked.
Report unlocking keylessly:
	say "You unlock [the noun]."

Then “try unlocking the noun instead;” fails because of course the built-in unlock requires two nouns and not one. Is there any way to call the built-in unlock, and have it prompt “What do you want to unlock the door with?” which is what would happen if I hadn’t overridden the “unlock” command and the user typed “unlock the door”?

2

First off, rather than reinventing the wheel I’d strongly suggest using the Locksmith by Emily Short extension for this sort of thing.

To make the compiler accept the try line, you do have to specify the full action including the second noun:

try unlocking the noun with nothing instead.

This won’t print a disambiguation, though, it will just say “You must supply a second noun.”

I don’t know if there’s any easy way to trigger a disambiguation question once you’ve “left” the parser and are now in action processing. But there are perhaps some other things you could do to make it more natural – Locksmith takes that approach, where it tries to detect a key that you’re already holding and then uses that automatically (under the assumption that the player should know which key they’re carrying would fit).

Without Locksmith, you could do something similar by relying on the matching key standard property of doors:

	if the noun is keyful:
		if the noun provides the property matching key and
				the player encloses the matching key of the noun:
			say "(with [the matching key of the noun])[command clarification break]";
			try unlocking the noun with the matching key of the noun instead;
		try unlocking the noun with nothing instead;
3

Thanks

4

Not in the Standard Rules. I’m not sure what extensions can get up to.

5

I did have a quick look through the extensions, but while there were several that modified disambiguation in various ways I didn’t spot any that would let you trigger it at will. Not surprising; due to the way that the parser is constructed that seems like a hard problem.

FWIW, another possible alternative to adding an extra action in the original problem is to give Inform better hints about an appropriate default choice; for example, if all doors were keyful but you wanted it to infer the correct key automatically:

Does the player mean unlocking a locked door (called the portal) with a thing (called the key):
	if the key is the matching key of the portal, it is very likely.

With this rule in place, then (provided they are carrying the correct key) Inform will accept unlock door without needing to add the extra action. It will still ask if they’re not carrying the correct key (but are still carrying more than one thing).

Oddly, due to the order that parsing scopes are tried, if the correct key is in the room (rather than carried) and the player is either carrying nothing or at least two things, then unlock door will also implicitly take the correct key and use it – but if the player is only carrying one thing then it will (unsuccessfully) try using that one carried object regardless. This can be worked around with some additional rules.

On further consideration, there is actually a way to get exactly the behaviour you’re asking for:

A door can be keyful or keyless. A door is usually keyless.

Understand "unlock [something]" as unlocking it with when the noun is keyless.
The carrying requirements rule does nothing when the current action is unlocking a keyless door with the player.
The can't unlock without the correct key rule does nothing if the noun is keyless.

Rule for supplying a missing second noun while unlocking a keyless door with:
	if the front side of the noun is not the location:
		say "The door is locked from the inside." instead;
	now the second noun is the player.

Does the player mean unlocking a locked keyful door (called the portal) with a thing (called the key):
	if the key is the matching key of the portal, it is very likely.

With this, unlock door will automatically unlock a keyless door (if they’re on the correct side), but doing that on a keyful door will (due to the final rule) either use the correct key automatically (if held), or ask for clarification (or just try a single carried object automatically, as usual).

Note also that this version doesn’t require you to specify “in directions” and “out directions” explicitly; instead it infers it from the automatically defined “front side” and “back side”. This just needs you to list the door in the correct order in the source text for it to work as expected (whichever side is mentioned first is where the latch is).

1 Like
6

Speaking of: Deluxe Doors by Emily Short is probably also worth a look; this implements a latched door kind which acts similarly to the above – you can have doors that latch on both sides or on only one side. The usage is a bit more complex but it’s also more flexible and thorough.

7

That doesn’t seem to work correctly. With this code I can unlock the door from either side as long as I’m carrying something:

>unlock door
(the gymnasium door with the wallet)
You unlock the gymnasium door.

But if I’m not carrying anything, this happens:

>unlock door
(the gymnasium door with the gymnasium door)
(first taking the gymnasium door)
That's fixed in place.

again this happens regardless of which side of the door I’m on.

Edit: When I’m carrying more than one object, the behavior is even stranger. “unlock door with object” always succeeds regardless of which object I specify, but simply saying “unlock door” results in:

>unlock gymnasium door
What do you want to unlock the gymnasium door with?

>wallet
I didn't understand that sentence.
8

Ok, to fix that, substitute this:

The can't unlock without the correct key rule does nothing if the noun is keyless and the second noun is the player.

Or use the same condition as for the carrying requirements rule.

9

Accidentally deleted post, not sure how to restore, but anyway, with your latest solution it still doesn’t work. It tries to unlock with whatever I’m carrying and fails saying it doesn’t fit. On either side of the door. Guess I’ll stick with your first solution.

10

Well, as I said before, the best solution is to make use of Deluxe Doors by Emily Short anyway.

But this worked fine for me. Are you sure that you’re trying it on a keyless door? The following is my complete test case:

A door can be keyful or keyless. A door is usually keyless.

Place A is a room.  The widget is here.
Place B is a room.  Place C is a room.
red door is a door.  It is inside of Place A and outside of Place B.  It is locked.
green door is a door.  It is outside of Place A and inside of Place C.  It is locked and keyful.  The matching key is the widget.
The player carries the fob.

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

Rule for supplying a missing second noun while unlocking a keyless door with:
	if the front side of the noun is not the location:
		say "The door is locked from the inside." instead;
	now the second noun is the player.
	
The carrying requirements rule does nothing when the current action is unlocking a keyless door with the player.
The can't unlock without the correct key rule does nothing when the current action is unlocking a keyless door with the player.

Does the player mean unlocking a locked door (called the portal) with a thing (called the key):
	if the key is the matching key of the portal, it is very likely.

Test me with "unlock red door with fob / unlock red door / unlock green door / unlock green door with widget".

Although I guess there is a slight bug with the above; the below will work a little better:

Rule for supplying a missing second noun while unlocking a keyless door with:
	now the second noun is the player.

Check unlocking a keyless door with the player when the front side of the noun is not the location:
	say "The door is locked from the inside." instead.

(You can provoke the bad behaviour by being on the wrong side of the door and explicitly typing unlock red door with me rather than letting it be inferred.)