Here's the situation:

I have a container object (named "device".) I also have four key objects in the game; red key, green key, blue key, and black key (with object names, greenkey, redkey, bluekey, and blackkey). Using the "Advanced" tab, I create a boolean property "is key" on each one (but on no other objects in the game). The keys are takeable, and the device is not. The device is set up so that it's neither openable, nor closeable. The player also can't remove objects from it, but adding objects is controlled by a script.

What I want is for the user to only be able to add the keys - "Put key in device" - to the container, but I can't get it to evaluate quest.add.item.name to the actual key object. I think the logic of the script is correct, but the syntax of the if comparison is wrong. It says in the script area (when I click on the Add verb in the container tab):

if #quest.add.item.name# has the property "is key" then
...

I believe that the game engine is trying to evaluate "#quest.add.item.name#" down to "#bluekey#", "#greenkey#", "#redkey", or "#blackkey#" when I (during playtesting) use the keys in the 'correct' manner, instead of evaluating them to the object named by "#bluekey#", etc... so that it'll test the object, not the string "#bluekey#" to see if it has the "is key" property.

I've even tried removing ".name" from the above test, thinking it ("#quest.add.item#") would then evaluate to an object, but nope!

This is driving me nuts, as there's got to be a way to make a container that only holds certain types of items. And this (the Quest game I'm currently working on) isn't the only one I'd like to use this technique on! And hard-coding the item names isn't flexible, because what if I want to add a yellow key, or a gold key? Then I gotta rewrite that part of the script again - YiQ!

For anyone whose interested, email me and I'll attach the .cas file (so far) for you to play with. It's a spoof of Myst, a sort of Myst pre-history involving a hacker, some desert islands, and... Oh, wait. I'll give too much away.

Ok, where did you get "#quest.add.item.name#" from?
From what I see it's not in the obvious places of the help file (containers/built-in strings).
.... oh, I've got it now.... The help documentation might need a bit of reviewing!

Quest should evaluate that down to "bluekey" "redkey" etc (so yes, you're correct).
Without looking at the code itself, we won't know precisely what's going on - but I'd suggest looking at:
1) the boolean property (try using one word - or underscore - as a property name.... eg. 'key' or 'is_key')
2) the object definition.. Sometimes the container stuff can be a tiny bit tricky.. double check everything is ok.

Tried replacing 'is key' with 'is_key'; no effect. Here are the relevant sections from the asl file.

define object <bluekey>
alias <key>
look <This is a blue, metal key.>
take
prefix <a blue>
displaytype <Object>
article <it>
gender <it>
properties <is_key>
end define

define object <device>
look <The device takes 4 keys. It has a red button on it.>
take msg <You can't - it's welded to the metal pole.>
prefix <a>
displaytype <Object>
article <it>
gender <it>
container
transparent
open msg <You can't - it's hermetically sealed.>
close msg <It's already hermetically sealed.>
add {
if property <#quest.add.object.name#; is_key> then {
msg <You insert the key into the device.>
add <#quest.add.object.name#; device> } else msg <You can't add that to the device - it doesn't fit the keyholes!>
}
remove msg <You can't - it's stuck.>
list {
if property <bluekey; parent> then msg <The blue key is inserted into the device.>
if property <redkey; parent> then msg <The red key is inserted into the device.>
if property <greenkey; parent> then msg <The green key is inserted into the device.>
if property <blackkey; parent> then msg <The black key is inserted into the device.>
}
list empty <There are no keys inserted.>
end define

The other keys (greenkey, redkey, and blackkey) are defined similarly to bluekey, save for the name, description and the prefix. Further investigation reveals that it's not even calling the add action on the 'device' when the player types 'put key in device' - it just says, "You can't put that there." instead of my custom message.

Problem solved. Lesson learned? Make sure script-controlled containers are open initially! The Clue? It (QDK) was giving the standard response instead of the custom one I put in, yet the scripts for controlling the listing of the container contents worked perfectly!

So let this be a lesson - when you control access to a container object (via the "add" and "drop" actions), make sure the container is open so the player can attempt to put stuff in it. And - of course - control the "open" and "close" actions as well if necessary!

oh, I think I can across something very similar before!!

I couldn't put something on a surface because of some similar problem.... or something.

Glad you figured it out!