Closed fredi-68 closed 5 years ago
I've added a system that takes old object IDs, strips them of the highest 32 bits and adds them to a pool which will be prioritized if new IDs are needed. However, we are currently not calling this method for all object IDs that could be recycled. This is particularly true for item drops, since they can remain in memory forever unless picked up by a player right now. However, I've done the maths and unless I am very much mistaken on how the object IDs work, we have around 4.3 billion available IDs, which would most likely last long enough until the instance would be rebooted anyways. However, I want to be as efficient as possible with this, just in case.
Oh yeah, if we do threaded stuff at some point we may need to lock that pool to ensure no two objects with the same ID are ever created, because that would be a total disaster. Whether or not this is necessary depends on how I'll end up implementing the physics engine
Well, that doesn't work. It turns out that the client actually assumes that object IDs are unique across the entire session. Which means unless we are switching zones we cannot use the same object ID twice for different objects even though they never exist at the same time. I guess we just have to hope that we never hit that 4 billion mark
The way the zone object handles object IDs is currently not ideal. IDs of deleted object don't get reused and the counter doesn't wrap around, so eventually we would end up running out of IDs. There are multiple solutions to this issues: Pooling IDs of destructed objects so they can be reused, keeping track of used IDs (as we are already doing) and select one that isn't, reserving certain ID ranges for certain object types and pooling those, etc...