I've set a door to object and activated the container function, making it openable / closable.

I have Can be opened and Can be closed ticked, and Is open not ticked.

Then I run the following script on When opening object:

if (GetBoolean(door2, "shopopen")) {
  msg ("The door's already open. You peer inside.")
}
else {
  firsttime {
    msg ("You push on the door and hear it scape over dirt and grime. You stand on the threshold and peer inside. The shop's interior looks dank and is clearly not in use.")
  }
  otherwise {
    msg ("You stand on the threshold and peer inside.")
  }
  SetObjectFlagOn (door2, "shopopen")
}

And then on Script to run when closing object I have:

msg ("You close the door.")
SetObjectFlagOff (door2, "shopopen")

But when I run it, open the door and then try to close it, I get The door is already closed.

What's more, the close door command is not removing the flag which sets it as open.

I suspect that Quest has its own open/closed flag. Your "shopopen" one is known to your code, but Quest has no idea you opened the door, since you didn't set its open flag. And its checking its own flag before calling your code.

Just a guess... I need to get Quest installed on my new computer!

Ah! Thank you.

I think there's a better way to handle this, but that's usually the case where my logic is concerned.

And yes, install Quest and come back aboard!

I believe the controlling/determining (Boolean) Attribute used by quest for whether the door is opened/closed is:

isopen ( http://docs.textadventures.co.uk/quest/attributes/isopen.html )

where-as, I believe there's the 'openable', 'opened', and 'closed' Inherited Attributes / Object Types (Types), which give Objects their properties of opening/closing, being initially open/closed, and etc functionality via through using the GUI/Editor, but what quest actually uses for the state of the Object of-as of being opened or closed, is the 'isopen' Boolean Attribute.

Here's the Attributes for Objects (this is a good thing to study and learn up on):

http://docs.textadventures.co.uk/quest/elements/object.html

Don't make doors containers... always worked for me.

XanMag
Don't make doors containers... always worked for me.

But how do you handle the open door command?

You create a room, for example Factory.
Inside that room, create an object called like "Locked Exit 1" for example. It would like this in the tree of stuff...

factory
Locked Exit 1

On that "Locked Exit 1" object, find the "exit tab" and check the "locked". Then check "run a script" with an "if script" attached. It might look something like this.

if (Got (Key 1)) {
   UnlockExit
}
else {
 msg ("Oh nooooes! You need a key first.")
}

Alternatively, you could do a super easy thing too...create a flag on the new "exit's attributes" in this case "Locked Exit 1"
exit attributes
add, flag.boolean set to False
Then check "run a script" with an "if script" attached.

if (Locked Exit 1.flag=False) {
msg ("Argh! You need a key you nasty vermin!") 
UnlockExit
}
else {
msg ("You unlocked the door you scaliwag!")
}

Then when the player takes "Key 1" set the flag to "True" with...
Locked Exit 1.flag=True

Hope that is what you were talking about @_@

Anonynn.

Thanks, Anonynn. That's pretty much what I do, although I don't create an additional object within the door. I just make the door the object then check for flags and run scripts etc.

I was just wondering what Xan meant when he said don't make doors containers.

For the record, Xan, the reason I make the door a container is because it creates the open verb in doing so. What I mean is if you don't make the door a container, how do you handle the open verb?

I think... Xan means this (or I could be totally wrong):

to use the 'openable' Container Type for/in the GUI/Editor's drop down menu: http://docs.textadventures.co.uk/quest/attributes/openable.html

(and not the 'container_open/closed' nor the 'surface' Container Types / Object Types / Inherited Attributes)

^^^^^^

http://docs.textadventures.co.uk/quest/elements/object.html (scroll down to the bottom to find the Inherited Attributes / Object Types (Types))

It looks like you can use the 'lockable' Container Type too, and I think the GUI/Editor is handling this for you via you checking in the 'can be locked' check box, as otherwise, to give your 'door' Object multiple Inherited Attributes, you have to do so in code, as I believe in the GUI/Editor, you got a drop down menu for selecting the Container Types, meaning you can only pick one of them. But as I've said, I believe you choose the 'openable' Container Type in the GUI/Editor's drop down menu, and then you can check the 'can be locked' check box, which I believe underneath adds the 'lockable' Container Type to your 'door' Object, as well as the 'door' Object getting the 'openable' Container Type added to it via choosing it in the drop down menu.

Ahh, I see. So how do I set an object to this instead of a container?

I just edited my previous post, so refresh and read it again... and I think it'll answer your question.... hopefully.. corectly, lol

technically, the 'openable' is a Container Type in the underlying code, but for the user-level usage, the 'openable' is not a "refrigerator/chest/cabinet/dresser/whatever-like container" where you can put/take Objects into/from it after opening/closing it, it's just a "door/whatever" that you open/close, it can't "contain" other items/Objects within it like the 'container_open/close' and 'surface' Container Types can.

HK edit, the above is wrong in that the 'openable' is NOT technically a Container Type, my bad.

so, here's my best attempt at how the Inheritance/nesting/layers work / is set up / organized / designed / structured:

Container Types:

container_base (makes the Object openable/closeable, via also adding/including the 'openable' Object Type, and able to contain/take/put/display other items/Objects within it --- basically this has all the functions for handling container functionality)

container_base -> container_open (it is specifically set as initially being open)

container_base -> container_open -> container (as it inherits the 'container_open', it is initially set as being open) // I'm not sure how this is different/needed compared to just: container_base -> container_open, I don't know what makes 'container' different from 'container_open', lol

container_base -> container_closed (same as 'container', but it is specifically set as initially being closed)

container_base -> container_open -> container -> container_limited (added feature of limiting the quantity of Objects within it, via using the 'maxobject' Integer Attribute)

partial/quasi (or full/is a) Container Type:

container_base -> container_open -> surface (transparent, open container, but can't be closed)
or
container_open -> surface (transparent, open container, but can't be closed)

meh

Lockable Type:

container_lockable (this able the 'lockable' Object Type / Inherited Attribute, adds the locking feature to the Object. While this is not a Container Type: it doesn't include/add any container properties/features, it DOES require the Object to specifically have the 'open/close' Scripts, so you'll need to also add/include the 'container_closed/container_open/container_limited' Object Types / Inherited Attributes. It is not a Container Type, but it requires being paired with a Container Type)

Openable Type:

openable (adds the 'open' and 'close' Boolean Attributes, which set whether the Object can be opened/closed, this is the functionality of opening/closing, NOT the actual state of whether it is open or close during game play. The 'isopen' Boolean Atribute handles the actual state of it currently being open or closed)

(again, note that the 'isopen' Boolean Attribute, is what is actually setting/determing an openable Object's current state of being during game play, as in, is it: open or closed)

Switchable Type:

switchable (getting tired... grants the 'on/off' functionality to an Object)

I might be a bit late to the party here, and honestly I didn't read anything after you asked about how to handle the open verb...
Scroll to the bottom if you don't care to look at the code below.

  <object name="room3">
    <inherit name="editor_room" />
    <description>There is a door to the south.</description>
    <exit alias="out" to="room1">
      <inherit name="outdirection" />
    </exit>
    <object name="door">
      <inherit name="editor_object" />
      <look type="script">
        if (GetBoolean(door, "ajar")) {
          msg ("This door has been opened and you may now enter the adjacent room.")
        }
        else {
          msg ("The door is just a door.  And... it is shut.")
        }
      </look>
    </object>
    <command name="open door cmd">
      <pattern>open door</pattern>
      <script>
        if (GetBoolean(door, "ajar")) {
          msg ("It's already open, you goon.")
        }
        else {
          msg ("You open the door.")
          SetObjectFlagOn (door, "ajar")
          SetObjectFlagOn (door1, "ajar")
          UnlockExit (doorlock)
          UnlockExit (doorlock2)
        }
      </script>
    </command>
    <exit name="doorlock" alias="south" to="room4">
      <inherit name="southdirection" />
      <locked />
      <visible />
      <lockmessage>The door impedes your path.</lockmessage>
    </exit>
    <command name="close door cmd">
      <pattern>close door</pattern>
      <script>
        if (GetBoolean(door, "ajar")) {
          msg ("You close the door.")
          SetObjectFlagOff (door, "ajar")
          SetObjectFlagOff (door, "ajar")
          LockExit (doorlock)
          LockExit (doorlock2)
        }
        else {
          msg ("Duh.  The door is already closed.")
        }
      </script>
    </command>
  </object>
  <object name="room4">
    <inherit name="editor_room" />
    <object name="door1">
      <inherit name="editor_object" />
      <look type="script">
        if (GetBoolean(door1, "ajar")) {
          msg ("This door has been opened and you may now enter the adjacent room.")
        }
        else {
          msg ("The door is just a door.  And... it is shut.")
        }
      </look>
      <alias>door</alias>
    </object>
    <exit name="doorlock2" alias="north" to="room3">
      <inherit name="northdirection" />
      <locked />
    </exit>
    <command name="open door cmd1">
      <pattern>open door</pattern>
      <script>
        if (GetBoolean(door, "ajar")) {
          msg ("It's already open, you goon.")
        }
        else {
          msg ("You open the door.")
          SetObjectFlagOn (door, "ajar")
          SetObjectFlagOn (door1, "ajar")
          UnlockExit (doorlock)
        }
      </script>
    </command>
    <command name="close door cmd1">
      <pattern>close door</pattern>
      <script>
        if (GetBoolean(door, "ajar")) {
          msg ("You close the door.")
          SetObjectFlagOff (door, "ajar")
          SetObjectFlagOff (door, "ajar")
          LockExit (doorlock)
          LockExit (doorlock2)
        }
        else {
          msg ("Duh.  The door is already closed.")
        }
      </script>
    </command>
  </object>

It seems like a lot of code for something so simple but copy-paste is marvelous. I've never had the best luck with container options. So, what I do often essentially is this:

1. Add a door as an object (non-container) to adjacent rooms. door and door1.
2. Add a command in the room with 'door' in it and type in open door. For this command script, I added a flag for 'door' and 'door1' called ajar. I use ajar because 'open' conflicts with the built-in Quest open. For each door I added a look at script to describe the state of the door (whether it is open or closed).
3. I also added an unlock exit script to each door object. You could add a make exit visible/not-visible, too.

o0 - seems convoluted, even for me.

I'm happy with my containers, now that I know Quest has its own 'open' flag, and that my problem stemmed from the fact I was trying to override it with my own flag.

I made the same mistake with the 'switchable' function, using torchOn, when Quest already uses switchedon