I’m having a little trouble identifying if things that are present are within containers. This matters as there are various odd effects that occur with contained objects that I’m trying to resolve, eg you can’t examine an item in a container, which is awkward if the container is an open cupboard; you can put an object into a container even if that container is within another one that is closed. Is_present picks up everything in the location, contained or not, and there is no is_contained as far as I can see.
I could work around this by checking if subjects are in containers if I could get this to work with s1() and s2(), but it isn’t having it:
is_within { outer = s2() inner = s1() }
Is the above something that just won’t work with subjects, or is it as simple as the syntax being incorrect (I’ve tried various permutations but I can’t figure it out).
Thanks Garry - that might work. I’ve used parent_of for a bunch of other things, but not this. I will experiment further.
My troubles arise as I have portable containers that can be put into other containers, eg a bottle in a cupboard, and I need to check if the container that I’m trying to put something in is already contained in another container that isn’t open (I have an open_t trait that I attach to open containers that I can check for that). It occurs to me now that I could add a trait closed_t to any closed container and then check eg PUT MATCH IN BOTTLE with something like if parent_of (s2()) has_trait =="closed_t", which will tell me if the bottle I’m trying to put the match in is already in a closed container. But I don’t think such a function is available at the moment. I can check object by object to see if each container is present and if it contains another container, but it feels like a bit of a clunky way of doing it.
I’m using a bunch of containers and supporters in my Christmas jam entry. One of those is an opaque openable container and one is a transparent openable container. Each has a boolean property to indicate whether it’s open. This could just as easily be done using traits. (I am using traits for something else.) When examining the opaque container, I check whether it’s open, then print a message accordingly (either “It’s closed.” or the contents of the container if it’s open). When examining the transparent container, I print the contents regardless. For getting objects out of these containers and putting objects into them, once again, I check the boolean first and act accordingly.
Another thing you might want to consider is using Adventuron’s object weight property to indicate the size of an object. Assuming you can only put a small object inside a larger object, you can do a test something like this before insertion:
: if (weigh(s1()) > 1) {
: print {("The " + original "noun1" + " won't fit in the thimble.")}
: done;
}
In this way, you can put the needle in the thimble, because it has a weight of 1, but you can’t put the ladder in the thimble, because it has a weight of (say) 20.
If using traits, you don’t need an open_t trait and a closed_t trait. Use something like : if (s1_has_trait "open_t") to test whether it’s open and : if (!s1_has_trait "open_t") to test whether it’s closed. The exclamation mark means NOT. If it’s not open, then it’s closed.
I haven’t had to deal with putting containers in other containers, but it is feasible, so I need to test that.
Thanks - I’ve got most of this already (booleans for open containers and their negation if closed - I know I don’t need a separate one for each state!). I’m using traits not weights though, to assess if things can go into containers (things are either too big to go into any container, or small enough to fit in a matchbox; anything else can go anywhere).
I think I’ve got where I need to be with this unanticipatedly complicated thing that I’ve implemented: several containers, nestable, and pourable liquid that can be transferred between. I expect that this is something that would be included in the standard library of eg Inform, so would be a given rather than having to do it all by hand? In any case, I’ve more or less done it so even if this thing never sees the light of day I can at least bask in that achievement (it can be a tiny postscript on my tombstone).
FYI I’m using a variation of the code outlined here (end of thread) for the containers: Getting ALL from a container in Adventuron, which does work well although it’s a faff to add a new container (code has to be updated in half a dozen different places).
Disambiguation is still a bit tricky, but that might just be a general thing and not strictly to do with containers. I’ve taken the path of least resistance and changed the names of the objects rather than continuing to struggle with it (I had two bottles, now I have a bottle and a flask). It would also be handy to be able to check if a container held objects with a particular trait, but that can’t be done at the moment as far as I can tell. Never mind, I have worked around the limitation.
Containers officially are still not supported largely because of issues such as these. Adventuron will certainly support containers fully in a future release including all the usual boilerplate, but right now, using containers is the wild west. Sorry for your pain.
Do know that a future revision will allow you to excise all or these workarounds. Just not yet.
I know! I am way out west and struggling through the thicket. But this is fine because it is forcing me to learn how to do it the hard way (I’m more or less succeeding).