Anachron said:
Anachron said:
method kill takes nothing returns nothing as it just adds confusion to destroying projectiles. Now projectiles may simply be destroyed by the default destroy method.setTargetPos method that would reject the command unless the unit moved in all 3 dimensions (usually units only move in 2 dimensions). It should be fixed now, I always encourage people to report problems/bugs to me though so I can address them. This means that 2.0b is now completely stable; I don't think there are any other mindless problems.onFinish( ) method will be executed immediately after onStart( ), before the end of the create method. I don't know who would use a projectile system for an instant projectile, but now the functionality is all there.
setTargetPos is used this value is taken into consideration; this serves purposeful when setTargetPos is being called automatically internally such as when a target-vector is being updated to match the position of a tracked target (using activeTargetFollow).
FLAG__onFinish that would prevent a projectile from executing its onFinish callback response method, and I'm not really sure why I implemented it in the first place.FLAG__onFinish from the system) to launch your projectiles from their onFinish method. If you launch the projectile again it will keep the same properties however so I suggest keeping an eye on it so that nobody runs into any problems (when trying to use them in this way).
Indeed. You would be surprised how many use square root extensively in comparisons rather than storing the square of the other side of the comparison.
static method enumNearby takes projectilegroup g, real x, real y, real z, real radius returns nothing
local real x2
local real y2
local real z2
local vector v // To minimize repeated array lookups.
local integer i = DATA__size - 1
local projectile p
set radius = radius * radius // The math is performed only once.
loop
exitwhen i < 0 // Comparison to constant 0 is faster.
set p = DATA__stack[i]
set v = p.VECTOR__position
set x2 = v.x - x
set y2 = v.y - y
set z2 = v.z - z
if ((x2 * x2) + (y2 * y2) + (z2 * z2) <= radius) then
call g.add(p)
endif
set i = i - 1
endloop
endmethodradius*radius just use another local variable. I suppose that would speed things up slightly, when there are a substantial amount of projectiles. For only a few projectiles it would probably slow things down. I really don't have feelings either way.
globals
private TableArray projGroupTable
private TableArray projGroupTableRev
endglobals
private module GroupMod
private static TableArray table
private static Table tb
private static method onInit takes nothing returns nothing
set projGroupTable = TableArray[8191]
set projGroupTableRev = TableArray[8191]
set table = TableArray[8191]
set tb = Table.create()
endmethod
endmodule
create method gets shifted down to allocate so that you can define your own creation method.
stack array readonly) and a few other functionality updates.
onLoop method with static variables, performance actually decreased (so I left it as it was).onDestroy method so the user does not need to worry about this, but instead of using if (proj != 0) then the expression if not (proj.destroyed) then can be used. This makes things a little more explicit. The destroyed member is public.
indexOf[] no longer exists (though it did in any previous version) but if you want to update it all you have to do is replace projGroup.indexOf[ X ] with projGroup[ X ] - this shouldn't be too big of a problem.
GroupEnumUnitsInRange filter in performance. The primary reason I do not want to use a loop with FirstOfGroup is because the OP limit also needs to be considered. I've been able to run 500 projectiles with unit collision without a drop in FPS below 60.0. If I've got a couple of units being collided with by each projectile, this runs the operations into the thousands.
call UnitAddAbility(u, ID__flyHeightModifier)
call UnitRemoveAbility(u, ID__flyHeightModifier)if UnitAddAbility(u, 'Arav') then
call UnitRemoveAbility(u, 'Arav')
endifFirstOfGroup found? I've been told that GroupEnumUnitsInRange is faster than both, and I've been told that ForGroup is faster than GroupEnumUnitsInRange. Now I'm told that FirstOfGroup is the fastest. It seems like a bunch of nonsense to me. I'm curious, how many units is this being tested on? In the "benchmark" by Anitarf he claims it is 3x faster, rather than a little less than 2x faster - he is only testing it on 20 units though. Has anybody performed these tests on 50+ units?
