Opening locked window ignoring customised response

I have a locked window, defined thus:

The inspection window is a locked openable container on the machinery. 
The inspection window is undescribed.
The inspection window has a truth state called was-unlocked. 
The was-unlocked of the inspection window is false. 
The description of the inspection window is "A small glass window on the machine."
Understand "inspection window" and "window" and "inspection" as the inspection window.

	
Instead of opening the inspection window:
	if the inspection window is locked:
		say "It appears to be locked.";
	else:
		if the player does not have the igkey:
			now the igkey is in the location; 
			say "You open the window and ....";
		else:
			say "The inspection window is already open.".

When the player tries to open the locked window, instead of returning the customised response, it returns the game’s default response:

>open window
(first unlocking the inspection window)
You lack a key that fits the inspection window

I have tried changing if the inspection window is locked to if the was-unlocked of the inspection window is false, but it returns the same response. I tried adding the inspection window is openable but same issue. Everything else is working and the player is able to open the window once they have unlocked it, it’s just this initial open I am struggling with.

Right, what’s happening here is that per the standard rules the open action is generating an implicit unlock action (since usually that is player-friendly behavior - it’s a nice convenience). But since you don’t have any specific rules for the unlocking action, it’s failing by default. So you should probably move your response code over to an unlocking rule.

(For the future, the RULES and ACTIONS testing commands can be super helpful for figuring out what’s going on in situations like this!)

Edit: you might want to also consider not relying on an instead rule here - there are some downsides to using them for situations like this one that are actually pretty straightforward applications of the relevant action. Thread with some details here.

3 Likes

Also (somewhat off-topic), your entire understand line is useless because you already defined the thing as an inspection window, meaning all three of those inputs will be understood. If you need other disambiguations, like “screen”, that aren’t part of the name of the thing, then you would use an understand statement.

2 Likes

Good point. That is a complete noob mistake on my part!

Hi Mike,

This needs some consideration. The unlocking of the window is dependent upon the state of three other objects. Only when they are all true is the window unlocked.

1 Like

If that’s the case, honestly I might just not lock the window at all and handle things with a check opening rule. If you’re not dealing with a case of a lock openable by a single key, it’s easy to end up fighting the default implementation in the standard rules.

1 Like

I believe that message is from locksmith and not from the standard rules. Sorry if I’m mistaken.

I haven’t used it before, so I can’t do more than mention it.

1 Like

Ah, could well be! I’m not in front of the IDE right now, and so many games with locked things use the extension that I don’t really notice it as a separate thing.

It’s just that the extension sets the output. So one of the instead cases can be handled there.

Maybe? There may be other questions.

e: I think the extension does “before” rules for implicit unlocks, which would mean “instead” processing is too late.

4 Likes

This is indeed the case. At least I now understand what is going on but it is a minor frustration that may cause confusion to a new player.

1 Like

I believe this is always the case with implicit actions, now that I think about it.

1 Like