I know containers are experimental, but I've got three containers and I'd like to give it a go. I've set up a container-like object (and its contents) as follows:

   paper_bag: object "a paper bag" container_type="bag";
   pickle_sandwich: object "a pickle sandwich" start_at = "paper_bag";

Where do I go from here? How do I specify whether the container is lockable, locked, openable or open (assuming that's possible)?  I've tried opening my container, but it just says "Not right now." Are there any tests I can use to test for the above properties, or statements that I can use to set those properties?

Unfortunately, it doesn't appear that a scenery object can be a container, so if I've got a wardrobe (for example), I have to make it an object, then I can carry it around. Bummer.

I don't have any surfaces in this game (like tables), but an example of surfaces would also be appreciated.

Containers are not a feature of Adventuron Classroom.

There is some preliminary support (which is what you found) but it's incomplete and should therefore not be used. Once it's ready, it will be documented. 

Very sorry.

I'd image that, for most people, anything simple you'd want to do with containers could either be done with object swapping or objects & flags. 

So, what's the workaround? By flags, I presume you mean booleans in Adventuron parlance. One boolean per object to indicate open or closed? Another one to indicate locked or unlocked? What happens when I open a container? How do I indicate what's inside? How do I put things in a container? Not easy with two-word input. How do I hide objects in the vontainer when it's closed again?

If I start with an object in a container, I've noticed that an is_carried test on the hidden object returns true. That caused an action to pass when it should have failed because the object had never been revealed. Is there a test for immediate children of the player without testing for grand-children?

The container issue is the only thing that's preventing me completing the coding. I think.

Containers were always going to be pretty much off-limits with the VERB NOUN restriction of the jam.

There is usually a way around most things. What *exactly* are you trying to code?

You mentioned a paper bag and a sandwich earlier? Was that a real example?  Is the idea that you take the sandwich out of the bag and you put something else in it later?

When I was talking about item swaps, etc, I was thinking of things like... OPEN BAG/EMPTY BAG... You find a sandwich... (swap 'full bag' with 'empty bag', create 'sandwich')
and later on you may...
FILL BAG... You fill the bag with sand from the shore. (swap 'empty bag' with 'bag full of sand')
or
HIDE APPLE/PUT APPLE (trying to get around the two word restriction!)... You hide the apple in the paper bag...

I guess, technically, you could code your own container routine by using the location movement trick I mentioned in another thread... Having a'blank' location set aside as the 'container insides', but that would really need (like any container puzzle really) four words to work, rather than the two that have been specified in the jam.

The paper bag and sandwich was just an example. I've been thinking about it during the day and think I have a nice workaround that will work for the cave jam. Each container has a boolean variable to indicate whether it's open or closed. It's initially closed. Examine tells you whether it's open or closed. When you first open it, the contents fall out. You can't put it back in. You can close the container. When you reopen it, it will say it's empty. The puzzles related to this aren't complex, but the containers are needed for realism. You'll see what I mean in due course.

I like your suggestion about the dummy room. I was thinking of this myself, but, as you said, it really requires multi-word input and that's outside the scope of the jam.

Can't wait to get home and try this.

The location method, for containers, is how the PAW does it. Every object in the PAW that's a container, needs a corresponding location, where stored objects are located. It's a rather clever little 'hack'. When you program in PAW, you get used to thinking outside the box (or container... or indeed, location). The building blocks in that system are so simple but you can string them together to make quite complicated systems.

An alternative to using a boolean, in your case, would be to simply have both an 'box_open' and 'box_close' object, and swap between them, using that as the way of checking the status of open/close. In your case, though, I have a feeling the boolean check might be simpler... although it would probably work out about the same in terms of lines of code.

In case anyone else is interested, my idea about dumping the contents of a container when you opened it worked, but it didn't make sense from a user's point of view. If you open a container while you're carrying it, then it makes sense for the contents to fall out. But if you open a container when you're not carrying it, it doesn't make sense for the contents to fall out. I've now handled it differently. When you open a container, it tells you the contents. You can then take the contents using :pocket "object". Once taken, you can't return it to the container or put anything else in the container. You can examine the object before or after taking it out of the container. You can open or close the container at will. If you open it when it's empty, it tells you it's empty. When you examine the container, it tells you it's closed OR it contains an object OR it's empty. Whew!

As I have three different containers, none of which are quite as simple as what's described above, it was quite a lot of hard work getting all the tests right for all the different conditions. Anyway, it's done now, so I'll know how to do it in future.