Let's talk about containers - I'd like some feedback as to whether you think they're implemented sensibly.

I've just thought of a refinement about adding/removing objects from a container. Currently, if you have a container and you've set the "add" option so you can add anything, you really can add absolutely anything to the container.

This means that if you have a room called kitchen, with a "fridge" object that's a container, you can put everything inside the fridge. Including the window and the kitchen sink.

This I think is a bit silly. Would it make more sense to only allow players to put objects in/on something if they're currently carrying the object? That way you would have to take something first before you could put it in the fridge.

Would this make puzzles a bit tedious though, having to take the object each time?

Would it be even better if, when "add" is on, you can by default only add take-able objects? That way you don't need to pick up an object before putting it somewhere, but you would have to at least be able to.

What do you think?

It definitely makes sense to restrict the kind of objects to put into a container - the 'takeable' criterion is a good one to use.
The common convention in IF seems to be that you have to have a thing in your hands before you can put it anywhere, so not having this as a criterion in Quest might go unnoticed - more or less everybody will try to take the object first before putting it anywhere anyway.

Could there be a size property (and also a weight property)..

Objects larger than the container's size would stop it going in - while weight would be a running total/maximum.

Ie, with just takeable objects, you would still be able to put the garden pole in the jewelery box..

You could use a script for that though - the jewellery box's "add" script could check #(quest.add.object.name):size# or whatever and then add the object or not as appropriate.

I think it is something that should be left to game developers. In the end most people are going to handle inventory on a case by case basis, and a universal standard predefined would just put up more roadblocks for customization. Some people may want bags/sacks and such for bags, others may want a magical "You are carrying: Everything" type system, people may want each of the player's hands to be a container, it's just too varying by person.

Containers aren't at all difficult to implement, and having to override built in things would just make it harder for people already capable, when others could just use a library.

Hi

In my (defunct as of Q4) 'typelib.qlb' I used a type called 'TLTcontainable' to indicate if an object could be put inside a 'TLTcontainer' type object.

It might be a good move to use a similar idea now, making anything you want to be able to 'contain' a 'containable' type, this type could then have size/weight properties.

Then for 'containers' you'd just need to test anything you tried to put in to check it was not too big/heavy by reading the size/weight properties. As these would not exist for non-containable types, you'd automatically prevent silliness like being able to put the garden shed in your backpack or whatever.

Al

^^
(ITID)

I was going to say this too - but was unsure which was better:
1) A single default form, which can be overridden easily by setting a number to 0.
2) A more general one where coders need to create the code.

Oh, I guess to answer the direct question Alex gave, I'd opt for both in the room, and in items in your inventory should both be able to be put in containers... I guess takeable objects would actually be the only objects you can put in other objects.. I can only think of water as being an objects which you *wouldn't* be able to just 'take', without putting it *in* a cup.

(actually, in that situation - would typing "drink water" be suitable? Would it check inside the 'cup' container object for the 'water' object? Then it'd check the 'verbs' or whatever? I'll check it out tonight if I can.. As you don't want to keep coding ways of checking objects inside containers for commands... and you don't want commands like "drink cup" ... Does quest automatically parse "#do_something# from #object#" - in which case you can just have a "#do_something#" command..)

.. Just a couple of idea's I can't try out right now..

Here's how the issue is resolved in Beta 3:

Putting an object in/on a container/surface

For example, "put eggs in fridge".

Unless you're using a script for "add", here is the logic:
- When putting an object in or on another object, the player must be carrying the object. (e.g. you must be carrying the eggs)
- If the player is not carrying an object, but the object is in the same room, then Quest will try to pick the object up first using the "take" command. (e.g. it will run "take eggs")
- If this succeeds (i.e. if the object ends up in the inventory), it will then put the object in/on the container/surface.

This means that the new logic is essentially transparent - if the eggs are take-able, and the fridge accepts objects, you can put the eggs in the fridge without having to explicitly type "take eggs".

This logic works even if you override the "take" command completely, or specify a "take" script, since Quest checks the inventory to see whether the take was successful or not.

Taking an object that is in/on a container/surface

e.g. "take eggs", when the eggs are in the fridge

Unless you're using a script for "take", the change in logic is similar to the above:
- If an object is inside a container, it cannot be taken. It must be removed first.
- If the player tries to take an object which is inside a container, and the object is take-able, Quest will try to remove the object first using the "remove" command. If this succeeds (i.e. the object is no longer inside a container), it will then take the object.

Hope this makes sense (both my description and the actual logic itself) - any questions, thoughts or suggestions please let me know.