ResManager problem?

#1 The "client number" you're referring to is your object ID. It's for the best that it not be reassigned, as that way you won't have issues where bits of the code get a reference to the old object, that object is destroyed, replaced, and then the old reference is valid again.

If you want sequential, re-assigned client IDs, I suggest using the client's order in the ClientGroup.

#2 Ben,

I need to be able to count on those numbers. I used the client as a quick example, but it affects all objects as near as I can tell. I would really like to be able to return all object ID's to the pool when each object is removed.

#3 Gonzo,

Out of curiosity, why do you need the numbers to be recycled? Initially this is how Torque worked (back when it was the Tribes 2 engine), but it made scripting errors much more difficult to catch since an old object ID would refer to a totally different object if the original was deleted and the ID recycled. Right now you have up to 2^32 object allocations before you run out of IDs, which should last you between server restarts.

#4 In T1 and T2 there were certain functions that were used to check blocks of ID's for certain objects, and their states or their existance. By knowing what ranges that objects always fell in, you could easily script a loop to run a fast check and perform the needed actions. If I know for a fact that I cant count on any such control, then I fear I'll completely lose the ability to code such functions.


For instance, if I were to check the first 1500 objects every time under the old method, then I could be assured that I had a run a check on all map objects no matter who made the map. This was especially useful on objects that had no name to call them by. The way torque runs now, the function would be useless after the first map or two.

I never had any problems using recycled ID's before.

#5 Recycled IDs are one of those "silent killers". Its quite possible for a script to end up using a different object than they thought they were because of recycled IDs, hence the reason most systems try to avoid them. Even with checks out the wazoo it still happens, and then some poor fool spends days or weeks pulling his hair out wonder why he's seeing such odd behaviour.

The high level API that i'm writing for one of our game engines originally used a similiar recycled ID system until it was pointed out, quite correctly, by one of our programmers how bad things could get confused.

#6 Gonzo - you're welcome to recycle your IDs.

Why not just use the SimGroups provided for the purpose of iterating over, say, all mission objects?

#7 "Gonzo - you're welcome to recycle your IDs."

Obviously. But getting help on it apparantly is not something I'm welcome to. Strange when you consider the amount of help I put back into the community.

#8 Im sure if they knew, they would help you out. All they're saying is that you can do exactly what you want with SimGroups, and it wont require any engine changes and would be much less prone to errors.

And no, I dont know how to help you, I just thought you were being a bit unfair to them.

#9 My apologies. I did assume that they knew the answer. My bad.

#10 Recycling IDs would be a moderately challenging task. You'd need to maintain a stack of all freed IDs so you could reuse them on new object allocations. And you'd run into a lot of problems, like we said. But hey, if you wanna do it, SimObject::onAdd and SimObject::onRemove are your guys.

#11 What's bothering me is the exploitability of it. Without saying how, I know it is possible to use the torque engine to crash any torque server you can see that uses a player ban system in a matter of minutes. And even if they dont use a ban system, it can still be done with a slightly different script.


Meaning if you make a game with torque and dont "radically" alter it, then you are open to any and all of your servers being crashed by the first script junkie you piss off.

Sorry to be the bearer of bad news, but it is what it is.

#12 If you send us the exploit, we'll fix it, or at least try to. :)

All networked systems have holes in them; the only proven way to mitigate the problem is to fix exploits as they are discovered (and to practice good software engineering principles).

Overall, Torque's networking system is solid - it does things like crash, instead of allowing buffer overflows and the like. There are probably buffer overflow-allowing weaknesses, but they're in per-object net code, meaning that unless someone has the source to your game and its objects, you're pretty safe. Eventually, it may be wise to make the server deal with bad connections robustly; so far it hasn't been a big enough issue as to be important.