Don't forward in-flight velocity updates for arrows or fireballs

[Term4]

1.8 tracks arrows & fireballs with sendVelocity=false — the client predicts the whole trajectory from the spawn velocity and receives no in-flight velocity updates. Modern servers track arrow velocity deltas (trackDeltas) and send periodic velocity packets, which ViaRewind forwarded unchanged. They overwrite the client's local prediction and desync its block-collision raytrace, making arrows visibly stick to / slide off block edges before snapping back. This drops in-flight velocity packets for arrows so the client predicts cleanly, matching native 1.8.

[Beaness]

Even though this helps with desyncs I'm not sure whether its a good idea to completely drop all motion sync packets, if a plugin for example sets a new velocity after a few ticks then this wont be shown to 1.8 clients.
For example a plugin like https://dev.bukkit.org/projects/homingarrow will probably break.

A better solution might be to modify your server software to just not use sendVelocity on any versions (if that works).

[Term4]

Even though this helps with desyncs I'm not sure whether its a good idea to completely drop all motion sync packets, if a plugin for example sets a new velocity after a few ticks then this wont be shown to 1.8 clients. For example a plugin like https://dev.bukkit.org/projects/homingarrow will probably break.

A better solution might be to modify your server software to just not use sendVelocity on any versions (if that works).

Ahh I see what you mean. It is possible to fix server side, and this change could cause issues with other plugins / projects, so you're right probs best to not. It could still be good to document the issue, and the fix, if there's a place to do that here.

[Term4]

Even though this helps with desyncs I'm not sure whether its a good idea to completely drop all motion sync packets, if a plugin for example sets a new velocity after a few ticks then this wont be shown to 1.8 clients. For example a plugin like https://dev.bukkit.org/projects/homingarrow will probably break.

A better solution might be to modify your server software to just not use sendVelocity on any versions (if that works).

Actually i'm not so sure. It looks to me like that plugin altered the arrows initial velocity rather than updating the arrows velocity mid flight. If there were some way to distinguish between synchronization velocity and manually set velocity, would this fix be more reasonable?