Hi.
Windows 7 64bit.
To reproduce the issue create a Pawn blueprint.
Add a transform variable.
Try and set the rotation values to
x=0,y=180,z=-90
You will notice when you hit recompile the variable sets itself to
x=180,y=0,z=-90
Ok. Now click and drag the Y value.
Notice how the Z and X values now jitter up and down and the Y value never incriments… it just hops to various different values.
Tried this with new blank projects.
As a workaround instead of using transform variables, instead use a Vector and a Rotator variable and make a transform from that.
Hey Crocopede-
Thanks for bringing this to our attention. I have submitted this bug to our internal tracking database for further investigation. Thanks for the workaround as well, in case others have the same problem.
Cheers
Hi.
Great stuff.
I just want to point out the same can be experienced for actors (static meshes) when setting to rotation values in a level. Under transform values. Not inside a blueprint.
For example i am trying to set a static mesh to X=90,Y=0,Z=90 but when i click somewhere else is resets to other values.
To work around this you need to set all values to 0 and then rotate the mesh using the rotation handles in the viewport instead.
Hi Crocopede,
So I got around to looking into this today. While we’re still looking into possible fixes, I wanted to let you know what was happening here…
So, the rotation is still representing the one you input. A 180 degree rotation about the y-axis will result in the same orientation as a rotation 180 about the x-axis and the z-axis.
When you input a rotation in euler angles (Euler angles - Wikipedia), we convert it into a quaternion (a more efficient representation of a rotation) and feed that to the transform (which stores rotation as a quaternion). Then, when the UI wants to show the rotation, it unpacks it from the transform and converts it back into separate distinct angles. It doesn’t know the original angles it was fed (so it cannot present those to the user), instead it shows an equivalent rotation.
The same thing happens if you enter 540 for a rotation around the x-axis. It “corrects” it to be 180, because 540 is a full rotation (360) plus another 180. Both 540 and 180 result in the same orientation.
All that said, we understand that we need to save off the user entered values and are working on that. I just didn’t want this to discourage you from setting up rotations (since the resulting values should be equivalent to whatever you enter).
Thanks for the information Mike. I am not discouraged in the least. Its still a young engine and there will be a few hickup’s.
And i learned something new… 
