Object ID bitflags

[fredi-68]

It looks like object IDs may have some additional flags, a lot of which we don't know the use for.

So far this is what (we think) we know:

• first 32 bits are used to store object unique ID
• 1 << 38 to 1 << 43 are used to store the scene ID an object belongs to.
• 1 << 44 and 1 << 45 might be used to store scene ID as well, although this is unconfirmed
• 1 << 46 We currently call this the "spawner" or "server" flag. Set for all object that are managed by the server and occured in traffic logs, except for players, items and some special objects(?)
• 1 << 58 "generic object" Set for all objects on the server? I don't really get this one.
• 1 << 60 Used for player and item IDs

[fredi-68]

Testing different loading configurations in the level/scene parser has lead me to believe that the "spawner" flag is actually a flag that signals the client that an object is managed by the server. So it is more of a "server" flag. This explains why it has to be set for all objects that are created on the server EXCEPT for the ones that are defined in the scene files. Turns out we can skip loading them altogether since the client does not care about them. This was probably the main cause of lag/graphical glitches.

[fredi-68]

Found something else: Apparently, for objects not created by spawners, the object ID is (LUZObjectID | LWOOBJID_SPAWNER), being (objID | 1 << 46). I got that number from the LU Mailbox object but I expect it holds true for all other objects. This is interesting as these are objects we aren't currently loading but still need to be able to communicate with the client (like the mailbox, which needs to be able to receive interaction requests). That means our current strategy of not loading non-spawner objects at all doesn't work (which was more of a workaround than a permanent solution anyways)

[fredi-68]

Once again, the 1 << 46 flag seems to make the difference between the object stored on the client and the one stored on the server. In network traffic, this is the only ID that occurs, the one from the LUZ file doesn't appear at all

[fredi-68]

On further inspection the roles of LWOOBJ_GENERIC_OBJECT and LWOOBJ_SPAWNER may be reversed, i.e. LWOOBJ_SERVER and LWOOBJ_NETWORKED? In this case, 1 << 58 would signal that an object is tracked by the server (not part of the LUZ) and 1 << 46 would imply that an object is networked (tracked by either client or server or both, but known to exist by both).

[fredi-68]

I've changed the server to use a class to store object IDs instead of plain integers now. This makes dealing with bitflags and offsets a lot easier since one doesn't have to worry about separating them anymore because they are accessible through different properties on the same object. While implementing this I discovered, that the 32nd bit doesn't have to be set for the player flag, so I removed that from the specification

[fredi-68]

If research doesn't reveal any more information about the bitflags used in object IDs, I may just end up defining my own categories alongside the already existing ones; for example a category for items so that we can have globally unique player IDs as well as per instance item object IDs.

[fredi-68]

Bits 38 - 43 are used to store the scene ID for object IDs located in the level files. Since these are only relevant for spawners it seems that these were used by the client to speed up object spawner config lookups by indexing the scene and then searching as opposed to searching all scenes in the level. It is actually very likely that the object IDs used bits 38 - 45 (which would be one uint) to store the ID, but since I haven't found a level so far that has more than 55 scenes I have been unable to confirm this theory. Should I be right, the flag indices would line up perfectly with the spawner flag, which has flag ID 46