When rotating an entity with /rotate using relative coordinates, the accuracy of the final rotation seems to vary depending on the entity's previous orientation. Sometimes it is slightly negative and sometimes slightly positive compared to the intended result.
While this appears to share the same root cause as MC-279766, it seems to have emerged specifically in version 25w32a, which is quite a bit later than the original report.
This only occurs in relative and local coordinates. Absolute coordinates seem safe.
/forceload add 0 0
/summon marker 0.0 0.0 0.0 {UUID:[I;0,0,0,0]}/forceload add 0 0
/summon marker 0.0 0.0 0.0 {UUID:[I;0,0,0,0]}Case 1 : rotate from 2.0 to 1.1 → 1.1 ✔ Expected
/rotate 0-0-0-0-0 2.0 0.0
/execute rotated 1.1 0.0 run rotate 0-0-0-0-0 ~ 0.0
/data get entity 0-0-0-0-0 Rotation/rotate 0-0-0-0-0 2.0 0.0
/execute rotated 1.1 0.0 run rotate 0-0-0-0-0 ~ 0.0
/data get entity 0-0-0-0-0 RotationCase 2 : rotate from 8.0 to 1.1 → 1.0999999 ❌ Wrong rotation
/rotate 0-0-0-0-0 8.0 0.0
/execute rotated 1.1 0.0 run rotate 0-0-0-0-0 ~ 0.0
/data get entity 0-0-0-0-0 Rotation/rotate 0-0-0-0-0 8.0 0.0
/execute rotated 1.1 0.0 run rotate 0-0-0-0-0 ~ 0.0
/data get entity 0-0-0-0-0 RotationCase 3 : rotate from 16.0 to 1.1 → 1.1000004 ❌ Wrong rotation
/rotate 0-0-0-0-0 16.0 0.0
/execute rotated 1.1 0.0 run rotate 0-0-0-0-0 ~ 0.0
/data get entity 0-0-0-0-0 Rotation/rotate 0-0-0-0-0 16.0 0.0
/execute rotated 1.1 0.0 run rotate 0-0-0-0-0 ~ 0.0
/data get entity 0-0-0-0-0 RotationComments 2
Let me put this in a programming perspective. What would be the value of f in the following code?
float f = 8.0;
f = 1.1;float f = 8.0;
f = 1.1;According to the IEEE 754 standard, the value of f must be exactly 1.10000002384185791015625, which is the closest representable number to "1.1". It should never result in 1.099999904632568359375(“1.0999999“) or 1.1000003814697265625(“1.1000004”). This is exactly what I am pointing out as a bug in this report.
Also, this is a simple assignment. The previous value 8.0 should have absolutely no influence on the subsequent assignment. Another key point of this report is that the entity's previous rotation is incorrectly bleeding into the new value during a /rotate command, which should behave as a clean assignment of the target coordinate.
Furthermore, it is important to note that this is a regression first observed in snapshot 25w32a. It worked correctly in previous versions, proving this is an issue with the game's implementation rather than an inherent limitation of the IEEE 754 standard.
It’s not caused by Minecraft. It's an issue that occurs in all programming languages because of IEEE-754 design used to represent floats.