This is super confusing. You default Val 1 and Val 2 (use better variable names, I think) to a value, and then you immediately change them only if option == behind. I think you're trying to put too much stuff into this one function. Have one function for behind, and one for facing, keep it really simple.
That being said, it seems like the behind logic should be extremely simple.
sourceFacingAngle = facing angle of source,
targetDeltaAngle = angle from position of source to position of target
sourceFacingAngle - 90 should be greater than targetDeltaAngle
sourceFacingAngle + 90 should be less than targetDeltaAngle
The hard part is converting them because you want the values between 0-360, and you could subtract below 0 or go above 360. You might need to convert the values using modulus. It's also possible that if you use a variable of type "angle" (i think that's a thing) that it will automatically fix your angles to be between 0-360.
SC uses facing angles of -180 to 180 not 0-360. The reason I combined both into one function is simple, saving script space. The variables are named that because they are reversed in the behind option. The basics of the two functions are identical its a simple matter of reusing what I can. I just have to figure out how I managed to mess up the behind option as its returning true for certain angles it shouldn't. I will update this when I figure out what I did wrong.
What exactly does "angle between points" return? Does it reference the map's grid origin (0,0)? I know you need 3 points to return an angle, so this always confused me.
EDIT: It's all coming back now... the function must create a third "phantom point" using the line between the two given points as the hypotenuse of a triangle. So the question then remains - which angle does the function return? It wouldn't be the right angle of the triangle, that would just be silly to return 90 degrees every time. Is it the angle from point 1 or point 2?
What exactly does "angle between points" return? Does it reference the map's grid origin (0,0)? I know you need 3 points to return an angle, so this always confused me.
EDIT: It's all coming back now... the function must create a third "phantom point" using the line between the two given points as the hypotenuse of a triangle. So the question then remains - which angle does the function return? It wouldn't be the right angle of the triangle, that would just be silly to return 90 degrees every time. Is it the angle from point 1 or point 2?
Counting straight "north" or "up" on a map as -180 it returns the angle from the first point to the second going to 179.99~
Ah, so it always creates the phantom point for the right triangle down, since that would be zero degrees. I'm guessing then that angles to the right are positive (0 to 180) and angles to the left are negative (-180 to 0).
Ah, so it always creates the phantom point for the right triangle down, since that would be zero degrees. I'm guessing then that angles to the right are positive (0 to 180) and angles to the left are negative (-180 to 0).
EDIT: after further testing the original behind is also giving me erroneous results at certain angles :(
when the targets angle is >90 its returning true when the sources position is in front of but still clockwise to the targets facing, but still less than 180 degrees.
Taking an assumed facing angle of the target of 135 then the range should be:
(135[Face] - 90) <= Angle <= 180
OR
-180 <= Angle <=(-180 + (180 - 135[Face]))
Which ends up being (45 <= angle <= 180) OR (-180 <= angle <= -135) which should be correct.
Unless perhaps its simply that my math is right and my test is wrong since I need to have the angle be behind the target not in front. I really hate math :(
So if the target is facing 135 the angle between points needs to be -135 <= angle <= 45 to return true.
That means (180 + (180 - Face) <= Angle <= 180 - Face) this only applies if 90<= Face <= 180
I may have to re-split these functions as even though all the math is the same there's a lot of flipped values. Perhaps I can make the actual comparison a function...
Hmmm, so you're essentially converting directional facing to the "angle between points" facing, which is different (the -180/180 scale.)
I will continue to work through this. You may want to consider an alternative for now though. You can create temporary regions with a polar offset from point 1, then check if point 2 is within one of those regions. It shouldn't be too heavy on resources.
To see if a unit is behind another unit, check the facing of both, then check if unit 2 is in one of the offset regions for unit 1.
After more testing I was wrong about the angle, north is 90 east is 0 west is -180/180 and south is -90. This doesn't really change anything though. it does however though mean that it starts at 180 and goes clockwise down to -180.
Ok, I think I might have a solution. Start by converting the angle between points to a facing angle scale (0 right, 90 up, 180 left, 270 down.) Now check if Facing Angle > ABP - 10 AND Facing Angle < ABP + 10. The 10 is the acceptable range for which to return true divided by 2 (so with 10 you have a 20 degree flexibility.) If it passes these checks, return true, else return false.
I just got around to testing it. Turns out no conversion is necessary. I'll post the revised function in a moment.
EDIT: Here is the complete revised function. I tested everything and it works fine. Best of all, the function is small and easy to understand and manipulate:
I'll try yours out, in the mean time this is the behind option I made, I think it could easily be converted into a facing option. Does yours take into account the occurrences where a units viable range crosses the -180/180 mark?
I'll try yours out, in the mean time this is the behind option I made, I think it could easily be converted into a facing option. Does yours take into account the occurrences where a units viable range crosses the -180/180 mark?
As far as I can tell from testing, the -180/180 crossover doesn't effect the function at all. It seems to work fine no matter what the ABP is or what the facing angles of the units are. In the test map, the ghost fidgets around periodically so you can see it working from several different angles.
Its weird, it looks like when I set a variable to the facing of a unit it doesn't work. But if I don't set that variable like how you had it it works fine. Most of the issues I was having was the crossover of -180/180.
On second thought there does seem to be a bit of a glitch when unit 2 is facing near that 180/-180 threshold. The fix should be simple enough. Convert both facing and ABP to a 0 - 360 degree scale. I'll write that up now.
EDIT: Wow, that's a bit of a headache. This will take more time than I thought.
This is a relatively simple trigger to determine if a unit is either behind another unit or facing another unit.
This is super confusing. You default Val 1 and Val 2 (use better variable names, I think) to a value, and then you immediately change them only if option == behind. I think you're trying to put too much stuff into this one function. Have one function for behind, and one for facing, keep it really simple.
That being said, it seems like the behind logic should be extremely simple. sourceFacingAngle = facing angle of source, targetDeltaAngle = angle from position of source to position of target
sourceFacingAngle - 90 should be greater than targetDeltaAngle
sourceFacingAngle + 90 should be less than targetDeltaAngle
The hard part is converting them because you want the values between 0-360, and you could subtract below 0 or go above 360. You might need to convert the values using modulus. It's also possible that if you use a variable of type "angle" (i think that's a thing) that it will automatically fix your angles to be between 0-360.
@SkrowFunk: Go
SC uses facing angles of -180 to 180 not 0-360. The reason I combined both into one function is simple, saving script space. The variables are named that because they are reversed in the behind option. The basics of the two functions are identical its a simple matter of reusing what I can. I just have to figure out how I managed to mess up the behind option as its returning true for certain angles it shouldn't. I will update this when I figure out what I did wrong.
What exactly does "angle between points" return? Does it reference the map's grid origin (0,0)? I know you need 3 points to return an angle, so this always confused me.
EDIT: It's all coming back now... the function must create a third "phantom point" using the line between the two given points as the hypotenuse of a triangle. So the question then remains - which angle does the function return? It wouldn't be the right angle of the triangle, that would just be silly to return 90 degrees every time. Is it the angle from point 1 or point 2?
Counting straight "north" or "up" on a map as -180 it returns the angle from the first point to the second going to 179.99~
Ah, so it always creates the phantom point for the right triangle down, since that would be zero degrees. I'm guessing then that angles to the right are positive (0 to 180) and angles to the left are negative (-180 to 0).
Clockwise from -180 it goes up to 180.
Hmm, ok, the reverse then - angles to the left are positive, with angles to the right being negative. This will be useful to know in the future.
Here's an image of what I think is being returned, I hope it's correct:
I know this seems a bit off-topic, but I think once I get this down I will be better equipped to help you with your problem.
@BasharTeg: Go
Your diagram is correct.
Here's the original trigger which seems to work fine.
Here's the original "behind" trigger which I merged with the facing one later.
EDIT: after further testing the original behind is also giving me erroneous results at certain angles :(
when the targets angle is >90 its returning true when the sources position is in front of but still clockwise to the targets facing, but still less than 180 degrees.
Taking an assumed facing angle of the target of 135 then the range should be:
(135[Face] - 90) <= Angle <= 180
OR
-180 <= Angle <=(-180 + (180 - 135[Face]))
Which ends up being (45 <= angle <= 180) OR (-180 <= angle <= -135) which should be correct. Unless perhaps its simply that my math is right and my test is wrong since I need to have the angle be behind the target not in front. I really hate math :(
So if the target is facing 135 the angle between points needs to be -135 <= angle <= 45 to return true.
That means (180 + (180 - Face) <= Angle <= 180 - Face) this only applies if 90<= Face <= 180
I may have to re-split these functions as even though all the math is the same there's a lot of flipped values. Perhaps I can make the actual comparison a function...
Hmmm, so you're essentially converting directional facing to the "angle between points" facing, which is different (the -180/180 scale.)
I will continue to work through this. You may want to consider an alternative for now though. You can create temporary regions with a polar offset from point 1, then check if point 2 is within one of those regions. It shouldn't be too heavy on resources.
To see if a unit is behind another unit, check the facing of both, then check if unit 2 is in one of the offset regions for unit 1.
@BasharTeg: Go
After more testing I was wrong about the angle, north is 90 east is 0 west is -180/180 and south is -90. This doesn't really change anything though. it does however though mean that it starts at 180 and goes clockwise down to -180.
Ok, I think I might have a solution. Start by converting the angle between points to a facing angle scale (0 right, 90 up, 180 left, 270 down.) Now check if Facing Angle > ABP - 10 AND Facing Angle < ABP + 10. The 10 is the acceptable range for which to return true divided by 2 (so with 10 you have a 20 degree flexibility.) If it passes these checks, return true, else return false.
Here's the conversion process for the ABP:
Now the check:
And finally, to check if a unit is "behind" another unit:
So your total function should look something like this:
Let me know how it works for you.
@BasharTeg: Go
Well this is the new version I have that seems to be working. It would appear as though -180 doesnt exist as well it goes to -179.999~
When I get the chance to test my method I will. For now though I'll leave it at theory.
Here's the revised "behind unit" section. It was actually a lot simpler than I thought:
I just got around to testing it. Turns out no conversion is necessary. I'll post the revised function in a moment.
EDIT: Here is the complete revised function. I tested everything and it works fine. Best of all, the function is small and easy to understand and manipulate:
Here's a tutorial map you can use as well:
Link Removed: http://www.mediafire.com/file/21as7gp5cxgd07o/Unit Facing Detection.SC2Map
@BasharTeg: Go
I'll try yours out, in the mean time this is the behind option I made, I think it could easily be converted into a facing option. Does yours take into account the occurrences where a units viable range crosses the -180/180 mark?
As far as I can tell from testing, the -180/180 crossover doesn't effect the function at all. It seems to work fine no matter what the ABP is or what the facing angles of the units are. In the test map, the ghost fidgets around periodically so you can see it working from several different angles.
@BasharTeg: Go
Its weird, it looks like when I set a variable to the facing of a unit it doesn't work. But if I don't set that variable like how you had it it works fine. Most of the issues I was having was the crossover of -180/180.
On second thought there does seem to be a bit of a glitch when unit 2 is facing near that 180/-180 threshold. The fix should be simple enough. Convert both facing and ABP to a 0 - 360 degree scale. I'll write that up now.
EDIT: Wow, that's a bit of a headache. This will take more time than I thought.