Run-time problem when a door is nowhere

One last problem with that pesky cellar door (knock on wood)!

There are two doors. One is supposed to disappear behind you as you enter but when you type in “x door”, the game asks you “which one?” Can’t have that. But now entering the cellar door causes a run-time problem. The code I added is:

After going to wine cellar:
	if the location is the wine cellar:
		now the cellar door is nowhere.

Inform gives me a hint:

Doors are part of the fixed geography of the model world, and are tied in to the map, so it is illegal to remove them from play. (Of course rules can be used to simulate the absence of a door, or to change its behaviour almost completely.)

I don’t know how to do this, though.

1 Like

Check out this section of the docs – the syntax you’re looking for is something like “change the west exit of the wine cellar to nothing.”

2 Likes

Hmm. The doc says:

This phrase alters the map so that the given map connection is unmade. >Example:

change the west exit of the Closet to nowhere

My code:

After entering the cellar door:
	if the location is the wine cellar:
		change the outside exit of the wine cellar to nowhere.

Error message:

The ability to change map connections during play is quite constrained, and although the change … exit of … to … phrase exists, it should only be used as a last resort. (Better to apply rules which cause the map not to be followed than to actually alter the map, is the idea.) In particular, doors must not be disturbed at all, and here you tried to change an exit which led through a door: this is not allowed.

Seems like I followed the instruction to the tee but still no.

1 Like

Oh geez, this is part of the reason why I never use doors (Hanon’s Easy Doors extension is a go to for lots of folks). Maybe you could just make the door undescribed and run an instead rule to preempt going outside?

So I already have say “Strange. The door you came through is no longer there.” as an instead rule, but it doesn’t solve the “which one” thing.

Oh, if there’s a second door there, can you fix that with a Does the Player Mean rule?

Does the player mean doing something with the Cellar Door: it is very unlikely.

2 Likes

Argh. Still:

x door
Which do you mean, the cellar door or the bronze locked door?

1 Like

Huh, that’s weird. When I do this:

A door called the cellar door is inside from the Walled Garden and outside from the Wine Cellar. It is scenery. Understand "old door" and "wooden door" as the cellar door. 
	
The locked bronze door is a door.  It is west of the wine cellar.  It is scenery. It is closed and locked.

Does the player mean doing something with the cellar door: it is very unlikely.

I get this output:

Walled Garden

>in
(first opening the cellar door)

Wine Cellar

>w
(first opening the locked bronze door)
It seems to be locked.

>x door
(the locked bronze door)
You see nothing special about the locked bronze door.

Is there a cut-down version of your code that allows you to reproduce the issue?

EDIT: if you want to get rid of the clarification – “(the locked bronze door)” – that’s possible too:

Rule for clarifying the parser’s choice of the locked bronze door: say “”

1 Like

Oh my god I’m a dunce!

The example in the doc was “taking”, not doing something and I just copy and pasted it without looking it through properly. No wonder :rofl:

Thanks! I’m sure the parts of the doc you pointed me to will help in future cases too!

1 Like