Also, it's better for you to use -180/180 angles instead of 0/360
In what way? I would imagine the performance difference between the two is so small that the JASS call overhead dwarfs it. Since these are angels, mathematically it makes no difference.
Using Facing of X unit you'll automatically get the correct angle of the direction the unit is facing, if you want (for example) Target all units withing a cone of 90º of unit's facing angle you can code it with -45/45º. Don't use Cos, Sin, or Tan if you don't know basic trigonometry/geometry.
You have to use cos/sin for detection (does not mater which as long as you use the one right for you) since they convert an angle into a finite range. Cos is mostly used due to it being a symmetrical function around 0 degrees starting at 1 and falling to -1 at -180/180 degrees. This removes all of the bother you get dealing with the cyclic nature of angels since a range of angles would correspond to some range of the cos of the angle range.
As far as I can tell tan is never used for this because its function behaviour is prone to thread crashes without strict angle bounds and also has a not very useful functional response.
also, X > 135 ^ X < -135 Is a 90º cone in your Left (Supposing you have a Facing angle of 90º or in other words, you're facing the North)
X < 45 ^ X > -45 Is a 90º cone in you Right (The same supposing as above)
Except you cannot numerically quantify such ranges for any unit facing. Unless you simplify the angles involved which will take more overhead than passing it to cos and using that to do it all for you.
Angle between points will also help you if you want to detect things in your left/right
Well you obviously need to find the angle of the flanking unit with respect to the unit being flanked.
The general approach to detecting if something is in a cone with respect to an offset of facing is...
1. Get the unit facing.
2. Get the something angle (angle of unit with respect to the unit as an example).
3. Get the deviant angle, this is [something angel] - [unit facing] - [offset]. The value here represents the angle of deviation with regards to the perfect offset and could be anything from >360 to <-360 depending on what happens but to remember than angles are cyclic.
4. Compute the value of deviation using Cos of the deviant angle. The closer it is to 1 the less deviation it is from the desired angle. In worst case it will be -1 if the something is located in the complete opposite direction of the desired angle.
5. Compare the value of deviation if it is larger than or equal to some constant (or even something dynamic if your angle range is dynamic). Do note the response of Cos is non-linear with regard to angle so values close to 1 and -1 represent a larger angle range than values around 0. Compute the constant by getting your cone maximum deviation angle and putting it through the cos function in a calculator. Only compute the maximum angle of deviation at run time if the maximum angle of deviation is dynamic.
It should be noted that there exists 3 special cases of the above that are optimizations under certain circumstances.
1. In the case of comparing if something is directly behind you can skip adding a 180 degree offset by changing the sign of the maximum deviation constant and testing if it is less than or equal to it.
2. In the case of comparing if something is directly to the left you can skip applying a 90 degree offset by changing the way the value of deviation is computed to using sin instead of cos due to the equality being true that sin(x+90 degrees or pi/2 radians) = cos(x). The same comparison as normal will still work.
3. In the case of comparing if something is directly to the right you can skip applying a 270 (or -90) degree offset by applying the changes from both 1 and 2.
The result of these optimizations is a saving of the offset arithmetic. Mostly this is so trivial it will make no difference however in performance critical code it could result in noticeable savings.