How would you like to see containers implemented?

My initial thoughts would be to have ASL like the following:

define object <backpack>
	add {
		if ( #(quest.thing):size# > 50 ) then msg <That's way too big.>
		else {
			move <#quest.thing#; backpack>
			msg <You add #(quest.thing):article# to the backpack.>
		}
	}
	
	remove {
		move <#quest.thing#; #quest.currentroom#>
		msg <You take #(quest.thing):article# out of the backpack.>
	}
	
	look empty <It's an empty backpack.>
	look contents <It's a backpack, containing #quest.contents#>

end define

The "add" tag defines code for when things are added to the object, and "remove" defines code for when things are taken out. As with other Quest tags, you could also use:

add <You put it in the bag.>

or just

add

to allow things to be added automatically.

Is this flexible and easy enough? Is there any functionality that I have missed?

We'll obviously get a couple of questions saying "how do you limit by weight" or "limit by number".. Which should be easy to add via coding.

Just saw the #quest.contents# bit..
What does this actually refer to?
Also, what format does it come out as?

Say we have a backpack and a toybox - both containing objects.. You the toybox be inside #quest.thing# and the contents be inside #quest.contents#?
Would it not be easier having something like #object:contents# ?
Or perhaps an array of some sort, which would be good for custom descriptions, quickly getting a count of how many objects there are inside a container, etc. All could be stored as properties...
How are we to check if an object's inside a container?
is it going to be able to be treated as a room?

So if we use the $getloc(teddybear)$ we get the "toybox" room returned?

How about the useful verbs - will look automatically look inside container objects in the current room?

Ie:

> look in toybox
The toybox contains a teddybear and a transformer!
> look at transformer
The transformer is an old one you recieved for your 10th birthday. This one is an airplane at the moment.

As far as I know, there isn't a real 'function' you've missed out there...

I take it you'll have "empty" to remove everything from a container? Perhaps fill to take everything from inventory (one at a time I hope) and put it into a container (just incase the object won't fit/etc).

I hope this has given you something to think about.

is it going to be able to be treated as a room?

and

How about the useful verbs - will look automatically look inside container objects in the current room?

I am interested in the answer to these questions myself. If container objects are to have correlated inventory rooms, then verbs such as 'look' will have to check each 'open', 'accessible' container. Here's a scenario:

I enter a room where there is a bucket container. This container is always 'open', but it is hidden underneath a table. I 'look under the table'. This makes the bucket 'accessible'. But I have not looked in the bucket yet. There is a key in it. I 'look in the bucket'. Now the key can be made accessible to common verbs 1) here, 2) when I discovered the 'open' bucket, or 3) right from the get go.

I guess it all depends on how I want to structure the room. Is finding the key a puzzle, albeit simplistic? Perhaps I want the key accessible immediately. If the container is transparent, then at point 2 I'd want the key made accessible to common verbs (such as get, look, etc.) In any case, I'm interested in how this would work for Quest 4.0.

Any chance you'll loosen the distinction between rooms and objects?

In what sense were you thinking the distinction could be loosened?

Take a look at Inform, TADS, Hugo, or even AGT.

Well, rather than me go through all that, it would be most pleasant if you could just elucidate. A sentence or two.

Okay, in Inform, object has a more general meaning. Every room is an object. Every noun is an object. The player is an object.

Object A is in room B: parent(A) == B
Object A is held by player: parent(A) == player
Object A is in object C: parent(A) == C

There's no need to create special rooms corresponding to the inventory or contens of a box.

You don't need to code a separate room for inventory - it exists whether you've got a "define room <inventory>" or not.

Similarly the implementation of containers won't mean having to code up a separate room for each object that can contain something.

So in ASL you could code a parent property for each object. That is, object:parent. This could work with a second property, a la object:parent_type to distinguish if the object is "in", "held by", "worn by", etc.

I take it Inform distinguishes automatically, "under the hood"?.

In the case of Inform:

Parent object has container attribute: A is in B
Parent object has supporter attribute: A is on B
(Objects must not have both the container and supporter attribute, though there are ways to get the effect of an object that is both container and supporter; see _A Nasal Twinge_.)
Parent object is player, child object has worn attribute: A is worn by player.
Parent object is player, child object hasn't worn attribute: A is carried by player.
Parent object is not player, has animate attribute: A is carried by B.
Parent object does not have container, supporter, or animate, and isn't the player: A is a "subobject" of B. (For example, the buttons on a keypad would be subobjects of the keypad.)