Description: When firing a rocket with a dispenser or a crossbow, the particles left behind by the rocket will speed up greatly. When tested in Java edition, this does not occur.
Replication:
Set simulation distance to 4
Store the rocket in a dispenser or crossbow
Rocket must have a flight duration greater than 1
A rocket with a flight duration of 3 is the best at replicating the bug
Launch the rocket in an open area
After a few seconds, some particles will come speeding towards the launch point
Media:
[media]Related issues
relates to
Attachments
Comments



I cannot reproduce this. Are you using any resource packs?

Using fireworks with a flight distance of 1 will not replicate it since it blows up too early.
Craft your firework with multiple gunpowder to increase the distance. I would recommend using 3 gun powders for easier replication.
I do not have any resource packs or behavior packs enabled.
[media]
Using fireworks with a flight distance of 1 will not replicate it since it blows up too early.
Craft your firework with multiple gunpowder to increase the distance. I would recommend using 3 gun powders for easier replication.
I do not have any resource packs or behavior packs enabled.
[media]
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.