[I6] Default message if we try to Enter or Go directly into door Object

Authoring Inform 6
1

An Object with the attribute door can be a door, a bridge, a ladder, a rope, a barrier etc.
If we try to move in the direction of the compass, and the door-object blocks the passage, the default message is adapted:

> n

“You can’t, since the door is in the way.”

But if we Enter or Go directly into door-object and is closed or locked, the same default message is displayed:

> Enter door

“You can’t, since the door is in the way.”

(I don’t know in English but in French this kind of message doesn’t work at all.)

“You can’t, since the door is closed.”, would be better (and it is, closed or locked).

So if the “noun” is in the compass, the first message is better, otherwise it is the second.

It’s happening here:

LanguageLM: Go, 5:
   5:  "You can't, since ", (the) x1, " ", (isorare) x1, " in the way.";

LanguageLM: Enter, 3: (does not seems appropriate for that)
   3:  "You can't get into the closed ", (name) x1, ".";

    if (next_loc has door) {
        if (next_loc has concealed) return L__M(##Go, 2);
        if (next_loc hasnt open && ImplicitOpen(next_loc)) {
            if (noun == u_obj) return L__M(##Go, 3, next_loc);
            if (noun == d_obj) return L__M(##Go, 4, next_loc);
**          return L__M(##Go, 5, next_loc);
        }

I can’t find any example for which the default message, LanguageLM: Go: 5, would be appropriate.
Can I bother David Griffith with this or not?

1 Like
2

I know you’re working in Inform 6 so this reply might be pointless, but I made an extension for Inform7 called “Easy Doors” which allows non-directional doors that the player can just type the name of to enter (although directional input can be redirected to them like a standard door). They also can behave as container-type objects in a location (such as a tent) that lead to a new location instead of inside of a container.

3

This seems simple enough to fix that it would be worth a pull request for the library.

The only worry would be breaking old games which expect there to be only a single message for that, since it sounds like you’d be adding a new message rather than redirecting to a different existing one.

This is hacky, but perhaps you could check for a particular constant being defined (LM_HAS_NEW_MSG or whatever), and only call the new message if it is? If someone’s Spanish library or whatever doesn’t supply the new message, it won’t define that constant either, and there’ll be no problem.

4

The default message is good for the case where the door-object is closed but not openable. The author might do this for a fence which will be wrecked at some point in the story. The story code can set the fence to be open, but the player can’t apply the OPEN or CLOSE verbs to it, and the game shouldn’t imply that they can.

(But I7 drops this distinction and has the player try an implicit OPEN for any closed door, even unopenable doors.)

5

Thank you for your answers.
The best solution is certainly to use the default messages as little as possible and to manage them in the source code of the game. The same default messages must respond to many different game situations and it cannot do this perfectly.
Default messages are very useful especially if the player does inconsistent things that the designer is not supposed to manage (eat, break, burn or kill everything or everybody, and so on.)

6

mha. In my concept of world model, ENTER/IN should be for moving either into location(s) inside a location, e.g. a car in a garage, an aisle, even the infamous “phone booth of death”, or, in a location on a periphery of a location, but functionally integral to it, e.g. the closet of a bedroom or the shower of a bathroom. The former don’t have an direction associated with it, the latter has also a direction associated.

I’m not 100% sure that I have rendered well my thinking…

Best regards from Italy,
dott. Piergiorgio.