Having noticed that according to the lexicon, a variable of type object is just a single int, I sat down and thought about how this would work. Having thought about it for a while the most efficient solution I could come up with was this -
Given that the value held by a variable of type object is just a simple int, how does this work? The games engine holds a list of everything that you have placed into the game. In order to accommodate those things created and/or destroyed during the course of the game, this list is what is termed dynamic. That is it can expand and contract as the need arises. This list in turn points toward the actual data of these things and the int is an index into the list.
My question is quite simple really. Is the above true? Is that how the NwN EE game engine actually works or have I missed something or am I totally wrong?
In my words: A variable of the type “object” is just a unique pointer (identifier) to something elsewhere (i.e. a list of all Objects, probably structured). You can imagine for sure, that all the complex details of an object couldn’t be stored into an simple variable efficiently; to say nothing about different object-types.
What you can see in a saved game is that object instances in an area are identified by that id. Those objects may in turn possess lists of objects, such as inventories and stance towards other creatures, which use the same id. This can be verified using ObjectToString.
It’s a reasonable assumption that the engine probably has a master lookup table which makes finding objects by id quicker than searching all the data.
So, the object id is almost certainly a pointer.
However, does it really matter? Doesn’t “unique id” tell us everything we need to know?
It’s probably just the programmer in me but to me a pointer is a unique address that points to the location in memory where something is. That means that unless it is used as an offset an integer is just too small in a computer system with either a 32 bit or 64 bit address range. So to my mind to my mind it is more probable that it is a simple numeric index value into a single dimension array of pointers to the actual data somewhat akin to an Iliffe vector.
As I am trying to continue with my TR’s Basics tutorials I trying to explain about how a single data type can be as generic as the data type object, which encompasses so many different types of thing. So it would probably look better if I knew for certain rather than making educated guesses. Once I’ve got objects down pat I only have 3 other data types to cover - effect, talent and itemproperty.
What would be nice would be if an actual dev were to take a look but from the size of the latest dev patch, in terms of the number of fixes it contains, I’m guessing that people like @niv just don’t have the time to waste on what is probably a trivial question from their perspective.
Unlike ints, strings and floats - which are (immutable) primitives - objects are compounds. You can demonstrate that via an example “object struct”:
struct object
{
int id; // 1234 - index in master object table
int type; // OBJECT_TYPE_CREATURE
string tag; // "WHARRGARBL"
string name; // "Dog"
int area_id; // 333
vector position // <1.0, 2.0, 3.0>
float facing; // 321.456
// etc
};
Locations, effects, itemprops are also structs like that, but they have a constant layout (see note 1), while objects are “dynamic”. They are (probably) stored internally as key-val pairs in some sort of object class instances. Since the game always knows the object type and the commonly used script functions access properties shared by most of the objects (tags, names, locations, etc), it can expose them via single type to the user, who does not need to concerned with implementation details.
Like others have already written here, objects can be large and always represent a single entity in the game world, therefore to keep everything in sync, it makes most sense (also for performance reasons) to have a master int → object associative array (or a list with destroyed objects marked as such) and simply pass references to objects as integers.
Think of objects as JSON dumps. Keys and values, plus some lists. And that’s it - you have a generic container for any kind of object, with a streamlining GFF I/O. Creatures have effects, placeables inventories, items properties, areas sizes, etc. Some keys are saved in module, some are added/modified in runtime.
Thanks guys. As I hadn’t done anything with JavaScript in a very long time I had to look up what json actually is, so for others like me here is what appears to be a very good explanation.
Yeah, those are great. I use those ruby tools all the time still since the new tools don’t support yaml and all my version controlled gff files are in yaml
