I just started working with Quest, and discovered a bug with containers.

Create a closed CABINET with glass doors - container, transparent, open, close, add, remove
Create a takable closed BOX inside the closed CABINET - take, container, open, close, add, remove, parent = CABINET
Create a takable KEY inside the closed box - take, parent = BOX

"LOOK AT CABINET" the to see the BOX inside; you'll find that you can "OPEN BOX" to see the KEY and you can "TAKE KEY" from the BOX - all inside the closed CABINET (but you can't "TAKE BOX" until you "OPEN CABINET").

I don't see an easy work-around. Any suggestions?

You probably can't fix it while working within Quest, because Quest hardcodes it standard library into the executable. You'll have to wait for the next version of Quest, or completely implement your own library.

Are you _SURE_ the cabinet's closed?
Have you tried opening and then closing it again before opening the box?
Are you doing this straight from blank, or any libraries whatsoever?

Thanks for reporting this - I've added it to the list.

As a workaround you could use a script for the key's "take", to check if the cabinet is open first.

It's a workaround, but it can be tricky to do it correctly.

Pathological subcases:
- Player gets the key, closes the cabinet, drops the key, takes it again.
- Player puts something else in the box then closes the cabinet.

Yes, I made SURE the cabinet is closed, and there are NO included libraries in my test case. I guess Alex's "take" workaround is the only answer for now -- even if it is "tricky", I'm sure it can be done.

I discovered this problem while testing every variation of accessing surfaces and containers (and their contents) I could think of, just to make sure I understood how they work BEFORE scripting player interactions. I've been using the attributes (CLOSE, OPEN, LIST) and properties (OPENED) of containers as a way of opening and closing doors between rooms (CREATE EXIT), and adding locks and keys (LOCKED, KEY=) capabilities.

I have always loved text adventure games since the days of my very first computer (just to date myself... it was a VIC-20 ...some of you young'uns won't even know what that is). Started programming in BASIC then directly in assembly language, but have been away from things for a few years. I like the "feel" and "flexibility" of ASL, but find QDK rather cumbersome. So far, I'm only experimenting with the capabilities of ASL, but hope to begin developing a game soon. I'm finding earlier forum discussions helpful, and will probably be posting a few comments and questions as I proceed.

I fixed this bug in Quest 4.04, which is available now, so please upgrade and let me know if it works!

What other IF systems have you looked at? If you prefer coding ASL directly to going through QDK, you're probably better off with TADS or Inform.

A thanks to Alex. Guess I wasn't the first one to find the bug. Downloaded version 4.04, haven't had a chance to check it out yet.

I haven't tried tried any other IF systems, and am totally satisfied with Quest for now. Don't want to confuse my poor old brain.

OK, just wanted to say I didn't want to appear ill tempered in my previous post.

This was supposed to just clarify details which might have also contributed to the problems.

As Alex has coded a 'fix' then perhaps try going in X deep (box in a bag in a chest in a draw in a cupboard)?