FWIW, “Secret Doors” (which I’ve just gotten into the Library after an update) also lets you do this (possibly slightly less thoroughly, but it has the same effect) by controlling whether secret doors are “revealed” or not.
The Secret Doors extension makes an object which is in scope, but which responds to all interaction with “You can’t see any such thing” / “You can’t go that way.” This is generally effective but not perfect. The secret door can wind up as “it”; the parser might infer it if you type “OPEN” with no noun; other game rules might act before the door-blocking rules. Also, the hidden door doesn’t respect a “going nowhere” message for the room.
(Also, the extension as posted in the Public Library has bad line spacing. You need a [line break] after the [text of …] output.)
My extension removes the door from scope and causes the game to behave exactly as if the exit were unused.
Sadly there doesn’t seem to be an I7 way to remove an object from scope (without removing it entirely, which isn’t otherwise possible without some I6 code like your extension). But I did say that your one would do so more thoroughly.
Can you explain this point further, please?
Ah, I missed that. I’ve corrected it in my local copy and I’ll resubmit it. (I was initially thinking this might be a bug, as it doesn’t happen elsewhere. But then I remembered the implicit break on full-stop rule.)
Note: this is not an subject on which I think everybody needs to be perfectionist. Secret Doors will work fine for a lot of games.
I worked out the Disappearing Doors trick for a special case in Hadean Lands. (Not in fact a hidden door, but a place where it was desirable to swap a fake door object for a real door object at a particular point in the game.) I figured I’d make it available.
Out of curiosity, I tried using this rule instead of the “before going through a secret door which is unrevealed” rule, to see if it would intercept the variables but still follow the rest of the normal “going” machinery, in the hope that it would resolve the above:
Rule for setting action variables for going (this is the going through secret doors rule):
if the door gone through is an unrevealed secret door:
now the door gone through is nothing;
now the room gone to is nowhere.
The going through secret doors rule is listed after the standard set going variables rule in the setting action variables rulebook.
Sadly this produces:
[** Programming error: (object number 583531) has no property component_parent to write **]
[** Programming error: (object number 583531) has no property component_sibling to write **]
Unfortunately while it works beautifully when an “Instead of going nowhere” rule is actually present, if there isn’t such a rule then it results in bypassing the normal Before rules and you end up being able to go through the unrevealed secret door anyway.
Hmm. The problem seems to be the determine map connection rule. If I delete that rule then it seems to fix things. I’m not entirely sure what its purpose is, since it seems to duplicate logic in the standard set going variables rule. Does anybody have any thoughts on whether deleting this is safe?