Multiple relative teleports in multiplayer can cause server to disregard all client movement, causing desyncs
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 by6
MC-141156Client/Server Disconnect During Continuous TeleportationDuplicateMC-231686Repeating Command block - Teleport command glitches [Freecam]DuplicateMC-255233Client side's player's coordinates does not applied into server when consistently teleporting player to `~ ~ ~ ~ ~`DuplicateMC-262281Relative Teleportation Desync DuplicateMC-265785In multiplayer, teleport command behavior is inconsistent between host and participant.DuplicateMC-275662Teleport command not "smooth"Duplicate
NormalAttachments1
Created Issue:
multiple relative tp in multiplayer can cause server and client to desync
When joining a server with connection latency > 1tick, relative tp every tick e.g. (/tp @s ~ ~ ~ ~ ~) will cause the client and server to desync.
What I expected to happen was...:
The player on server and client should behave in the same wayWhat 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
2. boot up two clients
3. use high latency connection or control latency with an external program (i use clumsy)
4. make sure rtt is > 50 ms (1tick)
5. join server and place repeating command block with /execute as player1 at @s run tp @s ~ ~ ~ ~ ~
6. observe with player 2Root 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.Environment
Windows 10, Java 8
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
multiple relative tp in multiplayer can cause server and client to desyncMultiple relative tp in multiplayer can cause server and client to desync
Windows 10, Java 8
![[Mod] Umija5895M](../../../data/avatars/users/10122.svg){kind=small}
When joining a server with connection latency > 1tick, re
lative tp every tick e.g. (/tp @s ~~ ~ ~ ~) willcausethe client and server to desync.What I expected to happen was...:
The player on server and client should behave in the same wayWhat 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
2. boot up two clients
3. use high latency connection or control latency with an external program (i use clumsy)
4. make sure rtt is > 50ms (1tick)5. join server and place repeating command block with/execute asplayer1at @s run tp @s ~ ~ ~~ ~6. observe with player 2Root Cause:
Looking at provided decompiled code, if teleportPos is set in PlayerConnection,movementupdateswill 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.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 wayWhat 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 locationRoot 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).
Multiple relative tpin multiplayer can cause serverand client todesyncMultiple relative teleports in multiplayer can cause server to disregard all client movement, causing desyncs
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
is duplicated by
relates to
is duplicated by
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
is duplicated by
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
is duplicated by
is duplicated by
Confirmed for 1.18.1 (the models you can see are a resource pack, the game is unmodded).
Maybe related to MC-197855 (this requires constant teleporting too, and is seemingly a packet being ignored because of it).
Hey there, thanks for testing. I'm curious, does MC-197855 describe your issue? I know it's much newer than yours but it seems to be gaining some traction and we could move it over there
I'm not 100% sure but I believe this is a duplicate of MC-197855.
Yup, this is MC-197855.
Thank you for your report!
We're tracking this issue in MC-197855, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
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.
Duplicate of MC-197855; Mojang intents to look into reworking the system, and then fix this, but as of now, it is not tracked as a bug.
Thank you for your report!
We're tracking this issue in MC-197855, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Duplicate of MC-197855. If this isn't what you're describing, cannot reproduce, a teleport command with all-relative or local coordinates will keep the motion just fine; for any of them being absolute, resetting motion is intended.
Duplicate of MC-197855, if changed it'd be part of a network rewrite, not a bug fix (I asked [Mojang] Moesh about it).
Thank you for your report!
We're tracking this issue in MC-197855, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
This is another case of MC-197855, just overly complicated within the description of the report.
![[Mod] ManosSef](../../../data/avatars/users/61702.png){kind=small}
Thank you for your report!
We're tracking this issue as MC-197855, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as Won't Fix, which means this is considered a bug but won't be fixed. The description of that ticket or the comments might explain the rationale. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
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).
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.
Per the DMs I've had with [Mojang] Moesh, this is not going to be fixed as a bug fix, but rather as a code rewrite some time.
