TriggerRegisterUnitInrange vs TriggerRegisterEnterRegion

[Sgqvur]

Which function do you think/know is better (fires faster), [ljass]TriggerRegisterUnitInRange[/ljass] or [ljass]TriggerRegisterEnterRegion[/ljass] in the case of a projectile movement (with high speeds [2000+ for example]).
Of course [ljass]TriggerRegisterEnterRegion[/ljass] with some distance calculations to make sure the entering unit is in the radius of the
circle that fits in the rect. I've done some tests and it seams that [ljass]TriggerRegisterEnterRegion[/ljass] (and of course moving the rect and using RegionClear/AddRect)
is probably better yes? In the Projectile system by Kenny he seams to use them both. The first is easier to use I guess as well.

 

[Dirac]

Since both are events that should only fire once, i would use both, however.

TriggerRegisterUnitInRange is more accurate, but requires more mathematical calculations, for projectile detection, i would use this. (given the case that calculating distance through projectile movement iteration slows the process down, which is actually a question i would ask myself: what's faster? using [ljass]SquareRoot(distance^2)[/ljass] every iteration or creating a trigger for these kinds of events and wait for them to finish)

 

[Sevion]

Speed-wise, I don't think either has a difference, but I don't know the C++ code behind each one.

Personally, I would implement a sort of projected collision line, but that would lag terribly in vJASS.

 

[Bribe]

Group enumerating works out better as it won't just fire once, won't require dynamic triggers (less RAM needs to be allocated), and is not too slow if you don't do it EVERY iteration.

TriggerRegisterUnitInRange, for example, only works every 0.10 seconds. You could do something similar with the group enums.

Does anyone know if Locust units even trigger that event?

 

[Dirac]

Ive tested detecting units that enter the range within an unit with locust, not the other way around

 

[Sgqvur]

Bribe:
1. Does anyone know if Locust units even trigger that event?
2. Group enumerating works out better as it won't just fire once, won't require dynamic triggers (less RAM needs to be allocated), and is not too slow if you don't do it EVERY iteration.
3. TriggerRegisterUnitInRange, for example, only works every 0.10 seconds.

1. Haha good one. It seams that [ljass]TriggerRegisterUnitInRange[/ljass] does not work with units that has locust (units that have locust
and enter in range of a unit that have or doesn't have locust, like projectiles and dummies)
so this explains why Kenny uses the rect method for projectile to projectile collision and the first for projectile to unit collision.

2. Well I think for collision you need it to fire just once and decide what to do, about the ram yeah sure, usually you would move projectiles every 1 / 32 of
second so instead of EVERY iteration mayme 1 / 16 you suggest? (But even that is a bit too much calling a function 16 times a second for every projectile)
3. How did you (or some else) timed that? This is equal to TriggerSleepAction(0) I guess which is of course inaccurate sometimes it's 0.1 then 0.175, 0.2 so it's not very reliable.


Dirac:
1. TriggerRegisterUnitInRange is more accurate, but requires more mathematical calculations, for projectile detection, i would use this
2. what's faster? using SquareRoot(distance^2) every iteration or creating a trigger for these kinds of events and wait for them to finish

1. It actually requires less mathematical calculations because you have a circle, but with the TriggerRegisterEnterRegion you have a rect
and if you need circle collision then you need to check the if the distance between the projectile (entering unit) is less then the radius of a
circle that fits inside the rect.

2. I think that jass math (iterating every projectile and calcualting it's distance to every other projectile and unit on the map) is
surly much slower than the trigger enter region and trigger in range methods.


So why does Kenny uses both methods ([ljass]TriggerRegisterUnitInRange[/ljass] for projectile to unit collision) and
[ljass]TriggerRegisterEnterRegion[/ljass] for projectile to projectile collision instead of just using the [ljass]TriggerRegisterEnterRegion[/ljass]
and check some flag to make the difference between a unit and a projectile and then fire the projectile2projectilecollision and the projectle2unitcollision functions accordingly. And also the [ljass]TriggerRegisterUnitInRange[/ljass] requires a group to make sure not to collide more then once with the same
unit. (on collision the entering unit is first check if it's in a group and is only added if it's not [and the collision function fires]). I don't think the [ljass]TriggerRegisterEnterRegion[/ljass] requires this extra work and ram right?.


Edit: scratch the above ("And also the [ljass]TriggerRegisterUnitInRange[/ljass] requires a group to make sure not to collide more then once with the same unit.") actually it doesn't but the GroupEnum* functions do. But I still think the [ljass]TriggerRegisterEnterRegion[/ljass] is better because it's
faster (faster detection) even if it requires more calcualations and some RegionAdd/RemoveRect and [ljass]SetRect[/ljass] (move rect).

 

[Bribe]

GroupEnum is feasable, and if you don't like evaluations because of the efficiency loss you can always take advantage of FirstOfGroup loops,

Which brings the thought of who came up with the idea that FirstOfGroup loop is slower than enumerating? I doubt it, because evaluating threads is a really heavy process.

I will try to do some FPS tests later to see which lags my computer faster - I have a feeling FirstOfGroup loops will see a comeback with situations where you only need to enumerate once.

 

[Sgqvur]

Bribe:
1. I doubt it, because evaluating threads is a really heavy process.
2. GroupEnum is feasable, and if you don't like evaluations because of the efficiency loss you can always take advantage of FirstOfGroup loops

1. I am really confused of the usage of the word 'thread' in the context of Jass.
Statements like "thread crash", "[ljass]ExecuteFunc[/ljass] starts it's own thread", "exceeding the oplimit crashes the thread", etc. ["evaluating threads" =)].
Now what exactly does thread is supposed to mean? I think the jass "virtual machine" (the thing that runs the jass "byte code")
runs in a single thread (os thread, that's why you don't have problems with concurrency [locks, mutexes] and a like) so a wc3 thread (which [ljass]ExecuteFunc[/ljass] and friends supposedly start) are not really threads (I have no idea how they are simulated/implemented), so I think it's an illusion that Jass related stuff executes in parallel in wc3 it's more like in every tick (1 / 32.0 for example) each timer's elapsed time is incremented and the rest of the things that happen ... ). So what should be the definition of a 'thread' in the context of wc3?

2. By evaluations you mean [ljass]ForGroup[/ljass]? But you still require a second group to check if the unit has already been damaged/collided by/with the projectile. So this means 1 extra group per projectile and 1 global group for either [ljass]FirstOfGroup[/ljass] or [ljass]ForGroup[/ljass].

 

[Dirac]

1. It actually requires less mathematical calculations because you have a circle, but with the TriggerRegisterEnterRegion you have a rect
and if you need circle collision then you need to check the if the distance between the projectile (entering unit) is less then the radius of a
circle that fits inside the rect.

Do you even know how do circles work? In order calculate the distance between 2 points you must do the following [ljass]SquareRoot((PointAx-PointBx)^2+(PointAy-PointBy)^2)[/ljass] and then pass it through a conditional to check if the returned value is less than the radius. "Rects" are just squares, to check if an unit is inside the square do [ljass]((PointX-RectXsize/2)>RectXstart) or (PointX+RectXsize/2)<RectXend)) and ((PointY-RectYsize/2)>RectYstart) or (PointY+RectYsize/2)>RectYend))[/ljass] so circles are more complex.

And from which statement you draw the conclussion that performing math in JASS is slower than those triggers? Pherhaps is as fast since those also have to calculate the distance between point A and B to determine if the distance is less than the radius

 

[Sgqvur]

Dirac:
1. Do you even know how do circles work? In order calculate the distance between 2 points you must do the following SquareRoot((PointAx-PointBx)^2+(PointAy-PointBy)^2) and then pass it through a conditional to check if the returned value is less than the radius.
2. And from which statement you draw the conclussion that performing math in JASS is slower than those triggers? Pherhaps is as fast since those also have to calculate the distance between point A and B to determine if the distance is less than the radius

1. I think I do and you also don't need the SquareRoot:

This is in a TriggerRegisterEnterRegion callback (or filter) function
dx = x1 - x0
dy = y1 - y0
// this is for ground checking no Z
if dx * dx + dy * dy <= radius * radius then
// run collision code

This is what I meant.

2. The difference is that the calculations happen when they need to (when the trigger fires) not every 1/ 32.0 of a second

 

[Dirac]

The difference is that the calculations happen when they need to (when the trigger fires) not every 1/ 32.0 of a second

It works the other way around, calculations are made periodically in order to the trigger to fire.

Also, about the math you performed there, ITS THE SAME THING! (performing square root here or checking for square radius) Please don't answer things when you don't know the answer...

 

[Sgqvur]

Dirac:
1. Also, about the math you performed there, ITS THE SAME THING! (performing square root here or checking for square radius) Please don't answer things when you don't know the answer...
2. It works the other way around, calculations are made periodically in order to the trigger to fire.


1. I will quote my self "and you also don't need the SquareRoot", of course it's the same thing but the [ljass]SquareRoot[/ljass]ing is slower compared to multiplication, that was my point with "and you also don't need the SquareRoot".
2. Ugh... if calculations "are made periodically in order to the trigger to fire" this is much more expensive (because jass math is rather slow)
compared to waiting the trigger the fire and then do a little math.