When joining a server with connection latency > 1tick, repeated relative teleports (~ or ^) will desync the client and server; the server side will not move the player
What I expected to happen was...:
The player on server and client should behave in the same way
What actually happened was...:
On the server, player stops accepting movement updates and, in the case of /tp @s ~ ~ ~ ~ ~, is stuck in place. On the client, the player can still move, albeit a bit jittery.
Steps to Reproduce:
1. boot up a server and client
2. use high latency connection or control latency with an external program (i use clumsy)
3. make sure rtt is > 50*teleportFrequency ms
4. join server and have /execute as @a at @s run tp @s ~ ~ ~ run constantly (repeating command block, ticking function, or any other clock running the command)
5. run /particle flash ~ ~ ~ to observe your server side location
Root Cause:
Looking at provided decompiled code, if teleportPos is set in PlayerConnection, movement updates will be skipped. If a new teleport is issued before a PacketPlayInTeleportAccept is received from the client, teleportPos will remain set, blocking movement updates indefinitely until new teleports are no longer issued.
Suggested fix:
1. If the movement's final location is in a decent range of the teleported to location, make the client's position the actual position.
2. If it is outside of said range, update the client to the server's position.
This should eliminate the desyncs and allow client movement, while still keeping a validation for the movement packet (if the teleport was rather far away, it'll then always update the client to that location).
Linked issues
is duplicated by 4
relates to 1
Attachments
Comments 9
Although im late, I voted for this in hopes it gains mojang's attention.
This is horrible as a mapmaker myself. All it takes is a repeating teleport command whilst on a server and everything goes wrong. I pray this gets fixed soon.
I submitted a bug report for this a few years ago, and my report was just merged with this one. I just wanted to add here that the fix suggested would not fix the entire problem. For my purposes, I want to be able to continuously teleport a player relative to a stationary entity, or any entity for that matter, and have their position on the client side properly updated. If I'm understanding correctly, the suggested fix would still allow the player to move around in the case of teleporting relative to a different entity. I don't understand the Minecraft code well enough to suggest my own fix, but if possible, I think the root of the problem needs to be fixed, which is that the client isn't updating the player's position when receiving frequent relative teleports.
Per this comment, the ignoring is actually the result of a fix with movement and teleporting. Reverting that would fix this, but unfix that report.
I'll see if I can think of something to incorporate your usecase for the suggested fix.
I'd like to request this to be reconsidered for fixing; any map that wants to control player movement (eg have a moving platform you can stand on) will freeze players in place server side, and not move them client side, and there's nothing that can be done to fix it reliably. Less frequent teleports do not fix it, as a less stable connection still freezes them then.
This is a major concern, especially since it is the only way to move a player properly (explosions make sound, particles, and push other players yoo, and mob collision will push nearby other players too).
I too would like to request a review of this ticket. This issue has been brought to light several times in the Minecraft Realms Slack and prevents desired mechanics within realms/future realms content from functioning as intended. It's a pretty game-impacting bug, (especially for mapmakers as already mentioned) because there doesn't appear to be a solid workaround. Furthermore, in the past, desyncs have always been considered valid issues so one would expect that the behavior described in this ticket would function as expected.
I would also like to request that this decision be reconsidered. Map makers have very little control over player movement as it is. You can make a player faster or slower; you can alter vertical acceleration; or you can teleport them. Teleportation should be the best way to get specific fine-grain movement, but as it is, teleporting more than a couple times a second causes desync. This makes it entirely impossible to implement many features that are common in game design.
Please reconsider resolving this issue. I know it's impossible to add commands to control player orientation and movement, so I hope this at least solves the problem.
Can confirm in 1.18.1; cause is explained in this comment: https://bugs.mojang.com/browse/MC-30489?focusedCommentId=635747&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-635747
I'm willing to keep this report updated and provide further information if necessary.
This is a quite big problem for map makers, and it shouldn't be too hard to fix (if the movement packet's new location is in a certain range of the teleport's location (if it was a relative teleport), just allow it, if not, force the client to update the position to server side).