Coordinate Change Event

[DoomSprout]

When the event for a coord change comes in, it seems to carry three separate tables mapping units to the new value, one each for x, y and z. This confused me for a bit, as I was expecting a single table along the lines of:

{ unitId -> {x,y,z} , ... }

But instead it's:

{ unitId -> x , ... } { unitId -> y , ... } { unitId -> z , ... }

... if that makes sense

Anyway, my question is, would there ever be a case where a unit ID could exist in one of the tables, but not all three?

Thanks,

DS

[NerfedWar]

When the event for a coord change comes in, it seems to carry three separate tables mapping units to the new value, one each for x, y and z. This confused me for a bit, as I was expecting a single table along the lines of:

{ unitId -> {x,y,z} , ... }

But instead it's:

{ unitId -> x , ... } { unitId -> y , ... } { unitId -> z , ... }

... if that makes sense

Anyway, my question is, would there ever be a case where a unit ID could exist in one of the tables, but not all three?

Thanks,

DS

Hey Zorba, that's just too strange! lol

[Imhothar]

That representation is actually more GC friendly.
Instead of creating one tiny table per unit it's always exactly 3 tables.

[DoomSprout]

That representation is actually more GC friendly.
Instead of creating one tiny table per unit it's always exactly 3 tables.

Good point.

The layout doesn't really matter, it's easy enough to work with either. The only reason for the question is that I need to know which units are included in the coord change event. If I can rely on any one of these three tables being a definitive list of units, I don't have to mess around working out the union of the three.

Purely an efficiency thing.

[the_real_seebs]

You could probably do

y[unit] or 0

but it'd be cheaper if you didn't have to.