Describe the bug:
When teleporting players with relative arguments, players are still teleported despite the x, y, and z arguments being set to 0. This causes the camera to jerk/stutter, when it should not be moved at all. This bug is seemingly only present in 1.14 and above.
Discovery:
While working on a gun server, I implemented a recoil effect for shooting guns using teleports with relative arguments to move a player's camera yaw/pitch. Because the teleport arguments are relative, sending a packet with only yaw/pitch having non-zero values should result in only yaw/pitch changing. However, if a player moves while this packet is sent, they seem to be teleported to slightly different x, y, and z coordinates despite them being zero.
Code to reproduce:
ServerPlayer serverPlayer = this.player;
// All arguments should be relative as we only want to change their yaw/pitch position
Set<ClientboundPlayerPositionPacket.RelativeArgument> relativeArguments = EnumSet.allOf(ClientboundPlayerPositionPacket.RelativeArgument.class);
// Do not change x, y, or z coordinates
double x = 0.0D;
double y = 0.0D;
double z = 0.0D;
// Move yaw and pitch by 0.1
float yaw = 0.1F;
float pitch = 0.1F;
// Create and send the packet
ClientboundPlayerPositionPacket packet = new ClientboundPlayerPositionPacket(x, y, z, yaw, pitch, relativeArguments, 0, false);
serverPlayer.connection.send(packet);Send the player this packet every tick while the player is moving to observe stuttering/teleporting.
Video demonstrations (watch in 60 FPS):
Bugged/incorrect outcome (stuttering while being teleported while moving) (1.19.2):
Video
Expected/correct outcome (no stuttering while being teleported while moving) (1.13.2):
Video
Linked issues
relates to 2
Comments 3
@Dhranios Yes, but when teleporting with relative arguments the player should not be moved at all if the x, y, and z arguments are set to 0 (which is the case in 1.13).
The issue here is the player is moved when I'm only trying to update their yaw/pitch.
Dhranios is wrong about this. This is caused by the player's xo, yo, and zo variables being set to the updated position on teleport, which screws with the renderer's interpolation. There isn't really a good fix other than hardcoding not to set these variables when the relative teleport amount is 0. This is more of a feature request than a bug report.
The reason for this is simple: the client moves, sends the move packet to the server (yes, even in singleplayer) and repeats this. The client, when moving, is always slightly ahead of the server. Commands run on the server-end, thus they use the "outdated" position, rather than the client's position.
Also, relates to MC-197855.