I am doing the tutorial and when I get to the 'Using lockable containers' section, my locked box containing the defibrillator opens without the key.

I created a "box" object in the lounge and made it a closed container. I moved the "defibrillator" object to the box. I added a "small brass key" object on the table (surface) in the kitchen and I made it takeable. I set the "box" object as lockable and locked with a key of "small brass key".

When I run the game. I can do "open box" as soon as I enter the game, without the key which is still sitting on the table in the kitchen.

I don't have access to the Issue Tracker forum so I can't search there and any search result I run across in the open forums isn't answering my question.

I am attaching a stripped down version that demonstrates the issue I am having. I assume I am missing something basic. Any help would be appreciated.

Running your attached test file (with no changes), I get this:

A lounge
This lounge is not just for lizards.
You can see a box.
You can go south.

> open box
It is locked.

> south

A kitchen
This is a bright cheery kitchen for bright cheery people.
You can see a table (on which there is a small brass key).
You can go north.

> take small brass key
You pick it up.

> north

A lounge
This lounge is not just for lizards.
You can see a box.
You can go south.

> open box
Unlocked.
You open it.
It contains a defibrillator.

When I run it, I get this:

A lounge
This lounge is not just for lizards.
You can see a box.
You can go south.

> open box
Unlocked.
You open it.
It contains a defibrillator.

It happens with the Test.aslx in my Quest Games\Test folder. Just for kicks, I downloaded the file attached to my above post and ran it straight from my Downloads folder and the same thing happens.

Very odd.

I'm running Quest 5.5.1 Build 5.5.5328.26623. I'm going to re-install since I have no idea what I did to break the engine.

Thanks for your help.

Uninstalled. Deleted Quest directories. Cleaned registry.

Re-installed.

Ran the Test game. Same thing happens whether I play it from the editor or play it from the recent list.

Thanks to jaynabonne for looking at it. No idea what I did to break this functionality in my install but I'm just going to continue to power through the tutorial and check on another PC later.

I haven't upgraded to 5.5.1 yet. I'm still on 5.5. I'll try with that latest version and see what I get.

Ok so apparently I was unable to keep calm and carry on with the tutorial so I continued poking at the issue and discovered the following.

If I set autounlock to false then it works as expected with the box remaining locked until I get the key from the kitchen.

When I set autounlock to true, the box opens even without the key in inventory.

Not sure if this is just me fixing things after having broken them or if it's an actual issue with the build I am using in general.

Anyway, now that I have it working as expected, I am diving back in to play with all the things.

chuckles, the defibilator part of the tutorial confused me too, as I also had a problem with getting it to work, but this was with a different issue with it and back a few quest versions. Keep up with the tutorial, you seem to be doing well with it, as it's a good first place source to get started with quest.

My understanding is that having autounlock set to true allows the player to type

open box

and as long as the correct key(s) is/are in inventory, the container will open. So autounlock is basically a convenience so the player doesn't have to type 'unlock box' and then 'open box'.

However, in the build I am running, having autounlock set to true allows the player to type

open box

and the box opens without having the correct (or any) key in inventory.

The problem only goes away when autounlock is set to false.

I downloaded 5.5.1, and now it fails for me the same way as it does for you. So something has been broken between 5.5 and 5.5.1.

The problem is that the box object has "key" and "keycount" but not "key1". That causes the function AllKeysAvailable to always return true.

If you delete the attribute "keycount" from the box, it should work as intended. Or you can rename the attribute "key" to "key1".

Actually, I take back what I said - it won't fix it. There is no workaround, short of modifying the code. There's a more insidious problem with AllKeysAvailable, and it's due to a quirk in Quest (unless it's been changed?).

The code is this:

  <function name="AllKeysAvailable" parameters="object" type="boolean">
    if (not HasInt(object,"keycount") and HasObject(object, "key")) {
      object.keycount = 1
      object.key1 = object.key
    }
    for (x, 1, object.keycount) {
      keyname = "key" + ToString(x)
      if (HasObject(object, keyname)) {
        if (not ListContains(ScopeInventory(), GetAttribute(object, keyname))) {
          return (false)
        }
      }
    }  
    return (true)
  </function>

The problem is that "return" sets the return value but *does not change program flow*. This has been a problem for those used to other languages for a while. So in the above code, the return(false) in the if may get executed, but the return(true) at the end will *always* be executed, even if the "if" is - because the code doesn't jump out of the function when it hits that return.

Really? I thought Alex changed that with Q5.5:
The “return” statement now immediately exits the function.

Ah ok. I missed that. Then it's the first thing I said. lol

That's good to know.

Thanks guys! You rock!