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.
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.
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.
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.
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.