Assuming a scoreboard objective rotation with type dummy, if the command execute as @a at @s store result score @s rotation run data get entity @s Rotation[0] is ran in an Always Active repeating command block, it is expected that the Vertical Rotation of each player will be set to their rotation score. This does occur, but it is inconsistent, ranging from -360 to 359
I believe this happens due to Rotation NBT not actually capping it's value, instead the value being given to rotation is the result of Rotation % 360 where % is modulus and Rotation >= 0. This isn't the worst thing, but the issue arises when Rotation NBT is negative and rotation then is given the value of Rotation % -360. Rotation NBT seems to not have a cap (and is inconsistent when being translated to rotation because if you continually rotate clockwise (angle is increasing), rotation will loop from 0 to 359. If you rotate from 0 to 720 (two full rotations), it then takes 2 rotations back (720 to 0) to begin getting a negative rotation score.
Related issues
is duplicated by
MC-122293
NBT Rotation of the player does not work as expected
MC-124827
Players rotation nbt value going out of the -180 to 180 range
MC-128096
Rotation displayed in f3 window is broken
MC-139127
x rotation stays negative when rotating to the left 720 degrees
MC-205931
Rotation value can go negative while still retaining the same absolute value
relates to
Comments
migrated
migrated
I think this has probably been happening for a very long time actually... I was originally going to write up a report on this quite a while ago thinking it was only related to a visual glitch during teleports, but now that I'm trying to create a raycasting thing for the first time, this inconsistency is giving me quite a headache trying to figure out the math for it, haha (would help considerably if it simply always matched the max 180/-180° style in F3). I'm sure there's a simple way to account for that inconsistency, but I'm too dumb to figure it out yet (but slowly getting there).
As for the visual glitch I mentioned, running a teleport command will reset that "overclocked" rotation value (as in, the value when you keep spinning in circles in one direction) to be within the starting 360° again, but your arm whips around with varying intensity based on how far twisted you were in one direction (Quick edit: Happened across MC-120545 right before I was about to go to bed; it focuses on this exact issue). It's a dead giveaway that you were teleported when you may not want it to be obvious (I and probably many map makers would be very happy campers if teleports in general never affected first person arm movement). Though unless they add the option to keep momentum with the now-merged teleport command, I'm not sure it's ever going to be truly possible anymore anyway to teleport someone without it being noticeable.
In short, everything related to this rotation wrapping issue is actually quite annoying when trying to use rotation creatively. And no more teleport momentum due to the removal of the original /tp is the cherry to top it off, haha.
As a side note, the wrapping issue doesn't happen with mobs (their horizontal rotation nbt is locked to 0-360 in the positive, though you can manually set NoAI mobs (or idle ones temporarily due to the bug in the next sentence) to have it be negative). Also, when not pathfinding, their horizontal rotation data freezes in the direction they were last moving, and doesn't update at all when looking around/at the player while in idle mode. Their vertical rotation updates normally though (looks like this bug is MC-63746).
Maxaxik
Affects 18w11a
migrated
On a separate note: the rotation nbt should probably be changed to be -180 to 179.999... in order to be consistent with selectors and the debug menu.
Jayceebee
Affects 18w30a
migrated
Can confirm for 1.13.2
migrated
Also in 19w08b. Note for your description that Java's native % operator uses the sign of the dividend rather than the divisor.
To reproduce:
Run /tp @s ~ ~ ~ 0 0
Rotate 180° counterclockwise
Run /data get entity @s Rotation[0]
The value will be negative, when it should always be between [0°,360°).
jamesmoton
Can reproduce in 1.14.3. When you press F3+C to get your coordinates (including rotation) as a /tp command, the x rotation value can fall outside the intended range of [0°,360°). This means that in order to get within that range, I need to spin clockwise or counterclockwise accordingly, sometimes a lot, or otherwise manually compute the value module 360° every time.
migrated
Confirmed for 1.19.2.
Confirmed for 17w50a