So doors are a problem for me. I really don’t need the player to be futzing around with opening and closing doors, and I’m having trouble turning “open door” off adequately. The code is set up so that players can either knock on a door or simply go into it, and I have a lot of things that are triggered by entering or leaving a room (going in the direction of the door). So I need code that respects going in a direction. I have this:
Instead of opening a door (called the entry):
if the location is outdoors:
try knocking on the entry instead;
otherwise if the location is indoors:
try outing instead.
The knocking part works fine. The outing part throws this error:
> **open door**
(first opening the sturdy front door)
(first opening the sturdy front door)
(first opening the sturdy front door)
(first opening the sturdy front door)
(first opening the sturdy front door)
(first opening the sturdy front door)
[** Programming error: tried to write to -->160 in the array "MStack", which has entries 0 up to 159 **]
(with this repeated a zillion times)
If I say
otherwise if the location is indoors:
say "You can just OUT."
now you can’t leave because Inform considers that if you leave through a door, you open it first:
> **out**
(first opening the sturdy front door)
You can just OUT.
And you’re still in the same location. I really hope I don’t have to write a response for every door in the game (otherwise if the location is X: try going north instead)… I already did that for “out” and I’m peeved it won’t work here.
Inform usually requires doors to be open before an actor can pass through them, and the player character will attempt to open any door he might encounter while going in a particular direction. So even if the player types go out, the game will automatically generate an open door action before allowing the going action to proceed.
So in the first example, the Instead of opening a door rule will fire for this implicit action, which then causes the character to try outing, which leads to implicitly opening the door (because the door still must be open), which leads to… you get the idea.
The rule responsible for this is called the “can’t go through closed doors rule”, and is easy enough to pacify:
The can't go through closed doors rule does nothing when the room gone from is indoors.
Hmm. Should this prevent a player from opening a door at all (which is what I want)? I’m a bit unclear on the purpose of this rule. I looked it up in the Standard Rules, and I’m still not sure what it’s supposed to do if I turn it off. I stuck that bit of code in (and turned off every other mention of opening a door) and it still says:
> **open door**
You open the sturdy front door.
Am I misunderstanding what this is for, or do I have something somewhere else in my code that is messing with this and is still allowing players to open doors?
I hate doors.
No, this just allows the player to pass through a closed door as if it weren’t even there, provided that the room they’re coming from is indoors. This then allows you to insert your original instead rule without running into the loop you experienced:
The can't go through closed doors rule does nothing when the room gone from is indoors.
Instead of opening a door:
if the location is outdoors:
say "You can't just waltz in here as if you owned the place!"; [1]
otherwise:
try going the noun. [2]
This then produces something like this:
lab
You can see a metal door here.
>open door
garden
You can see a metal door here.
>open door
You can’t just waltz in here as if you owned the place!
>n
(first opening the metal door)
You can’t just waltz in here as if you owned the place!
[1]: Replace this line with try knocking on the noun, or whatever you want.
[2]: Alternatively, put something like say "Don't bother with the door, just GO OUT". here to reduce surprise.
(Sorry, got my indoors/outdoors confused with inside/outside in the previous reply.)
This is a very useful line. I tried all sorts of the things like “try going the direction of the door”; etc, and I think this is the syntax I was missing. Thanks so much.
There was just a necro’d thread on this rule – it looks like it initially was just the rule that prevented you from walking through a closed door, but then in a later update the implicit open functionality was added as a player convenience. So that’s probably why the label and the functionality are a bit confusing – it does feel like an awkward kludge once you peer under the hood.
OK-- that code works great except it overrides locked doors, or something somewhere in the code isn’t tweaking to seeing that it’s locked. Gah. Why does this have to be so complicated?
OUT. EXIT. Knock on. Enter door. Open/close door. There’s a million ways all your rules attached to going through doors can get screwed up with all the ways players can approach a door. I guess I know what I’m tinkering with all week.
OK, that won’t work, because it overrides every place (many, many places) where I don’t let a player leave until they’ve done something, and overrides everywhere where I won’t let a player enter. This would be a huge overhaul of rewriting every single door and action involving a door.
This is very discouraging. Maybe players will just have to open and close doors to their hearts’ content with nothing happening, even if that is odd given what’s going on-- like you are too scared to move, so you can’t leave, but sure, you can open and close that door.
Maybe there’d be a way to use an either-or property on doors to mark whether or not they’re meant to be barriers? Then you could bifurcate the new rule’s behavior based on whether the door has that flag set or not (depending on the details of your current implementation, it may be that you can just use the existing locked property for this). That’s some additional work but not too prohibitive, I don’t think.
sorry I can’t offer something more concrete but I think what you will want to do is something akin to changing
The can't go through closed doors rule does nothing when the room gone from is indoors.
To something like
The can't go through closed doors rules does nothing when the room gone from is indoors and the door is unlocked.
I don’t think this suggestion actually works though iirc using ands in statements like this works differently and I don’t know if that is the correct way to refer to the door the player would need to open. So take this more as psuedo code that can hopefully help you move in the right direction.
Yeah, I thought about putting a tag on doors (goable/ungoable or something like that), but I have so many triggers and prohibitions and changes of descriptions, etc, etc that are attached to going through a door that I can’t even think about finding them all.
In my next game I’ll consider this from the beginning, but I think it’s just too late for that now. I’d rather have something odd with door opening than face all the game-breaking bugs I’d be setting myself up for if I implement something like that now.
Thanks for this. Unfortunately, I have a lot of places where doors aren’t locked but I still don’t let you leave: because you haven’t picked up something useful and you won’t be able to come back in, or because you’re frozen in fear, etc. So it just turns into a huge tangled mess to try to go through and find everything and attach it to opening a door. I wish I’d known this would be an issue from the start, but c’est la vie. I’ll know next time.
I can’t speak for other people, but unless it’s something game breaking, staying with standard library action should be just fine. After all, it’d be something I’m used to. So, adhering to standard library behavior is recommended.
I certainly can’t recommend you to rebuild the whole action from scratch just to have it behave exactly like you want it. Lest you end up like me, going deep into the rabbit hole and end up creating the whole enchilada from scratch.
Wise advice. I see things on transcripts that are awkward and irritating (like “open door” working when it’s weird for it to do that) and I want to make it perfect. But I can often let the perfect get in the way of the good, and I can probably just calm down and accept that I don’t have the experience I need to make everything work as smoothly as I wish.
Just for anyone finding this thread in the future, I think this is working:
A door can be playeropened. A door is usually not playeropened.
Instead of opening a door (called the entry):
say "No need to open and close doors in this game. Just go in the direction of the door.";
now the entry is open;
now the entry is playeropened;
thedoorcloses in one turn from now.
At the time when thedoorcloses:
now all playeropened doors are closed;
now no doors are playeropened.
We’ll see if this does something terrible that I haven’t thought about, but so far it seems to be OK.
** Edit: nope. This doesn’t cover just going in a direction, which yields:
> **w**
(first opening the sturdy front door)
No need to open and close doors in this game. Just go in the direction of the door.
before moving the player west. I hate doors so much. I’m giving up.
OK, I’ve really got the solution. It’s to FAKE THE DOORS. Everybody who ever has this problem in the future: you don’t need Inform doors. You can just pretend they’re there. If you fake them, you don’t have to put up with all the baked-in weird behavior of doors. And it was minimal effort to replace the existing doors with fake ones.
I will probably rarely use an Inform door ever again.
Thanks to @Zed for helping me realize that I don’t have to use Inform’s tools all the time.
I know, right? Once you remember you can cleverly narrate your way around almost any implementation problem it’s like you’re Mr. Triangle seeing Flatland for the first time from above.
I have to confess, I’ve made two medium-big games in Inform 7 (85k and 60kish words respectively) and have yet to implement a working door! More trouble than they’re worth, much of the time.
Yes. I got over my door-proclivities in Transparent. Man. Everyone likes locked door puzzles, right? And darkness puzzles, right?AND INVENTORY PUZZLES! RIGHT?
It not only used Inform doors, I also made an extension to have a completely different sort of door. And a wandering NPC that could go through doors but not the player and light switches and ambient sound and…
An elegant “locked house” puzzle box is a standard parser trope, but it requires lots of work.