Sliding doors (or how to overwrite a standard rule)

Authoring Inform 7
1

Imagine the player goes from room A to room B.

There’s a door between room A and room B, but there is no need to open it, because it is an automatic door or sliding door.

What I would like to see as output - best for all doors in a region - is something like “The sliding door opens automatically before you go through…”.

I tried two things here to get this done.

  • I tried to change the can’t go through closed doors rule following the documentation section 6.3 of the documentation.

    The new can't go through closed doors rule is listed instead of the can't go through closed doors rule in the check going rulebook. 
This is the new can't go through closed doors rule: 
  if someone is going through a closed door: 
      say "(The sliding doors open automatically in before you pass...)";

    The I7 compiler kept complaining about a missing condition, although apparently it found condition “someone is going through a closed door”.

  • So instead I tried to define a new kind of door, nullify the can’t go the closed doors rule, and rewriting the opening check:

    Automatic door is a kind of door. Automatic door is usually closed.

The can't go through closed doors rule does nothing when going through a closed automatic door.

Check opening an automatic door:
  instead say "(The [noun] opens before you go through...)".

The second code compiled, but I don’t get any output.

I give up for today. :sleepy:

2

You don’t want to halt the action, you just want to make something happen automatically while the action is occurring. Check rules are useful for this type of situation.

In this case, there is an existing rule (can't go through closed doors rule) which is triggered by the world state (the door being closed). The rule can be neutered by ensuring that the door is open when the rule is processed. Since you only want this to occur in specific circumstances, a new rule specific to those circumstances is warranted. Here’s some example code, with references to relevant parts of Writing With Inform, the built-in documentation.

"Automatic Doors"

Place is a room.

An automatic door is a kind of door. [see WWI 4.1 New kinds]

An automatic door called a sliding door is east of Place. 

Other Place is east of sliding door.

To approach is a verb. [see WWI 14.3 More on adapting verbs]

Check an actor going through a closed sliding door (called auto door) (this is the automatic doors open automatically rule): [see WWI 7.14 Going by, going through, going with]
    if the player can see the auto door:
	    say "[The auto door] slides open as [if the actor is the player][regarding the player]you[otherwise][the actor][end if] [approach].";
    now the auto door is open;
    continue the action.

The automatic doors open automatically rule is listed before the can't go through closed doors rule in the check going rules. [see WWI 19.4 Listing rules explicitly]

Every turn (this is the automatic doors automatically close rule): [see WWI 9.5 *Every turn*]
    repeat with auto door running through automatic doors:
	    if auto door is open:
		    now auto door is closed;
		    if the player can see auto door:
			    say "[The auto door] slides shut behind [if the actor is the player][regarding the player]you[otherwise][the actor][end if]."
3

Can you get away with defining doors that are open, and just describe them as being closed?

3 Likes
4

or make it always closed and unopenable but describe it as opening…

The Lab is a room.

Sliding-door is a kind of door.
A sliding-door is usually unopenable.
The description of a sliding-door is usually "The sliding door is closed.". [change if you might have more than one sliding door in a given room...]

The sliding door is a sliding-door. The sliding door is east of the Lab. The Chamber is east of the sliding door. 

To approach is a verb. 

Instead of an actor opening a sliding-door:
  say "The door opens automatically as [if the actor is the player][we][else][actor][end if] [approach]. It closes automatically when [if the actor is the player][we][else][actor][end if] [do] not go through."

Check closing a sliding-door: instead say "It is already closed."

The can't go through closed doors rule does nothing when the door gone through is a sliding-door.

Instead of an actor going through a sliding-door (called the-door):
  say "The door opens automatically as [if the actor is the player][we][else][actor][end if] [approach] and closes behind [if the actor is the player][us][else][actor][end if].";
  move the actor to the other side of the-door from the location of the actor;
5

Thank you, I’ll look into your suggestions to see what fits best for my case, and I probably still need to learn more about rules, and checks.

However, I still would like to understand what’s the problem with my approach number one.

When moving from room A to room B (before introducing the sliding door), I7 reported that the door is opened first:

>e
(first opening the sliding door)

So my first idea was that I could simply replace the standard output (first opening the sliding door) with something like (The sliding doors open automatically in front of you...).

This is how I tried to overwrite rule can't go through closed doors (similar to what is done to the can't take people's possessions rule in section 6.3 of the documentation):

The new can't go through closed doors rule is listed instead of the can't go through closed doors rule in the check going rulebook. 

This is the new can't go through closed doors rule: 
	if someone is going through a closed door: 
		say "(The sliding doors open automatically in before you pass...)";

The compiler responds:

Problem. You wrote 'if someone is going through a closed door'  : but the ingredients in this phrase do not fit it, and I am confused enough by this that I can't give a very helpful problem message. Sorry about that.
I was trying to match this phrase:

 if (someone is going through a closed door - a condition): 
I recognised:

someone is going through a closed door = a condition

As a novice user that suggests to me that I may need brackets around the condition (?). Apparently, my condition was recognised, but may not be formatted correctly? Well, when I add brackets I get:

I was trying to match this phrase:

 if (( someone is going through a closed door ) - a condition): 
I recognised:

( someone is going through a closed door ) = a condition

Hmmmm… - although this approach might not be the right one in the end (it might be too general to change this rule for all doors in the game), I’d like to understand what’s the problem here, because in other situations, I might want to overwrite a rule. Any thoughts on that?

6

You were close; the following works:

The new can't go through closed doors rule is listed instead of the can't go through closed doors rule in the check going rulebook. 

This is the new can't go through closed doors rule: 
	if we are going through a closed door:
		say "(The sliding doors open automatically in before you pass...)";

See 9.12. Actions as conditions.

(Works as is, as far as I see, but adapt where necessary for distinguishing between sliding doors and normal doors and so on.)

As for why “if we are going” works, while “if someone is going” doesn’t… hmm, I think it’s one of those cases where Inform’s “quasi-natural-language” approach is a bit misleading, because it expects quite specific phrasings, and some phrasings that would make sense in natural language (or even in other places in Inform) are not accepted. (That’s not a dig against I7; just something to be aware of.)

What might also be interesting: check out chapter 12.10. Action variables.

You can find some information there on variables which are set for the current action. And in the Actions Index tab, you can see specifics, like “the door gone through” for the going action.

(But depending on the case, you do not always need to use or be aware of action variables. Very often you’ll simply write specific rules with the right preamble, such as: “Check going through a sliding-door:” and so on.)

General piece of advice for overwriting rules:

When you’re replacing a rule from the Standard Rules, you can take a look at how it’s implemented there, to get an idea which parts to replace and how to word your own rule. You can access the Standard Rules by opening the “File” Menu → Open Installed Extension → Graham Nelson → Standard Rules, and then search for the rule name.

About the parentheses:

In the error message, they are there just for informational purposes, to clarify how Inform tried to understand and group the components of the statement.
I don’t find myself writing parentheses often in I7 code; I rather break down the structure further if some conditions and rule preambles get too long and complex. I’d say the main place where parentheses are used (and required) is in the notation for naming parameters, as in: “Rule for deciding the concealed possessions of someone (called the suspect)” or “To clear (current table - a table name)” and so on.

2 Likes
7

StJohnLimbo explained the issue with your first attempt. In your second attempt, you’ve disabled the can't go through closed doors rule, but that’s the rule that actually generates the opening action for the door. (This isn’t obvious, but you can look at the rule’s definition in the Standard Rules.) Since no opening action is generated, your Check opening... rule won’t have an effect.

Also, by using the instead keyword in your check rule, you’re implicitly saying stop the action. Since you want the going action to continue, you should leave this out.

Check opening an automatic door:
    say "(The [noun] opens before you go through...)".

The >ACTIONS debugging verb can be helpful in understand what’s going on, as can the >RULES debugging verb. See WWI 24.3 High-level debugging commands for details.

EDIT: To be clear: The above is not a proper solution, because an extra message is generated and the door only opens once. You just seem to be asking “What’s wrong with this code?” more than “How can I make this idea work?”

Also, be advised that if you are replacing the can't go through closed doors rule, you’ll probably want to make sure that the replacement rule handles normal doors, as well.

1 Like
8

Thank you all!

I chose @StJohnLimbo as the solution, because it feels natural to me in this case to extend a standard rule:

[AUTOMATIC DOORS]

The new can't go through closed doors rule is listed instead of the can't go through closed doors rule in the check going rulebook. 

This is the new can't go through closed doors rule: 
	if we are going through a closed automatic door: 
		say "([the door gone through] opens automatically before you pass...)";
	otherwise:
		If the door gone through is not nothing and the door gone through is closed:
			if the actor is the player:
				say "(first opening [the door gone through])[command clarification break]" (A);
			silently try the actor opening the door gone through;
			if the door gone through is open, continue the action;
			stop the action.

Pointing me to the standard rule definition also helped me to find out what variable I need to use in the output ([the door gone through]).

@otistdog : Thanks for pointing me to the valuable debugging verbs, that’s what I call “help others to help themselves!” :upside_down_face:
And to be honest, it’s still not clear to me if by overwriting this rule I create some bad side effect, for example, the original rule uses the actor, I use we in my deviation (problem?).

Well, for now it seems to work, for example, no message is displayed if a non-sliding door was opened already in a previous turn. I assume the next problem I will have to solve is how to deal with locked automatic doors (those that need some kind of access card). :grinning_face_with_smiling_eyes:

Here is the standard rule that was replaced:

Check an actor going (this is the can't go through closed doors rule):
	if the door gone through is not nothing and the door gone through is closed:
		if the actor is the player:
			say "(first opening [the door gone through])[command clarification break]" (A);
		silently try the actor opening the door gone through;
		if the door gone through is open, continue the action;
		stop the action.
1 Like
9

Depends… :slight_smile:

In this case, “if we are ...” only means the player, as far as I see, while in the past tense, as the manual says in 9.12, “it’s enough for any actor in the story to have successfully [done the action]: it doesn’t have to be the player”.

If it can occur in your story that NPCs pass through these doors, and if you want to display a message that announces the doors sliding open for them, similar to the message for the player, then you need to take into account who the actor is, and insert some logic that either prints a generic message (“the door slides open”) or prints a message which modifies the wording of the output (as Otis and Zed demonstrated above).

But note that it probably only makes sense to display such a message if the player is actually there to witness it ( → “if the player can see the auto door” in Otis’ code), otherwise it could happen that such an announcement is made if an NPC goes through a door on the far side of the map somewhere.

Presumably for the latter reason, the Standard Rules make a difference here whether the actor is the player or not, and for the player, the special message “(first opening …)” is inserted before the action goes on with silently opening the door, while NPCs don’t cause that message. (Note the “silently”.)

10

Doh… when I read that, I just thought that Otis was displaying an abundance of caution and covering the case of someone going through a door in Darkness; the NPC in another location case just didn’t occur to me in the moment. My code, which was nominally trying to cover the NPC case with its use of “an actor” should have done similarly.

But as @StJohnLimbo indicates, if you know you won’t have NPCs wandering around on their own, feel free to ignore that case. You can drive yourself nuts trying to cover every imaginable case in your code: What if another character becomes the player? What if someone’s doing this on or in a vehicle? What if the character is doing this in Darkness inside a closed enterable container? But if you know you don’t have any player changes or vehicles or enterable containers, it’s wasted effort. (If you’re writing an extension intended for other people’s use, then there’s a point in being more accommodating and making as few assumptions as possible about the game.)

1 Like