Models lag in following entities
When placing an entity and observing its movement, there is a noticeable delay between the movement of the entity and its corresponding model. This delay affects the visual representation of the entity, causing the model to detach from the entity itself during movement or teleportation. This issue is particularly evident when using commands such as /tp to teleport entities. Additionally, the model may lag behind or detach from the entity during its movement, leading to a desynchronization between the entity and its visual representation.
Steps to Reproduce:
- Place an entity
- Use debug features or particles to track the entity.
- Make the entity move or use /tp command to teleport it.
- Notice the delay between the movement of the entity and its model.
- Observe any detachment or desynchronization between the entity and its model during movement.
Expected Results:
The model of the entity should move synchronously and smoothly with the entity itself, ensuring accurate representation of its movement in the game world without any detachment or delay.
Observed Results:
The model of the entity lags behind or detaches from the entity during its movement, resulting in a noticeable delay and desynchronization between the entity and its visual representation.
Note:
This issue also applies to endermen, where detachment between the entity and its model occurs during teleportation
"The video I attached shows that I used particles to track the entity every second, demonstrating the delay that occurs."
Linked Issues
is duplicated by4
causes2
relates to8
Created Issue:
Models lag in following entities
When placing an entity and observing its movement, there is a noticeable delay between the movement of the entity and its corresponding model. This delay affects the visual representation of the entity, causing the model to detach from the entity itself during movement or teleportation. This issue is particularly evident when using commands such as /tp to teleport entities. Additionally, the model may lag behind or detach from the entity during its movement, leading to a desynchronization between the entity and its visual representation.
Steps to Reproduce:
1. Place an entity
2. Use debug features or particles to track the entity.
3. Make the entity move or use /tp command to teleport it.
4.Notice the delay between the movement of the entity and its model.
5. Observe any detachment or desynchronization between the entity and its model during movement.
Expected Results: The model of the entity should move synchronously and smoothly with the entity itself, ensuring accurate representation of its movement in the game world without any detachment or delay.
Observed Results: The model of the entity lags behind or detaches from the entity during its movement, resulting in a noticeable delay and desynchronization between the entity and its visual representation.
Note: This issue also applies to endermen, where detachment between the entity and its model occurs during teleportation
"The video I attached shows that I used particles to track the entity every second, demonstrating the delay that occurs."
When placing an entity and observing its movement, there is a noticeable delay between the movement of the entity and its corresponding model. This delay affects the visual representation of the entity, causing the model to detach from the entity itself during movement or teleportation. This issue is particularly evident when using commands such as /tp to teleport entities. Additionally, the model may lag behind or detach from the entity during its movement, leading to a desynchronization between the entity and its visual representation.
Steps to Reproduce:
1. Place an entity
2. Use debug features or particles to track the entity.
3. Make the entity move or use /tp command to teleport it.
4.Notice the delay between the movement of the entity and its model.
5. Observe any detachment or desynchronization between the entity and its model during movement.
Expected Results: The model of the entity should move synchronously and smoothly with the entity itself, ensuring accurate representation of its movement in the game world without any detachment or delay.
Observed Results: The model of the entity lags behind or detaches from the entity during its movement, resulting in a noticeable delay and desynchronization between the entity and its visual representation.
Note: This issue also applies to endermen, where detachment between the entity and its model occurs during teleportation
"The video I attached shows that I used particles to track the entity every second, demonstrating the delay that occurs."
When placing an entity and observing its movement, there is a noticeable delay between the movement of the entity and its corresponding model. This delay affects the visual representation of the entity, causing the model to detach from the entity itself during movement or teleportation. This issue is particularly evident when using commands such as /tp to teleport entities. Additionally, the model may lag behind or detach from the entity during its movement, leading to a desynchronization between the entity and its visual representation.
Steps to Reproduce:
- Place an entity
- Use debug features or particles to track the entity.
- Make the entity move or use /tp command to teleport it.
- Notice the delay between the movement of the entity and its model.
- Observe any detachment or desynchronization between the entity and its model during movement.
Expected Results:
The model of the entity should move synchronously and smoothly with the entity itself, ensuring accurate representation of its movement in the game world without any detachment or delay.Observed Results:
The model of the entity lags behind or detaches from the entity during its movement, resulting in a noticeable delay and desynchronization between the entity and its visual representation.Note:
This issue also applies to endermen, where detachment between the entity and its model occurs during teleportation"The video I attached shows that I used particles to track the entity every second, demonstrating the delay that occurs."
relates to
relates to
relates to
is duplicated by
is duplicated by
is duplicated by
relates to
causes
relates to
is duplicated by
causes
This is because the visual position/animation of moving entities typically lags behind their server-side position (MCPE-179969), while the texture for things like being on fire updates instantly. For example, this also applies to hits (MCPE-109423) and explosions (MCPE-151881). So arrows and other projectiles catch fire when their server-side position passes through the fire.
Could you provide a video?
The coming out delayed and appearing to go too fast may be a result of MCPE-179969.
Moving slower after deflection may be intended, as ghast fireballs have a base speed of 1.6, and all deflected projectiles have a speed of 1.0.
Possibly caused by MCPE-179969, as this is similar to the visuals of MCPE-123321.
Thank you. I can see now that the issue occurs when a firework flies out of simulation distance. The visual firework is also suspended in mid-air. This seems related to MCPE-178258.
Here is what I think is happening: firework particle emitters must have their positions determined by an interpolation of the server-side position and client-side (model) position of the firework. When the firework flies out of simulation distance, it continues to be ticked server-side (MCPE-178258), so it's server-side position continues to update. However, the client does not update the firework model's position because the firework is too far away (related to MCPE-101102). As the server-side position gets farther and farther ahead of the model position in the direction of motion, the interpolated particle emitter position moves farther and farther behind to compensate for the apparent acceleration. In other words, with each tick the client "thinks" the firework must be moving faster because its server-side position is farther from its model position, and it infers from this that the model must have been farther behind at its previous update, and therefore it updates the emitter to be farther behind.
Part of the problem here may be that client model positions are themselves interpolated instead of updated directly (MCPE-179969, MCPE-151881), so the firework particle emitter positions are a second-order interpolation.
The most likely reason I think this might be happening is that the Players crosshair comes into contact with the Enderman while they are teleporting.
If you pay attention closely in Bedrock, when an Enderman teleports, they do not disappear in one location and then appear in another like in Java. Rather in Bedrock, when an Enderman teleports they appear to slide from one place to another incredibly fast. During this movement is when I think the their head somehow comes into contact with the crosshair causing them to become Aggro.
I've attached a video of how an Enderman moves when it teleports (in slow motion) to explain this better:
mojira_MCPE Recording 2024-08-14 190259.mp4![]()
Reply from [Mod] GoldenHelmet:
The appearance of movement when endermen teleport is just visual interpolation. Server-side they move instantly. This "animated" teleport is how all movement is rendered by the client since 1.16.100, as reported in MCPE-179969. I have made a new report just about teleports at MCPE-188176.
Please provide exact steps to reproduce the issue, or a video so that we can see what you are experiencing.
I suspect you may actually be experiencing desyncing between mobs’ visual position and their server-thread position. (MCPE-179969)
Thank you for your report!
We're tracking this issue in MCPE-123321 and MCPE-179969, 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 (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 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.
Note from [Mod] GoldenHelmet: the attached test world includes a modified version of the addon provided by the reporter. I have set the projectile's power, inertia, and uncertainty to 1, and it's despawn timer to 1.0 seconds. I have also slowed the fire rate of the NPC. These changes make the the cause of the issue easier to see and understand.
Steps to reproduce
See demo players hit only by client-side projectile which trails server-side by 6 ticks.mp4
- Load the attached test world. Proj despawn player dmg bug.mcworld

- Spawn a villager on the block labelled "Z = 23".
- Observe that the bullet fired by the NPC despawns before it hits the villager.
- Spawn a villager on the block labelled "Z = 22".
- Observe that the bullet fire by the NCP hits the villager.
- Kill the villgers.
- Stand on the block labelled "Z = 23".
- Changed to survival mode.
- Slowly move forward until you get hit by the bullet.
Expected result
The bullet hits you (the player) at the same max range that it hits villagers.
Observed result
The bullet hits the player at a max range of 16 blocks, but hits villagers at a max range of 22 blocks.
Analysis
The bullet moves 1 block/tick and despawns after 1 second, so it travels from the NPC at Z = 0 to Z = 21. It hits the villager at Z = 22 based on its trajectory when it is ticked for the last time at Z = 21. The bullet also hits the player server-side at the same distance. However, the player does not take damage from the bullet until the bullet hits the player client-side. The client-side position trails the server-side position by about 300 ms due to MCPE-179969. If the bullet despawns during the 300 ms that its client-side position is catching up to where it hit the player server-side, then it does not damage the player. The player takes damage in the test world only at Z <= 16 because that distance allows allows the server-side bullet to survive without despawning for long enough that the client-side position can catch up to the player's position.
When there has component "minecraft:despawn" in projectile, the mob who shoots projectile cannot deal any damage to the player. However, this mob can still deal damage to other non-player mob in same distance. And if I delete the component "minecraft:despawn", the projectile gets back to normal.
In the zip I upload, I make a easy Bedrock_Addon to show this bug. I am sure that it is not the problem of my projectile, the timer that makes projectile's despawn is normal, After testing, the projectile can fly a distance of 60 blocks before it despawn.
The way to test the test_bullet in zip is spawn a villager in front of the test_npc, and switch the survive gamemode for player.
Thank you for your report!
We're tracking this issue in MCPE-179969 and MCPE-122593, 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 (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
One way to fix this issue might be to just fix MCPE-179969.
Most likely a duplicate of MCPE-179969 as the issue here is also described there.




I have previously described this issue as the underlying cause of MCPE-138060, and part of the cause of MCPE-123321, MCPE-151881, MCPE-166739 and perhaps some other issues.
Essentially, client-side entity positions are several ticks or about 1/4 second delayed from server-side positions. Somehow, various animations such as the death animation and entity-generated particles (e.g. slime and magma cube particles) occur at exactly the right time. It is only position that lags.
Would you be able to provide a copy of the add-on / pack that you're using to show the entity model please? That would help the team to further debug the issue that you're reporting here.
The addon is not necessary to confirm this report. You can use the following particle command in a repeat, unconditional, always active command block with 0 delay:
/execute at @e[type = !player] run particle minecraft:villager_happy ~~~
This command creates a particle at each entity's server-side position. Record any entity moving and watch the recording slowly or study it frame by frame. The reports linked as "related" give various specific examples.
When an entity changes position server-side, both both Java Edition and Bedrock Edition animate the position change client-side so that it appears more like a continuous movement. Both editions begin the animation immediately, so there is no delay in the start time of the position-change animation. However, there are significant differences between Java and Bedrock:
You can see these difference in these two videos of a pig teleported 2 blocks to the left, and then 2 ticks later teleported 2 blocks to the right. Particles above the pigs track their server-side positions. These clips should be compared in slow motion or frame-by-frame.
2gt Java.mp4
2gt Bedrock.mp4
The accelerations and blending in Bedrock's animation might seem to make it more advanced or sophisticated. In-game, however, the Bedrock animation as a whole gives players a less accurate visual representation of where entities actually are, and it makes movement appear to be delayed or "laggy". Entities that are continuously moving server-side (for example, walking or falling) appear farther away their server-side position than on Java. Compare the following clips of a pig falling from 50 blocks up. Again, particles above the pigs track their server-side positions, and the clips should be compared slow motion or frame-by-frame.
pigs fly Java.mp4
pigs fly Bedrock.mp4
In Bedrock Edition mobs that move quickly typically appear on-screen near the position they had occupied server-side 4 ticks prior. This can be quite dangerous and disorienting. For example, baby zombies running toward a target appear to have double their melee attack reach: