Often associative maps have the semantic idiosyncrasy where accessing a key that does not exist creates a new entry in the map, with that key and a default-constructed value.
This is so that, for example, in C++, you can write "m[a] = b" to insert the entry (a, b) into the map m. This is also why I've heard the [] syntax be discouraged, in favor of .at(), if this sort of default-construction is not desired. Apparently the engine writers used [] somewhere to get an object by key and either purposefully or inadvertently triggered the default-construction when the key was not there. If they had used .at() instead there would've been an exception generated. If exceptions were not what they wanted they could have used .find() with a dereference, which would've probably generated a segfault instead, but would've probably been less confusing than creating a completely new object somewhere else and continuing on.
Or, at least, I'm guessing, since this situation seems like an example of what I've described above.
What I think is more likely here is that the parent object simply doesn't exist. The objects would be stored in a flat table, since for a game engine you generally want to keep your data-structures as simple as possible, so you don't want to hard-code any hierarchies. You wouldn't use a map data structure here (at least, from parent to child) since one parent may have multiple children. Each child is also referenced by ID, so you have to have a master table of objects with IDs anyway, so adding a multi-map would be unnecessary overhead too.
So what you want is a bunch of records with ID as the key, and the payload as the value. The payload would include a field "ParentID". So the
child's ID is being created, it's just being created with a ParentID that's not in the database at all. There's no need to speculate that it's created a phantom node at that point.
Now, consider what happens whenever a new child object is spawned. You make a new object which gets a new ID and you specify which ParentID you want. However, should the game engine validate what you created?
Every time you spawn a new node? What if there are 1 million nodes and you're creating another 1000 nodes? The best-case scenario is that it does a heap-search of all million nodes, at least twice. First, to check that you gave it a valid ParentID and that you gave it a unique new object ID. That would be significant overhead on spawning objects. The game engine would be much faster if it just assumes the IDs that the code is giving it were correct to start with. So, yeah, it's not doing a full search of all nodes every time you make something, on purpose, for efficiency. If every time the engine runs some code it's doing extensive error checking to prevent mod makers from hurting themselves the game would run like dogshit.
Author
Topic: Things that made you go "WTF?" today o_O (Read 14549212 times)