Karl Jussila
- rik_mclightning1
- rik_mclightning1
- America/Chicago
- Yes
- No
When teleporting a player every tick to a stationary entity, the player's client can move around freely after the first teleport, but the server sees the player as still being on that entity. When the repeating command stops, it seems like the server snaps the player's location to what the player's client sees.
When teleporting a player every tick relative to a stationary entity, the player's client can move around freely after the first teleport, but the server sees the player as still being on that entity. When the repeating command stops, it seems like the server snaps the player's location to what the player's client sees. To reproduce, use a command like /execute at @e [type=armor_stand,name=tpTest,limit=1] run tp @a [tag=tpTest] ~ ~ ~
For clarity, the intention is to "stun" the player without locking their rotation. This has worked in previous versions, but it has since begun to exhibit this problem.
When teleporting a player every tick relative to a stationary entity, the player's client can move around freely after the first teleport, but the server sees the player as still being
onthat entity. When the repeating command stops, it seems like the server snaps the player's location to what the player's client sees. To reproduce, use a command like /execute at @e[type=armor_stand,name=tpTest,limit=1] run tp @a[tag=tpTest] ~ ~ ~For clarity, the intention is to "stun" the player without locking their rotation. This has worked in previous versions, but
it has since begun to exhibit this problem.When teleporting a player every tick relative to a stationary entity, the player's client can move around freely after the first teleport, but the server sees the player as still being at that entity. When the repeating command stops, it seems like the server snaps the player's location to what the player's client sees. To reproduce, use a command like /execute at @e[type=armor_stand, name=tpTest, limit=1] run tp @p[tag=tpTest] ~ ~ ~ running every tick.
For clarity, the intention is to "stun" the player without locking their rotation. This has worked in previous versions, but sometime around Minecraft 1.13, this behavior began.
This glitch seems to only happen on multiplayer servers.Multiplayer servers
TeleportationfreecamClient/Server Disconnect During Continuous Teleportation
When teleporting a player every tick relative to a stationary entity, the player's client can move around freely after the first teleport, but the server sees the player as still being at that entity. When the repeating command stops, it seems like the server snaps the player's location to what the player's client sees. To reproduce, use a command like /execute at @e[type=armor_stand, name=tpTest, limit=1] run tp @p[tag=tpTest] ~ ~ ~ running every tick.
For clarity, the intention is to "stun" the player without locking their rotation. This has workedin previous versions, but sometime around Minecraft 1.13, this behavior began.Description:
When teleporting a player every tick relative to a stationary entity, the player's client can move around freely after the first teleport, but the server sees the player as still being at that entity. When the repeating command stops, it seems like the server snaps the player's location to what the player's client sees. To reproduce, use a command like /execute at @e[type=armor_stand, name=tpTest, limit=1] run tp @p[tag=tpTest] ~ ~ ~ running every tick.Steps to Reproduce:
- Start up a server in any version after 1.13
- Connect to the server, not through localhost, as the bug only happens when the player has some ping
- Run /summon armor_stand ~ ~ ~ {CustomName:'"tpTest"'}
- Set up a repeating command running /execute at @e[type=armor_stand, name=tpTest, limit=1] run teleport @p[tag=lock] ~ ~ ~
- Give yourself the tag with /tag @s add lock
- Walk around
- Have someone else on the server verify that your character is stationary or set up commands to display your position on the server
Observed Results:
The player can walk around freely, while the server thinks they are stationary.
Expected Results:
The player should be kept in the same location, effectively locking their movement.
Videos:
I attached a video displaying the bug in 1.18.2 and another in 22w13a. I also showed how connecting to localhost results in different behavior in the second video.
Notes:
Notably, this bug does not happen when the player is teleported continuously to absolute coordinates.
Multiplayer servers not connected to via localhost
I'm not sure how reopening a bug report works. I added 1.15 to the affected versions a couple days after it was suggested I do so. I recently revisited a project that required this bug to be fixed and recalled this bug report I made, so I also just edited it to add a video demonstration and include 1.18.2 in the affected versions. Can this issue be reopened?
I just tested the bug in the latest snapshot, 22w13a, as well, and it had the same behavior. Also of note, I found that the bug only happens if the player has some ping. When connected through localhost, the command has the intended behavior.
That post does seem to describe the same issue, and it is more thoroughly tested. However, the fix that was suggested there doesn't sound like it would fix the issue I am having, which is being unable to restrict player movement by repeated teleports. Should I post a comment there explaining my perspective?
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.
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.