Multiplayer
Server-authoritative lock-on, replication model, prediction, and target switching across the network
Multiplayer
Agentic Targeting is server-authoritative with client prediction. The owning client predicts lock/switch actions immediately for zero-latency feel, the server validates and owns the real state, and the result replicates back to every client.
You don't need to write any networking code. Put the AgenticTargetingComponent
on the PlayerController (or Pawn), grant the lock abilities, and the
replication described here happens automatically.
What replicates
| State | Replicated | Notes |
|---|---|---|
HardLockTarget | ✅ OnRep_HardLockTarget | The authoritative hard-lock target |
SoftLockTarget | ✅ OnRep_SoftLockTarget | Soft-lock target |
bIsHardLocked | ✅ OnRep_IsHardLocked | Drives lock UI / state |
ReplicatedTargetPool | ✅ OnRep_TargetPool | Identities of the switchable pool, mirrored to clients for UI/cycling |
CurrentTarget is the local prediction pointer for instant response; it is
reconciled to the server's HardLockTarget via OnRep.
The lock flow
- Client presses Lock →
GA_HardLock(aLocalPredictedGAS ability) runs a targeting query, predicts the lock locally, and sends its chosen target to the server viaServerSetReplicatedTargetData. - Server consumes that target data (
CallReplicatedTargetDataDelegatesIfSet), validates it (ServerValidateTarget— range,CanBeTargeted, alive), and applies the authoritativeSetHardLockTarget. If the client's pick is invalid the server substitutes the best alternative or cancels (the client rolls back). HardLockTargetreplicates to all clients;OnRep_HardLockTargetupdates their local state and broadcastsOnHardLockChanged/OnTargetAcquired.
The server is the only authority. A client cannot force a lock the server rejects.
Switching / cycling targets
Switching an already-held lock (relock "Try Different", "Cycle", or stick-direction
switch) is also server-authoritative. The component routes every player-initiated
switch through RequestHardLockTarget():
- On the server / listen host / standalone → applies
SetHardLockTargetdirectly. - On a client → predicts locally for instant feedback and sends a
ServerSetHardLockTargetreliable RPC so the server adopts the new target and replicates it back.
This round-trip is required. If a client changed the lock with only local state, the
server's (unchanged) HardLockTarget would replicate back and snap the client's
lock to the previous target. If you author custom switch logic in Blueprint/C++ on
a client, call RequestHardLockTarget (not SetHardLockTarget) so the change reaches
the server.
Validation runs on the server
The lock-validation timer (LOS / distance / alive checks, GracePeriod,
ValidationFailAction) runs only on the authority — clients rely on the
replicated result. When a locked target fails validation the server decides whether
to switch or release, and that decision replicates to every client. See
Styles Reference → Validation
for the policy options.
Target switching on validation failure is validated before switching: the server only switches to a pooled target that currently passes the filters (e.g. has line of sight), so it never hands you an occluded target that would just drop again.
Testing checklist
Standalone and single-player PIE do not exercise replication, so always test networked features under a real net mode:
- PIE → Net Mode → Play As Listen Server, 2 players — both clients see each other's lock state.
- PIE → Play As Client with a dedicated server, 2 players — catches bugs the listen server masks.
- Lock an enemy on a client, then switch to another — confirm it stays switched (doesn't snap back).
- Break line of sight to the locked target on the server side — confirm the grace/validation outcome replicates identically to all clients.