MC-170907Network position deltas are processed relative to a wrong point
Steps to reproduce
- Run a minecart in a loop (see the screenshot below)
- Teleport 100 blocks away and wait a few seconds (/tp ~100 ~ ~)
- Teleport back (/tp ~-100 ~ ~)
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to MC-342, MC-2783 and probably many other similar issues.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
Linked Issues
Low
Created Issue:
Network position deltas are processed relative to a wrong point
Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which come into the player's tracking range but have already existed on the server side for some time.
Also, the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which come into the player's tracking range
buthave already existed on the server side for some time.Also, the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
Steps to reproduce
- Run a minecart in a loop
Teleport 100 blocks away and wait a few seconds- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.Steps to reproduce
- Run a minecart in a loop (see the screenshot below)
- Teleport 100 blocks away and wait a few seconds (/tp ~100 ~ ~)
- Teleport back (/tp ~-100 ~ ~)
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
relates to
![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Some extra context/information about this issue; this is not just present for quick tick rates exclusively, but any tick rate. The minecart's hitbox generally does not consistently follow the appearance of it's model, but a faster tick rate makes the issue far more apparant and obvious:
2023-11-04_16-23-08.mp4
This could possibly duplicate and/or relate to MC-170907, and imo definitely relates to MC-71779.
Does MC-170907 describe your issue? While it showcases minecarts in the example, it is more generally an issue with all entities.
Can sort of reproduce: rapidly teleporting in and out of render range does cause the cart to go off the track, but it gets back on track relatively quickly. https://youtu.be/ji7pCsABKlY
Also had to teleport ~140 blocks to get the minecart to stop rendering instead of just 100.