Rewrite teleport reply position to fix riding teleport loop on 1.8 servers - #5041
Packsolite wants to merge 3 commits into
Conversation
…rvers Since 1.21.2, clients keep their own position when receiving a teleport while riding and reply with that instead of the teleport position. A 1.8 server expects the reply at the teleport position, treats anything else as an illegal move, and endlessly corrects the player, eventually kicking the client. Rewrite the reply position to the teleport position, which is what pre-1.21.2 clients already reported. Fixes ViaVersion#4748
kennytv
left a comment
kennytv
left a comment
There was a problem hiding this comment.
The polling feels like it'll break on clients/servers with high latency, depending on where Via is installed? accept teleportation was added specifically made because of that
Can you elaborate please? In which scenario would it break? |
|
The incoming player movement can be behind what the server is sending so you rewrite one movement to be "correct" and the next one is suddenly dozens of blocks away again |
Well, that is exactly why I used a FIFO queue. If the server sends two teleports, the first position packet from the client will be rewritten to whichever teleport was sent first. Do you still think that is an issue? |
2 participants
Fixes #4748
Since 1.21.2, the client keeps its own position when it receives a teleport while riding and replies with that position instead of the teleport position. As from the protocol docs:
An 1.8 server, however, expects the reply at the teleport position and treats anything else as an "illegal" move and endlessly corrects the player. Each correction is another teleport, so client and server ping-pong until the client is kicked ("You are sending too many packets"). Clients before 1.21.1 applied the teleport even while riding, so this never happened before.
This PR implements a fix by remembering the position of every teleport sent to the client and rewriting the client's reply to it. This matches pre-1.21.2 behavior of the client.
Reproduced on Paper 1.8.8 with a 26.2 client (packet capture + server-side teleport-event log showing ~250 corrections/s until the kick, see #4748). With this change the loop no longer occurs and mount/dismount behaves normally.
Disclosure: Part of the research and implementation of this PR were AI assisted. I've reviewed and verified the results and any changes made.