mojira.dev

Moulberry

Assigned

No issues.

Reported

MC-298558 Rain fog calculation can overshoot while game is unresponsive Confirmed MC-272962 (Duplicate) Display entities in 1.21 with rotation appear completely wrong Duplicate MC-263708 Keybinds menu renders Keypad keys the same as regular keys Confirmed MC-255263 Players' positions are desynced after stopping movement while moving the camera Fixed MC-255059 AttackStrengthTicker desynchronization when aborting block break Confirmed MC-255058 AttackStrengthTicker desynchronization when swinging Confirmed MC-255057 Client/server desync when breaking block from continueDestroyBlock Confirmed MC-236199 Crash while rendering if Merchant trades are updated while the window is open Invalid

Comments

This is likely the result of Minecraft representing rotations in the ClientboundMoveEntityPacket as a single byte with 256 values. In simple terms, it means that the minimum angle between rotations is 1.4 degrees.

For example, if the player's yaw is 137.0 degrees, the rotation of the entity will appear to be 136.40625.

If this is indeed the cause, the only fix would be to change the representation of angles in the move/teleport entity packets, but this has it's own drawbacks

This was fixed at some point in 1.20 during development of Display entities, but I cannot mark the bug report as fixed by myself

As of 1.19.3, the first reproducer (Case 1) is no longer working since the handling of relative teleports by ClientPacketListener#handleMovePlayer has changed. The change results in no angle wrapping, similar to the "hack-fix" proposed in the original report.

However, the underlying issue is still present and can be reproduced using absolute teleports. Simply rotate in circles several times, then perform /teleport ~ ~ ~ X ~ where X is the yaw value observed via the F3 menu.

The fix below is still applicable.

MC-39987 which was marked "Working as Intended", was not actually "Working as Intended".
MC-39987 has been fixed. You can now use \n in chat.
However, you still can't use \n in item lore.

This report is neither a duplicate (since it's about items, not chat) nor working as intended (see above). Please reopen it.

As for why I'd like this bug fixed:
While it is possible to simply use a "list of lines", this is not possible when working with translations.
I would like to be able to have a translation that is 2-lines long (eg. English) and a translation that is 1-line long (eg. Japanese).
This would be really easy to do if \n worked in item lore, because I could simply make it so that the English translation has a \n in it.

This is the same bug as MC-69865

The 1-line fix for this bug is outlined here: MC-255057

As of 1.19.2, this bug still exists, but the cause identified and fix proposed in the original report is inaccurate.

Whenever you want to find the difference between two angles, you always have to wrap the result of the subtraction.

This isn't being done in two places, causing this bug to occur when the yaw changes by multiples of 360.

 

(Note: the two changes below only affect rendering code, so they won't inadvertently break calculations involving yaw/pitch.)

 

1. LocalPlayer#serverAiStep calculates 

this.yBob += (this.getYRot() - this.yBob) * 0.5F;

If getYRot is 0 (because of a teleport) and yBob is 360, 720, etc., the result of this calculation is clearly wrong.

The correct calculation is as follows:

this.yBob += Mth.wrapDegrees(this.getYRot() - this.yBob) * 0.5F;

 

2. ItemInHandRenderer calculates

poseStack.mulPose(Vector3f.YP.rotationDegrees((localPlayer.getViewYRot(f) - k) * 0.1f));

Similarly to above, the correct calculation is:

poseStack.mulPose(Vector3f.YP.rotationDegrees(Mth.wrapDegrees(localPlayer.getViewYRot(f) - k) * 0.1f));