• Welcome to Valhalla Legends Archive.
 

Warcraft 3 Object IDs

Started by Strilanc, September 01, 2009, 10:51 AM

Previous topic - Next topic

Strilanc

When communicating in multiplayer, or saving to a replay, the objects (units, destructibles, items, etc) in a wc3 game are referred to by an id number. Duh. It seems to be allocated and freed, pretty simple. You can see it in any of the order or selection actions.

The mystery is that the id is always followed by a second value, which I'll just call id2 (since it seems to be unique per object). All objects created at game init have id = id2. id2 seems to increase with time and with the number of ids. Late in the game a typical id2 for new units is in the hundred thousands whereas the id stays relatively stable due to units dying and such. id2 also seems to increase as more ids are allocated. But, most confusing of all, it doesn't strictly increase. It goes up and down over the short term.

So, the question is: what is this value? What information is the primary id not specifying that this weird secondary one specifies? Why does it increase over the long term? Is it just there to screw with my mind?
Don't pay attention to this signature, it's contradictory.

MyndFyre

In what conditions does it decrease?  For instance, if I respawn a hero, does it really decrease, or are we seeing the recycling of a unit ID?
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Strilanc

I created a test map which created 5 peasants, waited 5 seconds, removed the peasants, waited 5 seconds, repeat.

I selected the peasants to get their IDs from the selection action data, and noted how the IDs change.

The primary id stayed between 900 and 1000, even after I let the map run for 20 minutes or so. The secondary id started less than 10 away from the primary id, but after 20 minutes it was in the tens of thousands. But during each create-5-peasants cycle it was not strictly increasing.

...

unless

...

Maybe it *was* strictly increasing, but it simply ordered the peasants by primary id and so it only looked like it was decreasing.

...

I need to test something.
Don't pay attention to this signature, it's contradictory.

Strilanc

Alright, now it looks like id2 is a strictly increasing index while id1 is an allocated index. Any ideas why they would use both?
Don't pay attention to this signature, it's contradictory.

MyndFyre

Quote from: Strilanc on September 01, 2009, 03:08 PM
Alright, now it looks like id2 is a strictly increasing index while id1 is an allocated index. Any ideas why they would use both?

id1 could be something related to the unit ID relative to the player, or the unit prototype ID (e.g. "human peasant")?
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Strilanc

No, the ids are unique to each instance of an object. Also, the type would presumably be part of the information the primary id points to.
Don't pay attention to this signature, it's contradictory.

Strilanc

My current theory:
- The allocated id is for fast-access (eg. array storage). The counter id would require a tree or other non-constant-time structure.
- The counter id is for uniqueness. The allocated id could be reassigned between the time a player issues an order and the host receives the order.
Don't pay attention to this signature, it's contradictory.