My door opens, but I can't go inside!

Porch is a room.

The front door is a closed openable door. The front door is north of Porch and south of Foyer.

Front door is undescribed.

Hello again. It really helps us to help you if you put your code within the code tags (see attached). And if you can also print the error that occurs, it will help. :slight_smile:

I don’t get an error message. The game just tells me I can’t do that.
I could before I rote the code for the door.

Check that code. Remember what Hanon said. Doors are, by default, closed openable things. :sunglasses:

Taking out “closed openable” did not solve the problem. This is especially frustrating, because I wrote the same code for another door, and it works as expected/

It seems that making it undescribed is the culprit. Making it scenery is fine, though. Is there any reason it needs to be undescribed?

It needs to be undescribed because otherwise it shows up in the promp. The other door I talked about, the one that works, is also undescribed/

Actually, I tried Eleas’ suggestion, and now I am able to go inside; but the story keeps telling me “You can see an open front door here” and I don’t want it to.

An undescribed door is generally not passable, and a scenery thing does not show up in the prompt.

Scenery will do what you want, and will not have this problem. If you make the door scenery, it should not display in the room description, whether it’s open or not.

Of course, as was mentioned by climbingstars in an earlier thread, you could always set its locale priority to zero, like so:

For printing a locale paragraph about a door (called the item) (this is the don't mention doors in room descriptions rule): set the locale priority of the item to 0; continue the activity.

But it should be unnecessary.

If I make it scenery, I won’t be able to make the player open the door before entering a room. I want to make him have to open the door.

That should implicitly happen. Playtest it with the door as scenery as see if it does what you’re describing.

I did that, and now I can go through the door without having to open it first. Thanks anyway.

Just to be sure we’re on the same page. You don’t want the door to automatically open when the player goes in that direction?

So I tried this, and oddly enough, if I check “going through” the door in question, it’ll successfully block directional navigation from automatically opening the door, but if I actually type “go through” or “enter” the door, that circumvents the check.

Going through the door is the standard “going” action, like when the player types “go north”. The noun is the direction moved.
Entering the door is a separate action, when the player types “enter door” or “go through door”. The noun in this case is the door.

Yes, but I specifically wrote the check for “going through the door”, which is why I thought it was odd that going [direction] got checked, but the verbatim action that I wrote the check for – “go through the door” – didn’t.

Internal action names are often different from the commands you use to type them, and usually (always?) there’s only one internal action name for each action that you can use to specify a given action in your rule.

It’s pretty unusual that a command that corresponds to one action compiles as another action when you put it in the source code, but in this case the going action has what’s called an action variable called the “door gone through” which is specified in the internal rules like this:

The going action has an object called the door gone through (matched as "through").

That “matched as” clause means that you can specify “through foo” in a rule for going, and Inform will know that it only applies when foo is the door gone through. (This is why you can write “Check going from…” and “Check going to…”–there are action variables matched as “from” and “to.”) So if you’ve written:

Check going through the bamboo curtain:

Inform processes that as basically

Check going [the going action] through [when the door gone through is] the bamboo curtain

and it gets hooked up to the going action–but, again, “go through bamboo curtain” triggers the action of entering the bamboo curtain, which is different.

holmes_iv, as for your problem that you don’t want the player to be able to go through the door without opening it, what’s going on is that you’re running into this rule from the standard rules:

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.

This rule automatically has the player try to open any closed door that’s in their way. Modifying the standard rules might be more than you want to dive into at this stage, but you should be able to stop the player just by writing a rule that cuts off a going action in the relevant direction when the door is closed. So like this:

[code]Porch is a room. “Here is the porch of the house. The house itself is to the north. If only there were some sort of traditional way to enter a house from its porch!”

The front door is a closed openable door. The front door is north of Porch and south of Foyer.

The front door is scenery.

Check going north in the Porch when the front door is closed: say “You haven’t found a way in from the Porch yet.” instead.

test me with “n/open door/n”.[/code]

yields this: