[General] unit leave range event : |

[Nestharus]

so, I've tried to solve a way to do this and all of my solutions have thus far sucked. My latest one couldn't even handle 80 units...

So, does anyone have any genius ideas? : )

My last solution created a grid of rects across the map.
x dimension / 128 rects
y dimension / 256 rects

it added these rects to two alternating regions (alternated as x (column) changed).

So essentially, this could determine when a unit moved a certain distance. It's accuracy was kind of meh (1 to rt(128^2*2)), but it has much less overhead than a timer =).


So yea, that's the grid thing. This meant that as a unit moved from one 128x128 tile to another, it'd do it's thing =). Useful for ranged auras that have stats depending on the range I guess =P.


The real problem in my Morale system with this lies in the iteration. If there are 100 units all moving at the same time, it requires 9900 iterations (100*99).

Every single unit gets a unit group, and all other units are added to that unit group. For example, if there were 100 units, then each unit group would have 99 units and there would be 100 unit groups. This means that the maximium iterations would be 100*99, and unit groups are slow to iterate through to begin with (but forced to use them).


So, does anyone know of any better ways, or it this just impossible to do in WC3? >.>

 

[Weep]

so, I've tried to solve a way to do this and all of my solutions have thus far sucked. My latest one couldn't even handle 80 units...

80 units with one exits range event? How is it even possible to have that inefficient a system?

Oh, I see later that it's not just one event.

Well, it seems that WC3 internally does (pseudocode) checking every ~0.1s, for each center, enum units in range; if it wasn't present when last checked, run event. So, just do the opposite?

Useful for ranged auras that have stats depending on the range I guess =P.

The real problem in my Morale system with this lies in the iteration. If there are 100 units all moving at the same time, it requires 9900 iterations (100*99).

Ah, so it's less about "unit leaves range" and more about "how many other units are in range of every unit".

As you were doing, you could divide up the map but make a heatmap of sorts based on how many units are in each checkerboard square, and sum up the appropriate squares (which has room for optimization). Also, it strikes me that instead of n² rects, you could weave 2n rects, half the full width and half the full height of the playable map area, each set just to track horizontal or vertical motion.

 

[Nestharus]

Well, the problem is that each unit gives off a different amount... so I have to actually look up the amounts on each unit.. and it's not within a range of a source, it's within a range of that unit that gives off the amount... I have to apply that amount to every unit in a range.

edit
Not sure what you mean by the 2n

My current thing looks like this

     *     *     *     *     *
  *     *     *     *     *
     *     *     *     *     *
  *     *     *     *     *

Oh, so it's really 63001 handles I have in my thing, hahaha... I calculated wrong ^^

 

[Weep]

Not sure what you mean by the 2n

My current thing looks like this

     *     *     *     *     *
  *     *     *     *     *
     *     *     *     *     *
  *     *     *     *     *

I mean two sets of alternating rects like this:

 __________ 
|__________|
 __________ 
|__________|
 __________ 
|__________|

and like this:

 __    __    __
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |
|__|  |__|  |__|

because that's all you need to determine horizontal and vertical motion.

Then, use a 2d array or hashtable (3d for multiple players) with each cell having the sum of the morale contributed from the units within, then either using that to compute the morale received by each unit, or blurring its values to neighboring cells and then just doing a single read for each unit.

 

[Nestharus]

That gives the same result of what I'm doing right now ;(, oh but yours has less rects =D


Also, a ForGroup is about the only way to do this. Overall, the iterations are going to be the same :\.

edit
When I think about the way you laid out rects, it's actually worse since you fire 2 events rather than 1 in the center.

---> -|-