#Ball synchronization issue

1 messages · Page 1 of 1 (latest)

fallen edge
#

I'm building a football system with client-side prediction. I've already fixed: Desync (client = server)
Ghost ball
Consistent speeds

But now I have a visual problem on remote client:
When a player releases the ball:

  1. The ball disappears (correct)
  2. Then it reappears incorrectly: In the wrong position; It stays still for a few frames; It can be stolen from behind
  3. After that: It snaps/teleports It follows its trajectory
    What's causing this it’s maybe conflict between: Client prediction and Server replication. The ball has two states at once, causing: Freeze, Visual rollback, Snaps

How it should look:

  1. Release
  2. Ball disappears (~200ms)
  3. Player still has no ball
  4. Ball reappears IMMEDIATELY while moving
  5. No static frames, no snaps, no delays

What I need to achieve is zero static ball after release, zero server snaps, zero ghosting, direct respawn while moving, smooth interpolation, no visual delay

I'm looking for help with How to correctly implement: client-side smoothing / interpolation, temporary ball hiding, clean reconciliation with the server without breaking physics or introducing desync.

If anyone has worked with: projectiles, sports, client prediction any tips would be great 🙏

wise ore
#

The issue is caused by a mismatch between client prediction and server replication during the moment the ball is released: the client immediately switches to a predicted moving ball while the server is still updating its authoritative state, so Roblox briefly sends an outdated position which makes the ball appear frozen, then corrected, then snapped into motion. This creates two conflicting states (client-simulated vs server-replicated) that overwrite each other for a few frames. To fix it, you should avoid hiding/recreating the ball and instead keep a single ball instance, instantly switch it to “released” state, apply predicted velocity immediately on the client, and smoothly interpolate toward server updates rather than snapping; the server should also set velocity instantly on release so both sides agree on motion timing, removing the freeze and eliminating the reappearance/teleport effect.

fallen edge
# wise ore The issue is caused by a mismatch between client prediction and server replicati...

Hey, your explanation about client prediction vs server replication helped a lot. I’m implementing this in and want to fix the ball release desync (freeze + snap issue).

Quick questions:

  1. Should I send a timestamp on release and have the server fast-forward the ball to match the client?
  2. Who should own the ball right after release, client or server?
  3. Is it better to briefly ignore server updates (~100ms) or always lerp toward them?
  4. When correcting position, how do you decide between lerp vs hard snap?
  5. Any best practice to keep fast interactions (like tackles) responsive but still synced across clients?

I’m aiming for a competitive, low-desync feel, so I want to get this part exactly right.