Doing a very quick scan of the code
-
Set LS_OrbAngle[LS_TempIndex] = (Angle from LS_TempPoint2 to LS_TempPoint)
-
Set LS_TempPoint3 = (LS_TempPoint2 offset by LS_TriggerExplosion[LS_AbilityIndex[LS_TempIndex]] towards LS_OrbAngle[LS_TempIndex] degrees)
-
Set LS_XOfPoint = (X of LS_TempPoint3)
-
Set LS_YOfPoint = (Y of LS_TempPoint3)
-
Custom script: call SetUnitX(udg_LS_Orb[udg_LS_TempIndex], udg_LS_XOfPoint)
-
Custom script: call SetUnitY(udg_LS_Orb[udg_LS_TempIndex], udg_LS_YOfPoint)
There's a lot of redundancy here - there's no need to use points at all particularly for what you are doing (since you convert it all to co-ordinates anyway)
call SetUnitX(u, x + dist * Cos(angle))
call SetUnitY(u, y + dist * Sin(angle))
moves a unit from (x, y) to its new location by dist toward angle where angle is in radians
(which can be done via
set angle = Atan2(y2- y, x2 - x) where y2 and x2 are the target point and x, y are the current point)
this cuts down the lines of code from 6 to 3 and you done need to remove the location because you don't make one and fewer variables are used overall
(Using GetUnitX() and GetUnitY() functions can make this easier as well though if you use them twice on the same unit it's recommended to store it in a variable (udg_LS_X/YOfPoint in your case)
-
Set LS_DistanceTravelled[LS_TempIndex] = 0.00
This is done regardless of the boolean value
Since this uses 0.03 in a lot of places (the timer speed) it'd make sense to put it as a configurable and substitute the variable into all the appropriate places (if somebody changes it to run every 0.04 seconds for instance it will not work as intended)
-
Animation - Change LS_Orb[LS_MaxIndex]'s size to (175.00%, 175.00%, 175.00%) of its original size
This would do the same thing as
-
Animation - Change LS_Orb[LS_MaxIndex]'s size to (175.00%, 0%, 0%) of its original size
(May save you some processing later such as fetching LS_Size[LS_TempIndex] 3 times in one function call, also why is the starting size not configurable?
Could argue that there should be some z offset to the lightning - it looks a bit weird with the lightning being at the units' feet rather than their body
(I'd suggest looking at the function MoveLightningEx to do this)
You find pretty quickly with "advanced" spell making that locations are almost completely and utterly redundant and slow and are completely avoidable
I'll test the program for bugs and edit this post later
Edit: Testing went pretty well
- Object data, dummies etc. all good
- The only new "Issue" I found was in the first GIF I've attached below - While I'm aware why it happens (the unit moves further away making the orb visually stay in place) it does look a bit wrong for it to not continue moving at the same speed while not essential to change it does ruin the aesthetic a bit
- The second GIF kind of puts an emphasis on my previous point about the heights looking weird: the problem is significantly worse when targeting fliers and further ruins the effect of the spell (you can fix this the easy way: by making the ability only target ground units, meaning fliers should not really be damaged by the ability when doing AOE damage or the harder way: make the visual effect work for both ground and fliers (which would involve changing the fly height of the orb as it moves if the two units are of different heights)
Approved
