I haven't worked much with Object Lists and Object Dictionaries (aside from the "ScopeInventory" and the "foreach" functions or scripts), so I have a few questions on them, and would like to understand them better, compared to versus Objects simply being nested in other Objects or just simply with the scripts for moving Objects around.

Objects can be physically moved around, from within an Object, Player Object, or a Room Object, to another Object, Player Object, or Room Object.

Does this happen with objectlists and~or objectdictionaries too, when you add~remove from their lists~dictionaries, or is it "logical" in usage, and thus not "physical" like it is with moving nested Objects or script-moved Objects ???

Are Objects actually "placed~put~held" within the objectlist or objectdictionary ??? Or, no? How does this compare to Moving Objects around by scripts and thus nesting objects (objects placed within objects) ??? What's the difference, is there is any ???

and any other basic explanation of what Objectlists and Objectdictionaries are and can do, vs simply moving objects around via script and nesting objects (objects within objects) ???

As you've suspected, object lists and object dictionaries are different from the child/parent relationship that exists elsewhere in Quest. The latter is implemented by each object having a "parent" object attribute which can be set to the parent object that holds that child. This parent relationship is used by the Quest engine to conceptually implement things like containment, objects being in a room, etc. (Your use of the word "physical" in your question threw me a little, as even "moving" objects in Quest does not physically move them. Such moves are logical as well, with simply a new parent being assigned. I suppose if you are looking at it virtually, in the sense of the game world, then an object is "moved".) Given that each object only has one "parent" attribute, an object can only have one parent. In a sense, a child points "upward" to its parent.

Object lists and dictionaries are the opposite. They point downward to the objects that they contain. As such, an object can exist in multiple such lists or dictionaries at once. More importantly, Quest does not place any special meaning on such containment; there is no "physical" or virtual meaning to being in such a container, apart from what you assign to it yourself.

Dictionaries and lists are data structures you can use for whatever purpose you wish. For example, when you invoke GetDirectChildren on an object, Quest searches through all the objects in the game, finds all the ones with "parent" set to the object in question, and then adds them into a list to return to you. Once you're done with it, the list goes away. There is no meaning to that list other than that is the result of that function call. Lists and dictionaries can come and go as you need, or you can keep them around if you have a purpose where you need lists. How you use them and what they mean to your code are up to you.

I hope that helps a bit. If not, ask away.

thanks Jayne, that helps a lot, everything makes a lot of sense now, and sorry about the confusion with my use of "physical".

I was thinking of in reference to the "moving~changing" of an "object" (like "gold_coin") from one "object" to another "object", vs using the changing of attributes ("gold_amount"), for my use of "physical". As you put it well: the "virtual" perception of a physical movement within quest.

I totally forgot about the "parent" logical association (and thus couldn't realize it's presumably the same as the "list~dictionary" logical assoication), due to it mostly not being needed thanks to the underlying code engine (as it recognizes your ease-of-use of nesting it, both via the GUI~Editor and In-Code modes), laughs.

so, as you point out, technically you're changing an attribute (the "parent") when you "move" an "Object" ("such as a "gold_coin"), just as you're changing the attributes (such as with "gold_amount") of an "Object". This is all logical, actually, as there's no physical movment (technically, ALMOST EVERYTHING in terms of computing is logical, unless you're actually talking about the hardware and the AC-DC electrical current and its moving of the bits of data at the OSI model's layer 1, whereas and because the other 6 layers of the OSI's 7 layers are logical. OSI (Data Link) Layer 2 's use of a MAC address and up is ALL logical attribute coding!

good Cisco networking info~pic of the "OSI", "DoD ~ TCP/IP", and "Cisco's 3 layers heirarcial" 3 models all together:

http://www.texbuddy.com/Images/Snap_Shot_OSI.jpg

or just between "OSI" and "DoD ~ TCP/IP" models (not as good as the above link, lol):

http://www.sis.pitt.edu/~icucart/networ ... Model.html

----------

could we say that the "parent~nesting" and "lists~dictionaries" are both forms of containment, the quest engine recognizes their "virtual location existances and virtual movement", and thus they can be acted upon at that "location" (association of~with another Object), with the only difference being that the "object" can have only one "parent" association ("virtual location existence"), but many "list~dictionary" associations ???

And thus if the above is true, then using "MoveObject or <parent>blah</parent>" Scripts~Tags, "Remove~Destroy Object" Objects, or "list~dictionary add~remove" are all ways of "virtually moving~changing" the logical "object" attribute, correct ???

ie, everything that can be done to~with~at (acted upon) an "object" via a "parent" association~containment, can be done with an "object" via a "list~dictionary" association~containment, correct?

I'm basically trying to ask this (lol ~ I think I'm just confusing you more, and making myself look like I understand less and less):

an "object" logically-exists (and thus can be acted upon) at both its "parent" and "list~dictionary" associations (the other "object" that it is pointing towards or at) ???

----------

Also, one other question for more conceptual understanding for me:

would this cause a problem~conflict~error?

<object name="blah_1">
-> <inherit name="editor_object" />
-> <object name="blah_2"> // either via a "parent" attribute on the "blah_2" object or the underlying code engine recognizing this code nesting
->-> <inherit name="editor_object" />
-> <object>
-> <blah_object_list type="simpleobjectlist">blah_2</blah_object_list>
</object>

or can the "blah_2" object exist at "blah_1" object via these two logical associations of "parent~nesting" and "lists~dictionaries" ???

Also, are they independant of each other ??? what happens if one action is done to one (the "parent~nesting") of them, but a different action is done to the other of them (the "list~dictionary") ???

What happens if I do a "list~dictionary remove", does "blah_2" object still exist-logically at "blah_1" object via the "parent~nesting" ??? what if I were to "move~change to the parent~nesting", does "blah_2" object still exist-logically at "blah_1" object via the "list~dictionary" ??? What if I were to "destroy~remove" the "blah_2" object, does it still exist-logically at "blah_1" object via the "list~dictionary" and~or the "parent~nesting" ???

----------------

Out of coding~logic curiosity, could an "object" (and if the underlying code engine was ~ and ie can be ~ coded for) have multiple "parent" (upward) associations too, or is this somehow impossible in the coding~logic "world", whereas it's not for the "lists~dictionaries" (downward) associations ???

---------------

jayna wrote:As such, an object can exist in multiple such lists or dictionaries at once. More importantly, Quest does not place any special meaning on such containment; there is no "physical" or virtual meaning to being in such a container, apart from what you assign to it yourself.

I'm assuming (guessing) that this is what you mean (I'm hoping!):

the underlying code engine acts upon (ie is coded for acting upon or for understanding) the "parent~nesting" of "objects", but you got to craft your own code for specifically acting upon the "lists~dictionaries" (obviously for doing what you want with them), is this the correct understanding of your quote~comment ???

I think that's the important part of all of that. Apart from the one/many, upward/downward pointing nature of the two schemes, the crucial difference is that Quest has a lot of logic built around the parent/child relationship, in terms of what it means in the game world. But lists and dictionaries have no inherent meaning. If you create an arbitrary list or dictionary and put an object in it, it has no "meaning" in the Quest world as such.

Maybe this makes sense: the room I'm sitting in right now has all sorts of things in it - a table, a chair, a TV some bookcases, a Christmas tree. That is the "physical" sense of those things; their being in this room is part of my "world". That's what Quest uses the parent/child relationship to represent. Now, if I take a pad of paper and pen and make a list of those objects, writing each one down on the list, nothing in the "world" changes (other than that the list now has entries), but I have a list I can look at and use for my own purposes. The fact that I have written "chair" on my list does not change anything about the chair or where it is. It's just put in a list for my own use, so I can track it for some purpose. (Maybe I'm taking an inventory or want to remember what I have for insurance purposes after I set the house on fire.)

And I can have as many different lists as I want. It doesn't change things in the "world" as such. (The analogy breaks down a little bit there, as in the real world, a pad of paper is itself an object, whereas in Quest an internal list is not. Try to look past that a bit. )

Thanks, that makes a lot of sense! The "object" (as an Object) is indeed the Object and thus its "parent~nesting" too (as the quest engine understands it), whereas a "Value" (even an "Object" as that Value) in an Object List~Dictionary Attribute, is just that, a Value of an Attribute... of an Object. You can use Object Lists~dictionaries to act upon the "Objects" within them, but the "physical" (for the quest code engine's "world") Object itself, exists as a tag (<object name="blah"></object>) and through its "parent or "nesting", for its "physical" (again as understood by quest engine) location. Though in terms of "containment", there's no difference between the "parent~nesting" Attributes and the "lists~dictionaries" Attributes (aside from one vs many, and "upwards-parents" vs "downwards-childs").

An "object" within a list~dictionary is just a "representation" (a mark or symbol) of the "actual~physical" (virtual) "Object", in terms of how the quest engine is coded to understand. Writing "pig" on a contract is just a "representation", it's obviously not an actual pig, just as an "object" within a list~dictionary isn't the quest-engine-understood "physical" Object, either. The "real pig" of the quest engine, is the "creation-tag" of <object="name"></object> (or a script that creates it) and it's "location" via a "parent" attribute or the "nesting" made possible by the quest engine's underlying coding to understand it as such.

I think I understand these concepts very well and a lot more of the coding design~logic~concepts too, understanding greatly more about "objects", "parents~nesting", "lists~dictionaries~childs", attributes, and etc, thanks to your superb explanations!

sorry, for the work of getting me to understand, I am~was so dense~slow in understanding that: an Object is an Object, and a list (or dictionary) is a list (or dictionary), lol. Sighs... but at least now I do understand, heh.