Containers are not officially supported and the coding is incomplete.
They are partially implemented but the functions around them are not yet fully written. As such, I just document them as unsupported.
I think the following works for example (I can't quite remember so don't hold me to this):
But it's not yet clear or settled how is_present works for objects inside a bag you are carrying as well as there being other edge conditions. Also unclear is if you might want to add the weight of all items in a bag to the parent container weight, or if you might want containers that act magically and don't propagate the weight of their contained items.
I did some work with reachability of contained items I recall too, about if items in containers that you are holding are instantly accessible or not or if you have to take them out of the container for them to be accessible. I didn't do any work for automatically removing items from bags if they were useful.
Adventuron Classroom was intended to be the beginner level variant, and the jams have if anything, started to creep into advanced level functions.
Generally speaking, personally speaking, I think containers are a solution in search of a problem. I am attempting to support them for reasons of compatibility and because it's "just like my opinion man", but personally speaking (again), I just find containers to be a grind.
Containers are useful for a variety of things... I've needed to use them twice in the game I'm writing, but I've just got around them with commands. You can use them to hide objects so the player has to search, or you can use them to complete tasks "put ballot in box" kinda thing.
I guess you could limit them to being unmovable scenery objects, and the person has to look at them or open them to bring the contained objects on or in (depending on type) to having the same parent as the parent object... If they're not a scenery object, they're a bag where the things inside aren't reachable by default. I'm spoiled by using Quest which has a bloody complex container system with surface, bag, seethrough, opaque and all kinds of other containers :D haha.
I guess you could make the inbuilt bag functions pretty basic, and let advanced people write scrips if they want to make them more flexible. Having object ON a scenery object might just add (on Table) or somesuch to the description, and that's all!
I don't think I've ever written an adventure that doesn't have containers and supporters (or bags and surfaces in Adventuron parlance), even way back in the days of BASIC adventures. I had three pseudo-containers in 'Seeker of Magic' and the coding to implement them was quite complicated. They weren't true containers either, as I couldn't put things in them.
My next adventure (still in the design phase) will have several surfaces, one surface-like (enterable) object and several containers of different types.
For me, being able to refer to generic nouns is the number one priority, but containers are certainly high up on the list.
You *can* make containers using the scripting language. It's a teeny bit messy, but there's enough flexibility in the system to allow you to pretend. The only real limitation is the VERB NOUN match construct limitation, because that prevents PUT x INSIDE y or PUT a ONTO b, but it looks like those are being worked on at some point....
I think the way Quest handled containers is pretty cool. It has a reachability calculation which is quite sophisticated. :)
: match "put lamp" {
: if (preposition_is "on" && noun2_is "table" && is_carried "lamp" && is_present "table") {
// Do something
}
}Yes, I know this is currently sub-optimal, but if you need it it's there and it does the job.
As far as disambiguation goes, it's not fully there yet. A whole new structure of match patterns that are subject and subject context centric is planned.
For now, disambiguation works for gets, drops, examine, wear and remove commands.
I don't want to harp on this, because it isn't relevant to the jam, but I am curious and raise it because it may have an influence on your future match statement format.
It looks like there is only provision for one preposition, but this doesn't account for where the preposition is located within the command. For example TURN ON LAMP and TURN LAMP ON mean the same thing, but JUMP ACROSS CHASM and JUMP CHASM ACROSS are definitiely not the same thing. The latter is rubbish. There are also situations where the presence or absence of the preposition changes the order of the direct and indirect object. The classic example is GIVE SWORD TO TROLL vs GIVE TROLL SWORD. The former is the more common syntax. You might like to say that the latter format is not supported, the direct object must precede the indirect object and they must be separated by a preposition.
This still doesn't account for the situation where you need two prepositions. I can't think of a good example off hand, but something like CHOP UP CARROT WITH KNIFE or TURN OFF MACHINE WITH LONG POLE or REACH INTO HOLE WITH STICK or WRAP UP PARCEL WITH BROWN PAPER.