Concept: Multiplayer Authority
The owning client decides who, and the server decides how far. That split is not a compromise - it is the only honest arrangement, because the two machines genuinely cannot compute the same answer.
Why the server cannot just work it out
Target providers are client-side by design. A lock-on component runs for the locally-controlled pawn because targeting is a camera concern; a dedicated server holds no lock-on state for a remote player at all. So the server has no target to resolve against, and asking it to guess would mean guessing wrong.
Even where the server does have a target, it sees that target as an interpolated simulated proxy - tens of centimetres behind where it authoritatively is. Two machines resolving independently would produce two different points, and the difference would surface as a movement correction.
What actually happens
| Machine | Does |
|---|---|
| Owning client | Resolves against what it can see, applies locally so its prediction is immediate, and reports its conclusion on the ability's target data channel |
| Server | Waits for that conclusion, then validates the reported point against its own computed reach before planting it |
| Simulated proxies | Receive the planted warp target through the engine's own replication and reproduce the movement |
The report travels on the ability's target data channel rather than a component RPC, because that channel is keyed to the activation prediction key: data arriving before the server has activated the ability is held and delivered when it starts, instead of racing it.
When a reported point overreaches, the server keeps the client's direction and imposes its own distance. Discarding the point outright would leave the attack standing still, which reads as a bug rather than as a rejected claim.
What this asks of you
| Rule | Why |
|---|---|
Use Local Predicted for anything a player triggers | Under Server Only the owning client never runs the task, plays the montage unwarped, and is corrected by movement instead. The plugin warns when it sees this |
Keep Geometry Object Types on World Static | Static geometry is identical on every machine, so the collision clamp stays deterministic. Dynamic types can make the two sides disagree |
| Test on a dedicated server, not a listen server | A listen server host is both authority and locally controlled, so it never takes the path that matters |
Reading the Server vs Clients tab
Both sides round their point to the same precision before applying it, so agreement shows as a distance of essentially zero rather than as rounding noise. A large distance is a genuine divergence and is what produces a rubber-band.
Clamped client warp point warnings in the server log mean the acceptance tolerance is too tight for your latency - raise Server Accept Tolerance in Project Settings.See also
- How-To: Diagnose a Warp
- Concept: How Reach Is Derived