Bug: Instances slightly offset their Pitch Yaw Roll value when rotated, moved or shift-cloned

[mikatastrophe]

Describe the bug

The Pitch Yaw Roll keyvalue in the Object Properties of a func_instance offsets itself to slightly incorrect floating point values when the instance is either rotated, moved or cloned (moved while holding shift). This has no visible effect on the map as far as I could tell, but does make the instance's rotation harder to read and is just generally annoying. As well as changing integers to long floating point values, values of 180 and 0 are changed to -180 and -0 too.

Footage of rotating an instance in hammer: https://github.com/StrataSource/Engine/assets/96993542/c410bfb7-006d-4c35-b65f-0bb428139a8d

Footage of moving an instance in hammer: https://github.com/StrataSource/Engine/assets/96993542/d0e910d5-5cf3-423a-91bd-6b9c337beb0d

This bug often leads to multiple instances that appear to have the same rotation and even originated from the cloning the same instance showing the Pitch Yaw Roll as (different) when group-selecting them, without ever independently rotating any of them willingly. The floating point offset seems to happen especially often (or maybe only) when rotating instances from 0 to any other rotation, and then back to 0. Rotating an instance on all axes like this has created this result: Notably, the actual values on each axis differ slightly, so the offset doesn't happen at the same amount every time. Also, the floating point offset doesn't seem to occur when the instance is moved or shift-cloned from an initial Pitch Yaw Roll of 0 0 0, but still does change to -0 0 0, which also seems nonsensical. Additionally, I think I remember the same problem occuring in prop_* entities, but wasn't able to reproduce it when trying.

To Reproduce

1. Open any map or create a new map in hammer.
2. Create a func_instance entity and assign it any valid VMF Filename in the Object Properties.
3. Once the contents of the instance show up in the map, rotate the instance around using the rotation handles in any of the 2D views. For 100% reliability, rotate it away from the default of 0 and then back to 0 in separate steps.
4. The Pitch Yaw Roll keyvalue should now contain one or more offset values.

Issue Map

Any map, this is a hammer-only issue.

Expected Behavior

When rotating a func_instance (or any other entity, should the problem occur in others too) in the 2D views using the rotation handles, I expected the Pitch Yaw Roll keyvalue of that instance to only contain integers (when not holding the alt key while rotating) and multiples of 0.5 (when holding the alt key while rotating) instead of long floating point offset numbers that appear like rotations of 0 in the 3D viewport or ingame. I also didn't expect rotations of -0 to exist, as they make no sense.

Operating System

Windows 10

[TeamSpen210]

What Hammer's doing is correct, but it does look rather confusing. The 5.00895e-06 notation is a common way programmers write really small/large numbers, it's the same as 5.0089 × 10⁻⁶, in other words 0.00000050089. The thing is that mathematically, combining two Euler angles (pitch/yaw/roll) isn't directly possible. Instead Hammer has to convert them into a different form (doing a bunch of sin/cos operations), combine them using a bunch of multiplications, then convert back. Any tiny inaccuracies in those calculations produce something almost but not quite zero, which is what you see. -180 and -0 might have been produced by a calculation being slightly offset. Floats do support signed zeros, which has some computational advantages.

All this really means is that the values are equivalent to what you want, mostly Hammer should perhaps round a little.