Rooms below other rooms

I have a room that is up from a door, and a room that is down from the same door (it’s basically supposed to be a room with a trapdoor in the floor, through which you can drop down to the floor below).

Problem is, even when the door is open, trying to go down results in “you can’t go that way”. Is this likely a problem with my code, or is there something inherent in I7 that prevents going up and down?

It’s likely a problem with your code. Please copy-paste the relevant part here. You can also check the World tab in the Index where you see a map of the layout which might give a clue for what’s going on.

Are you referring to the same door in both places? It could be that Inform 7 thinks that there are 2 different doors. Don’t cut corners when referring to named items, Inform 7 is fussy like that!

Also, as Juhana said above, it’d be best if you posted your code here, then we can diagnose the problem.

Hope this helps.

I changed any abbreviations to the full name, but nothing changed.

I can’t really post the code because there is a puzzle involving ‘unlocking’ the trapdoor, so I would have to post the WHOLE code to determine which part is affecting travelling up and down. Here is the map though…

The map looks as it should, I think.

The “You can’t go that way” response is given if there is no door in the direction you want to go or if the door in that direction is undescribed. If you have a puzzle that involves finding the door, you might perhaps have started out with the door undescribed. If so, you need to state that the door is now "described (or ”not undescribed”) as soon as it’s been found.

Try the RULES debug command, to find out what rule prevents the player from going down.
Just enter the command RULES (or RULES ON) and then Inform will list all rules it considers as it goes along. The rule immediately before the unwanted response is likely to be the one responsible for it.

Thanks, you were right, it’s because the door is undescribed. This is annoying because it’s undescribed because I don’t want it to be mentioned after the room description, and I’m trying to simulate the door not being there anymore, so I DEFINITELY don’t want it described at the point the player is going through it (within the gameworld it’s just a hole at that point).

The ‘rules on’ thing is a god damn revelation. That will help me a lot! Thanks :slight_smile:

The simple solution is to make it scenery instead of undescribed.

It certainly is!

There’s another one you should know of, too. You don’t need it as often, but when you do it’s quite as useful as the other one: viz. ACTIONS, which tells you what action(s) (if any) the game is actually trying after a given command and whether an action succeeded or not.

Also, its good to have the Standard Rules at hand to check precisely what a rule does when it does something you don’t what it to. You can open Standard Rules from the IDE (File > Open Extension > Graham Nelson > Standard Rules) or download a heavily commented pdf version of it from the Inform 7 site: http://inform7.com/sources/webs/

SHOWME is another command–describes every property of a thing.

It can often sweep up disambiguation problems e.g.

[code]> SHOWME DOOR

Which door do you mean, the trap door or the trap door?[/code]

You know you’ve somehow defined a second door according to Inform. I know in one piece of code I wrote, I unintentionally defined two things called (privately-named):

doc-y
docy

This caused me enormous frustration when I tried to do something simple and it failed.

TREE is also handy to check on objects.

But you’ll pick up your own debugging methods too as you go through things.

However, I’m half wondering if we should have a pinned topic for popular debug commands–it could double as a “try this first.”

Also, Juhana’s link is amazing–I somehow missed it. The PDF annotations are a huge help.

It might be a bit advanced in large doses, but I can vouch for looking into the Standard Rules as a good way to understand what is going on for my specific questions.

The best way to do this would be to use this.

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.

Hope this helps.

Really? I’d say the best way is the simplest way, noted earlier – make the door scenery.

I rather assumed that making doors scenery caused issues since the don’t mention doors in room descriptions rule is used as an example in “17.26. Printing a locale paragraph about” in The Inform Documentation. It could just be a bad assumption on my part.

No, making doors scenery doesn’t cause any trouble. It’s just an example.

(Making a door undescribed makes it unusable, as noted earlier in this thread. That’s different.)