Local variables only exist for as long as the scope they're declared in does. Every time your trigger fires, it initializes "TeamColors" as a new Ally Color Setting with the default value. Because of this, it's always "Normal Colors" at the time you check its value, so your trigger will always set the triggering player's ally color setting to "Team Colors for Minimap and Game View".
One solution is to instead keep track of each player's setting using a global Ally Color Setting array which is indexed by player. Assuming you use the same variable name for the global, the correct trigger would look similar to this:
EventsUI-PlayerAnyPlayerpressesFkeyDownwithshiftExclude,controlExclude,altRequireLocalVariablesplayer=(Triggeringplayer)<Integer>ConditionsActionsGeneral-If(Conditions)thendo(Actions)elsedo(Actions)IfTeamColors[player] == Normal Colors
Then
Variable - Set TeamColors[player] = Team Colors for Minimap and Game View
UI - Lock ally color settings for players in (Player group(player)) to TeamColors[player]
Else
Variable - Set TeamColors[player] = Normal Colors
UI - Lock ally color settings for players in (Player group(player)) to TeamColors[player]
You were close with your first method. As SoulTaker said, rather than taking the difference of the absolute values, you should take the absolute value of the difference. There's a couple more things to add before it works correctly in all situations, though.
When you first obtain the difference between angles, it should be a number between -360 and 360. If either of the two angles used were not between -180 and 180, then it's possible that this difference is out of bounds. It is, however, still a valid angle. You can get it back in bounds by performing a modulo with this number as the dividend and 360 as the divisor. The result will be a number between -360 and 360 that represents exactly the same angle.
Then you can take the absolute value of that to obtain the magnitude of the turn.
However, there are two possible ways your unit can turn and we're not sure yet whether we found the long way or the short way. Fortunately, this is easy to solve for two reasons:
The correct angle you're looking for is 180 or less, as a unit cannot possibly need to turn more than 180 degrees to reach any facing.
The two possible angles are explementary (they add up to 360); if your unit can turn 270 degrees counterclockwise, it also could have turned (360 - 270) 90 degrees clockwise.
Therefore, all you have to do is check if the result is greater than 180.
If so, then you have the larger angle, and the correct smaller angle is (360 - result).
Otherwise, you already have the correct angle and nothing else needs to be done.
At this point, you can just divide the result by your turn rate to obtain the correct duration.
I've attached an example map that implements the method described. Left click anywhere and the baneling will turn to face it at 60 degrees per second. Alternatively, type any angle in chat and it will turn to face the typed angle at 120 degrees per second.
0
@SorcererPsy: Go
Congrats on top 10, you've certainly earned it!
Man, we made it look so easy in that video. To think that we still have yet to beat Hard mode despite our nightly attempts.
0
Local variables only exist for as long as the scope they're declared in does. Every time your trigger fires, it initializes "TeamColors" as a new Ally Color Setting with the default value. Because of this, it's always "Normal Colors" at the time you check its value, so your trigger will always set the triggering player's ally color setting to "Team Colors for Minimap and Game View".
One solution is to instead keep track of each player's setting using a global Ally Color Setting array which is indexed by player. Assuming you use the same variable name for the global, the correct trigger would look similar to this:
0
@AstralCV: Go
You were close with your first method. As SoulTaker said, rather than taking the difference of the absolute values, you should take the absolute value of the difference. There's a couple more things to add before it works correctly in all situations, though.
When you first obtain the difference between angles, it should be a number between -360 and 360. If either of the two angles used were not between -180 and 180, then it's possible that this difference is out of bounds. It is, however, still a valid angle. You can get it back in bounds by performing a modulo with this number as the dividend and 360 as the divisor. The result will be a number between -360 and 360 that represents exactly the same angle.
Then you can take the absolute value of that to obtain the magnitude of the turn.
However, there are two possible ways your unit can turn and we're not sure yet whether we found the long way or the short way. Fortunately, this is easy to solve for two reasons:
Therefore, all you have to do is check if the result is greater than 180. If so, then you have the larger angle, and the correct smaller angle is (360 - result). Otherwise, you already have the correct angle and nothing else needs to be done.
At this point, you can just divide the result by your turn rate to obtain the correct duration.
I've attached an example map that implements the method described. Left click anywhere and the baneling will turn to face it at 60 degrees per second. Alternatively, type any angle in chat and it will turn to face the typed angle at 120 degrees per second.