One-Way Door Possible Output Discrepancy

Authoring Inform 7
1

A terrible title for this thread, but I couldn’t think of a better one at the moment.

Consider the following source:

[code]The blue door is a door.
The blue door is east of the Undertomb.
Through the blue door is the Flat Landing.

Every turn:
say “[front side of the blue door].”;
say “[back side of the blue door].”;
say “[other side of the blue door from the Undertomb].”;
say “[other side of the blue door from the Flat Landing].”;
say “[direction of the blue door from the Undertomb].”;
say “[direction of the blue door from the Flat Landing].”[/code]
Here is the output:

I’m curious about the fourth and sixth entries (bolded and underlined in the output).

Shouldn’t those be “nothing” similar to the second entry?

I can somewhat understand why the last statement does print “east” but it doesn’t feel strictly accurate to say that given how directions are treated. For example (shortening it up and changing the door to be two-way):

[code]The blue door is a door.
The blue door is east of the Undertomb and west of the Flat Landing.

Every turn:
say “[direction of the blue door from the Undertomb].”;
say “[direction of the blue door from the Flat Landing].”
[/code]
Here the output is:

So in a two-day door context “direction of the blue door from the Flat Landing” in this case is west, which makes sense.

But when it’s a one-way connection, the “direction of the blue door from the Flat Landing” is east.

So Inform is shifting what “the direction of” means, or so it seems.

This may be a nit-picking thing, to be sure, but I wonder if that can lead to issues when you want to check if a one-way door does have a direction from a given location. In this case, it would seem the one-way door will always have a direction from both points even though that’s not true. Likewise, “other side of the blue door from the Flat Landing” will always provide an answer even though, in fact, it’s not the “other side”.

2

This is a general quirk in the behaviour of the expressions “other side of [door] from [room]” and “direction of [door] from [room]”, in the case that [room] is not a side of [door].

In the case of a 2-sided door, Inform apparently checks whether [room] is the front side of [door], and if it isn’t, assumes that it must be the back side. And in the case of a 1-sided door, it apparently assumes that [room] refers to the one side without checking at all.

It is specified in 3.12 of WwI that [room] needs to be a side of [door] in both of these expressions, so I don’t think this counts as a bug; I imagine the behaviour is intended.

3

Yeah, the logic is basically:

  • “the other side of [DOOR] from [FRONT SIDE]” := [BACK SIDE]
  • “the other side of [DOOR] from [ANYTHING ELSE]” := [FRONT SIDE]

This could be changed via I6 if you really wanted it to return “nothing” for an input which is neither the front nor the back side, but Inform assumes you’ll never be giving nonsensical inputs and optimizes slightly.

4

At first I was thinking this might be an issue when (or if?) doors that are initially one-sided could, in the course of play, be made two-sided. Say, a magic mirror or a wormhole that eventually allows passage through it. In that case, an author might want to check if the door (previously one-sided, leading to “nothing” from one end) now leads to an actual location via a direction.

With the logic as it is, I suppose a check could be made to see if both sides of the door essentially lead to the same location and, if so, know that it’s one-sided. From a query perspective, it would probably make most sense to be able to wrap that check up in some logic and ask: “if the blue door is one-sided …” or “if the blue door has an other side …”

I have done very little with doors in Inform, so I probably need to investigate all this a bit further.

5

Doors are generally permanent and don’t change their location or connections in play; there are some ways around this, but none of them are ideal, and optimizations in Inform sometimes assume doors never change. So in practice this is seldom an issue.