does it require JASS? Because I'm about to give up on this objective if it doesWith triggers it is more tricky as you need to filter a large area group enum search using the unit in rage of point native. This is because the standard area enum for units does not factor in collision size but WC3 abilities do.
JASS is recommended as always since WC3 GUI is kind of terrible unfortunately. Honestly I am not sure if the test is available in GUI.does it require JASS?
Does not factor in unit collision size, only origin. As I said the "best" solution is unfortunately not so simple. Also in such a case you would use cosine or sine for the comparison to avoid the 0 <-> 360 wrap around.A unit group formed at the midpoint of the 'cone' with matching units having an angle between them of less than (unit facing + x) and greater than (unit facing - x), where 'x' is 1/2 of your cone vertex angle, then damage the picked units in the group?
Tried this, and it becomes sorta buggy and usually covers MORE (i mean MOREEEEE) than the desired angleA unit group formed with matching units having a distance between it and the casting unit at less than or equal to desired max spell distance, and an angle between them of less than (unit facing + x) and greater than (unit facing - x), where 'x' is 1/2 of your cone vertex angle, then damage the picked units in the group?
That is not how you do it... You use IsUnitInRange, IsUnitInRangeXY or IsUnitInRangeLoc to filter a larger search area. These natives factor in collision radius.In reply to Dr Super Good, does it really matter that it only takes into account the origin of the units? Is he really likely to have units with a large enough hitbox that it is noticable? It isn't that hard to get around that, either, take 2arctan(collision radius) * dist and add it to the angle variance. Note: that is collision radius, and not diameter. But doing that is really unnecessary.
Or you use the properties of sine and cosine to avoid caring about the angle range.Also, to avoid 0 <-> 360, you would just take the angle difference add 180 Modulo 360 subtract 180, returning an equivalent angle difference between -180 and 180.
Which is why you apply a range check on the angle difference after pushing it through cosine or sine. Symmetrical and does not care if the angle wraps around. Also is faster because modulo is an emulated function (not native).Tried this, and it becomes sorta buggy and usually covers MORE (i mean MOREEEEE) than the desired angle
Actually they do very much work for conical areas. All one needs to do is compute the correct position and correct distance to test.IsUnitInRange, IsUnitI.. blah don't work with a conical area, though. Those only are useful for distance. Mine is useful for angles. Although you would have to account for both.
Value equality is symmetrical on either side of the caster. Using cosine something behind the caster would return -1 and something in front of the caster would return 1. The symmetry property can be used to create a range test to detect an angle range to either side of the caster. For example testing if the value is greater than 0 will return true for all angles between -90 and 90 degrees of the caster, even if the angle being tested has suffered from wrap around such as -360, 360, 720 etc.I guess you could use sine or cosine to compare them, but you have to remember that angles behind the caster will return the same values as angles in front of the caster (or something like that, depending on the implementation).
Sine and Cosine implementations are defined for every possible input. Even crazy ones like NaN should still return a value, even if that value is also NaN.Also I don't know what happens in WC3 when the sine/cosine function returns undefined.