Before / After

// issue

When letting go off the zoom input, there would be a delay equal to the round trip time before actually zooming out.

// cause

The zoom in/out state was handled via gameplay tag. That tag was applied upon pressing the zoom input by activating a gameplay ability that applies the effect that applies the tag, and the ability was cancelled when releasing input. Zooming in worked fine because the ability activation is predicted, but ability cancellation is not predicted so there was a delay equal to the round trip time before the ability got cancelled and the tag removed.

// fix

The boolean handling the zoom in/out state (bIsAiming) is now set locally immediately upon pressing input. Zooming is cosmetic only so it doesn't need to be validated.

// issue

Client impact particles were only visible locally, never visible for other simulated proxies.

// cause

The impact cue had no server-side execution path.

// fix

Play a non-replicated cue locally for responsiveness, and when target data is received, play a replicated cue since now the server will execute it and will surely have the correct information (hit result) of the impact.

// issue

1. Two grenades were being thrown each time, one at a random direction, with both exploding inconsistently.
2. Explosion cue was not visible on clients, only on the server.
3. The client was able to equip the grenade ability again even if they have none.
4. A client may not lose a grenade charge after throwing it.
5. The equip throwable animation was able to be interrupted indefinitely by spamming the equip button.

// cause

1. The throw animation ending callback was running on both client and server causing two grenades to spawn.
2. The grenade was being destroyed too quickly for the explosion cue RPC to reach clients.
3. Loose gameplay tags are local by design, replicated loose gameplay tags were needed for the NoThrowables tag.
4. The cost was predicted by a GE (manual cost handling), and when spamming fast enough, the server confirmation would not come back in time so invalid checks were sometimes passing.
5. The equip ability is predicted so by the time the server sends back the rejection, the animation was already interrupted.

// fix

1. Made the RPC only be called if no authority, and the server path will spawn the grande with no RPC, if also locally controlled (to prevent the double spawn).
2. Set a short lifespan for the grenade instead of immediately destroying so the RPC has time to reach clients.
3. Add replicated loose gameplay tag for NoThrowables instead of non-replicated so the client gets it.
4. Moved the cost reduction to the RPC where the grenade is spawned. Cost is now not replicated which is fine for grenades.
5. Partially fix by keeping track of when a throwable is being thrown via ThrowingThrowable gameplay tag. Still able to spam to interrupt but not as much.

// issue

1. Rubber banding. The client starts getting pulled to the destination, but after the round trip time passes, gets put back at the location before pulling.
2. Looping pulling sound never ends when pulling finishes/times out.

// cause

1. In my case, there was previously a check validating exact client impact point vs server impact point. At high latency the check would almost never pass because the check inherently compares the client's hit using the current server world state instead of the client world state at that point.
2. The actor notify looping cue that handles starting and fading out the sound was being removed in the grappling hook root motion callback task which only runs on the server.

// fix

1. Removed the check and now using a custom trace channel for the grappling hook which functions as a weak validation. Using the exact impact point with a tolerance check would require a full lag compensation system, which is out of scope and not that required for a PvE game.
2. Moved the removal of the cue to EndAbility which runs on both server and client, which is always called by the callbacks.

// issue

Projectile looking jittery instead of moving smoothly.

// cause

When using just replicated movement on the projectile, the server ticks the projectile movement component and the projectile's position replicates down to clients via standard actor movement replication, which looks jittery on high ping and packet loss due to the client only getting location updates after actor location replication, which results in constant corrections.

// fix

Use a local variable for the launch velocity passed into the projectile movement component. The launch velocity (passed in from the ability) is set at projectile spawn which triggers an OnRep that passes it into the component locally. This moves the projectile locally for smoothness. Replicated movement is no longer used on the projectile.

// issue

Rubber banding when being slowed/speed being added back in slow zones.

// cause

Setting speed values on the CMC is not predicted, so a high latency client keeps moving at the incorrect speed until they get the new movement speed replicated back which causes them to rubber band due to the correction.

// fix

Immediately apply speed reduction/adding back on the CMC locally when affected. Now the client is synced up from the start.