Object IDs don't reset after disconnecting?

#21 The issue with object ids is that beyond datablocks everything is essentially lumped into the same space.

This doesn't appear to be much of a problem however since the code never really seems to check for an overflow and I haven't heard of a Torque game suffering because it ran out of object ids either (yet). The only bad thing which can happen is you could get an increasing set of objects with the same ids every overflow. Still the last object will always take priority over the first one, and if you have something important (e.g. part of the gui or a mission prop) you can always refer to it by name instead.

Personally I would advise against re-using object ids where possible as you could easily end up with stupid cases where old references to objects point to new completely unrelated objects.

#22 James pretty much hit on the reasons for not reusing SimObject IDs. As all SimObjects use the same pool (with datablocks being an exception) and not just ghosts from a server, you would have to be careful about how you're rolling back your IDs. Anything that you create but want to have stick around between missions would have to be kept track of to ensure that you don't reuse their IDs.

But I believe the primary reason for not reusing IDs is to ensure you don't accidentally work with stale references (again as James pointed out). It is much better to have a SimObject not found error than to have a hidden, unintended object interaction. This is especially true if you allow your end users to mod your game.

- Dave

#23 I see, that's a logical reason for it to operate as it does. Back in the days of Starsiege Tribes, however, (Different engine, of course, but it still appears similar in concept to how T3D works.) the IDs would recycle once the mission was reloaded. I think that would probably be the best method to handle this.

If I understand correctly, Starsiege Tribes probably had different dictionaries for different categories of objects? GUI element IDs had their own for example, and in-game objects would just clear theirs upon reload?

#24 @James & @David: Just create a list of object types that can be recycled. IE: ProjectileType, VehicleType, Ect.

Then just simply compare the mask of the object being recycled to the list. You can easily avoid removing something important that way.

I'll do some research into this and see what I can come up with, maybe I'll get something working, maybe I won't.

#25 @Robert:
Oh sure, there are ways to change this. You could have lists of what types of objects should be recycled, and then have a pool of IDs that may be reused that you could draw on. And if that pool runs dry then continue with using new ID numbers. Or some other method. You may also want to add something to help with the concern over dangling incorrect references while developing or otherwise.

But you may want to consider what issue it is you're trying to solve with this work.

- Dave

#26 In the rare case that the IDs do overflow it will cause the engine to malfunction. The first event will be that objects with negative numbers cannot be found (something sees the number as S32 during this failure). The next event will be when the number overflows to 0. If the previous event did not screw up the server/game then this will overwrite objects that have protected ID numbers. No matter how you look at it, letting it overflow on its own will have problems. I think at least being smarter about the overflow would be a good idea.

If you store an ID and are not mindful of the life cycle of the object then that is bad programming. It is akin to storing a C++ pointer, deleting the object, and then using the pointer. It may not crash when it is done is TS, but it is still not a good idea. Even in C++ it could point to a new object, but you still don't want to use the old pointer.

I like dBs idea for hole tracking. It allows the reuse of IDs in a sensible and efficient way.

#27 @Demolishun:
Yes, I agree that the possibility of an overflow is not great. And I also agree that not properly handling an object's life cycle and all references to it in your own script is equally not great.

If someone wants to tackle these issues in an across the board, generic manner, have at it!

It's just... I can't help but feel that if you have time to tackle that, then we could certainly use your help on resolving the issues list on GitHub.

- Dave

#28

Quote:But you may want to consider what issue it is you're trying to solve with this work.

This is right on the money. I don't like the potential for the overflow because I like things to be neat, but here are some likely scenarios:

1. For a dedicated server that runs a long time it would a very long time to actually get to the 2^31 mark. Lets say a typical mission created 10,000 new objects so it would create 10,000 new IDs during the mission. Lets say the mission is 30 minutes. That would be 214,748 missions. That would take 6,442,440 minutes if the missions were run back to back with no breaks. That would be 107,374 hours or 4,474 days or 12.25 years. If the server is not rebooted in that time you will have problems.
2. Most games will start and end within 1 to 10 missions. So those are not an issue.

Considering the long term dedicated server was my biggest issue I don't see this being a problem at all. So I don't think this needs a fix. Maybe in ten years when we are spawning 1 million objects per level or something.

#29 I agree, my inner OCD tells me to do something about it but ultimately it's not likely to be an issue at all. Should it ever become an issue, however, now I have a much clearer idea on how I could deal with it.

#30 Interestingly, there's already a class that seems to do just what we're discussing. I assume it's unused.

Also: GitHub issue, just so we have the link handy.