Doors and "removing" them


First of all, a note. I do not intend to flood this board with “every little problem” i have. But still a bit unfamiliar with I7’s “way of thinking” and easily getting lost in the manual…

I want a door to lock itself (done), being blown to pieces (kinda done) and “removed”. Removed for the reason that I don’t want it to be there anymore. So if it’s “forced open and defined as uncloseable” is sort of good enough.

But I can’t manage to do it. And removing doors seems to be a bit illegal…

“So, testing is the new fun” by Morten Flaten

Shaking is an action applying to one visible thing. Understand “shake [any thing]” as shaking.

A Kitchen is a Room. South of Kitchen is Living Room. West of Kitchen is Bathroom. Down from Kitchen is Basement. Up from Kitchen is Attic.

Section Kitchen

Door from Hell is east of Kitchen. Office is east from Door from Hell. Door from Hell is a door. Door from Hell is lockable and unlocked.

there is a Thingy in the Office. “Thingy thing is thingy, but not that much.”

After going through Door From Hell for the first time:
say “muhaaahaaa, door from Hell!!! It slams shut behind you! (spooky).”;
move player to office;
Now the Door from Hell is closed;
Now Door from Hell is locked.

Before opening Door from Hell when Door from Hell is locked:
say “Buhu, the door is locked.” [this obviously “doesn’t work”, the [after opening] message is still around]

Before shaking thingy:
say “smart move. The thingy now explodes and the door vanishes in a pretty vague vanish-kaboom.”;
Now Door from Hell is open; [/code][/rant]

Text is still pure nonsense and not meant to be anything else. yet.

One other thing I can’t seem to get done. (I know I saw this in the manual, or elsewhere, but I can’t relocate it :frowning: ) :

When the door is locked, you can’t open it. Ofcourse. But if you try to go W it says something like “after opening the door” but it seems to be locked. I want that default “[after opening…]” to be very very gone. From my game(s). :slight_smile:


No worries, Mort. Your examples are fun!

It looks like you’re putting the rules in the wrong rulebook again. Before rules continue the action by default. I think what you really want here is an Instead rule:

Instead of opening locked Door from Hell: say "Buhu, the door is locked."

You’ll noticed I also stuck the “locked” adjective before the name of the door for brevity. I7 lets you do lots of handy things like that.

I think shaking the thingy works better with an Instead rule too, but you need to do some extra things to make everything work right:

Instead of shaking thingy: say "smart move. The thingy now explodes and the door vanishes in a pretty vague vanish-kaboom."; Now Door from Hell is open; Now Door from Hell is unlocked; Now Door from Hell is not openable; Now Door from Hell is improper-named; Now the printed name of Door from Hell is "blackened hole in the wall";

The door must be open, obviously. But it must also be unlocked to prevent the special “locked” message you wrote (alternatively, you could change that Instead rule to test for the closed locked door.) If you make the door “not openable,” then you’ll be prevented from closing it, which is good when the door’s not really there. The last two lines work together. Since we can’t remove the door from play, I change the name of the door so it doesn’t look like a door anymore, and I make it improper-named so it will get an “a” or “the” before its name in descriptions.

This is sort of the reverse of a hidden-door puzzle. Kinda cool! There are tried-and-true approaches to creating hidden doors, but I’ve never looked at them - maybe someone else will have some tips.

So it won’t let you

Remove Door from Hell from play.

Or move it out of scope?

Here is another thing I don’t understand, maybe because I don’t fully understand what the word scope is saying.
I read about “scope” yesterday, but didn’t get it.

Glad to hear!

Yeah, I start to get it now. I really have to dig a bit deeper into what the “words” instead, before, after and so on actually does.
Their more than words, they are powerful rules and commands. (repeat x1000)

I liked what you did to the door, good solution. Learned a lot from it.
(That’s something I like about Inform7, when you explain one thing to me I start to see how it relates to other things as well. Easier to see bigger pictures in I7 than when writing stuff like
if x=y,
else when z;
come on, do f now;
or else;

I had a lot of fun writing ActionScript 3 a couple of years ago, but it was hard to remember stuff and also hard to see bigger pics. )


Do I miss something here?

This code does not remove the default (first opening door from hell) when I try to go west when door is locked.


Removing it from play won’t work. It compiles, but it throws a run-time error when you shake the thingy: “P44 - Attempt to remove a door from play… 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.)”

Even if you could remove it from play, it would not work as intended since the player would still be stuck in the office even so. The door is east from the kitchen and the office is east from the door. With no door, there is no more connection between office and kitchen.

That is considered normal behavior. The implicit “(first opening door from hell)” means, before we go west we are attempting to open the door from hell. If you don’t want that message to show up, here is one way to stop it:

Instead of going west in office when Door from Hell is locked, try opening door from hell.

I thought you could simplify that to “instead of going through locked Door from Hell,” but for some reason the compiler trips up on this line because the name of the object has the word “from” in it and it thinks I’m talking about “going from” a room called “Hell.” It looks like the compiler is actually case-sensitive here - if you capitalize “From,” it works!

Instead of going through locked Door From Hell: try opening Door from Hell;

If I were writing this, I might rename it Hell-Door and give it the printed name “Door from Hell,” just to make the compiler’s job easier.

I was going to mention the “from” earlier, but didn’t want to look like an idiot if I was wrong! :stuck_out_tongue: