Problems using "Now [the door] is locked" during a custom scene

Hello, while trying to familiarize myself with how scenes work I noticed that locking a door during a scene I created was not behaving as expected, such as when a door is locked when play begins. Here is a scenario that illustrates my problem:

"Locked in the closet"

Laboratory is a room.

Closet is a room.

In the laboratory is a door called oak door. It is north of laboratory and south of closet.

Lock the door is a scene.

Lock the door begins when the player is in the closet for the first time.

When Lock the door begins:
    now the oak door is locked.

Instead of examining a door:
    say "The door is [if locked]locked[otherwise]unlocked[end if]."

[When play begins:
    now the oak door is locked.]

test me with "n / x door/ s / x door"

Perhaps I am missing something vital but it appears to me that during my created scene even though the door is recognized as locked by inform and prints that it is is locked when checking it’s state, it still allows for the player to enter the door. However using the same line of code “Now the oak door is locked” does seem to work within a when play begins rule. This was especially confusing to me when reading through the inform 7 documentation to see that When play begins is also a scene.

If anyone has any insight into why this might be behaving this way and any way around it, that would be greatly appreciated.

Locked vs Unlocked and Open vs Closed can be set completely independently from each other. When the player’s trying to do things, there are Check rules in the Standard Rules enforcing things like that you can’t lock something that’s open. But there’s nothing stopping the author from writing rules that set any combination of locked/unlocked and open/closed.

So your door is being locked; it’s just that it’s still open.

3 Likes

Thank you so much, the open/closed state didn’t even cross my mind.

1 Like

Glad to help. The SHOWME debugging command is helpful in a case like this when things are strange: it’ll show you what properties are set for a thing and, so, would have told you the door was locked and open.

1 Like

By the way, I’ve never seen this syntax:

I only know this:

Is the first part adding anything? Is the door actually in the room?

You don’t have to say anything like “Door X is in Room Y”… you can just define it in terms of directions. But, yes, any given door is always in a room. An example:

Doors are always enclosed by the rooms on both sides of it, initially contained (and thus held) by the room they’re first defined relative to, and subsequently contained/held by whatever room the player was most recently in that encloses the door.

But in writing this sample, I found one thing that surprised me. If you uncomment the line about Oak door is in the lab. then initially:

The location of the oak door is Conservatory.
Oak Door is in Lab.
Lab holds the oak door.
Lab encloses the oak door.
--
Conservatory encloses the oak door.

The oak door’s location is different from what contains it!

1 Like

Okay, now you have to tell me how you embed the inform interpreter in the forum… :heart_eyes: :sunglasses:

snippets.borogove.app. Compile something, select “Share”, then copy the “Forum code/embedded” iframe tag it presents and paste it here.

5 Likes

If this seems confusing, it’s because it is… It’s (probably the sole) exception to the rule that to enclose something, an object must also either directly or indirectly hold it.

This is due to the specific hard-coding for the location of a door in the I6 routine [LocationOf], which defines the location of an object:

[ LocationOf o;
	if (~~(o ofclass K1_room or K2_thing)) return nothing;
	if (o ofclass K4_door) {
		if (parent(o) == real_location) return real_location;
		return FrontSideOfDoor(o);
	}
	if (o ofclass K7_backdrop) {
		! print "(deciding ", (the) O, " is at ", (the) BackdropLocation(o), ") ";
		return BackdropLocation(o);
	}
	while (o) {
		if (o ofclass K1_room) return o;
		o = CoreOfParentOfCoreOf(o);
	}
	return nothing;
];

This (somewhat unexpectedly) will always return the location of a two-sided door as the front side of the door (being the room in which the door is first defined in source to be found, or more technically, the first element of the I6 found_in array property of the door) unless the door happens to currently be in the same room as the player, in which case that room is returned

1 Like