[!IMPORTANT] PredictedMovement contains a GrantClientAuthority() node This grants a partial location authority only Use this to iron out any de-sync that you cannot reasonably solve via Client-Side Prediction

Partial Client Location Authority

This system was spawned as the answer to a problem: Our attack, which registers only on the server, inflicts a snare, or root, or stun, or causes a knockback.

Because the client cannot reasonably predict receiving damage or the resulting effects, when receiving the snare (etc.), they experience significant de-sync. They rubber-band; their location gets pulled back into the past where that effect was applied.

This means for a player who is actively being attacked, especially by multiple players, being snared or rooted or knocked back means that their already one-sided experience is so much worse due to the constant de-sync.

Built-In Client Authority

UCharacterMovementComponent has bServerAcceptClientAuthoritativePosition and the matching function ServerShouldUseAuthoritativePosition() built-in.

This is a lie. A trap. What it really means when true is that the server will assume the client's location, and also not send any corrections. It will not send any data from the server at all. It will not even tell the client they have been snared!

This would also enable cheaters to use any application of movement-affecting effect to teleport anywhere they want. That's no good.

The Answer

What we want to do, and what this Client Authority system does is:

1. Allows external calls to GrantClientAuthority()
2. The call results in our FClientAuthStack adding FClientAuthData
3. ServerCheckClientError() compares the client's data to it's own, and returns true if it is out of sync
4. ServerMoveHandleClientError() processes our FClientAuthStack then queries ServerShouldGrantClientPositionAuthority()
5. ServerShouldGrantClientPositionAuthority() sorts parameters from the FClientAuthStack by priority and averages any with matching priority
6. Then, determines if we are far enough away from the server's location to be reported as possible cheating via OnClientAuthRejected()
7. Otherwise, determines how much of the client's location we should accept, and the server applies that location to itself

[!NOTE] This solution has been battle tested in a live-service hardcore PvPvE Action RPG. Players have not reported even noticing that we're doing this. From the perspective of the attacker, assuming the client's location on the server means that they would see their target slide a bit after applying a Snare etc., however it is too minimal to even notice.

When to Grant Authority to Clients

The greatest pitfall of this solution on an engineering team is the temptation to not fix avoidable de-sync and simply grant some authority for important actions. In production this can be a reasonable band-aid but it should be used wisely.

When using GAS and Root Motion Sources (RMS), and you apply RMS ➜ Root Motion Animation ➜ RMS, there will be de-sync that can't reasonably be avoided. This is a great atypical use-case for granting client authority. Sometimes abilities are simply too complex for CMC to reconcile with GAS.

Primarily, application of client authority should otherwise be limited to non-predicted modifications to the character's movement.