Creating Rotators not working correctly for the first frame.

As far as I’m aware, the Rotator variables should always be clamped between 180 & -180 degrees.

Whislt investigating and setting up my own vision cone system for AI I’ve noticed that if I create a Rotator from Ints with a value is over 180 degrees or less than -180 degrees, then it won’t be clamped 180 & -180 until the next frame.

For the moment I’m working around this by checking values and adding or taking away 360 from them if they’re too high or low, but I want to check that my interpretation of a Rotator is correct and to see if anyone else is having this issue.

I think that is kinda normal, you don’t want to drift too far away from -180~180 because it would have greater float point error(that would be pretty far away for it to happen), but I don’t think most people would notice if the rotator self correct itself.
Or, you could simply using combine rotator with a empty rotator, that should fix it for you with a little overhead(maybe use it with begin play?).

I just pull this out of Monday morning brain, so make sure you test it. :slight_smile:

You don’t want to drift from -180~180 at all, otherwise your logic can be broken through no fault of your own. A Rotator is essential a value clamp so it shouldn’t give you the unclamped value accidently for a single frame.

I’ve already got a work around and despite noone else reporting it, it’s still happening so I’ve submitted a bug to AnswerHub

The rotator implementation is never specifically limited to the range of -180 to 180. It can provide values in that range and indeed many portions of the codebase use such normalized rotations, particularly when inheriting from Actor, but rotators are not inherently clamped. If you just add 360 to an axis every tick it will continue to go up by a full rotation until you hit the float max or couldn’t add without getting back the same value.

If the BP math functions matched those of the C++ rotator class this probably wouldn’t be any problem at all because Normalize(-180 to 180) and Clamp(0 to 360) would be right there, though in FRotator they are not what would be considered a pure function because they modify the rotator in place. Need a SafeNormalize function.