Concept: Multiplayer and Prediction

Every system in this plugin is built for a dedicated server plus clients. This page states where each piece runs so you can stop guessing.

Where things run

Operation	Runs on	Notes
Granting abilities, effects, attribute sets	Server	Replicates to the owning client.
Ability activation	Owning client predicts, server confirms	Standard GAS prediction.
Movement parameters (`MaxWalkSpeed`, rotation flags)	Both machines, in lockstep	Anything less rubberbands - see How-To: Fix Movement Rubberbanding.
Cast and channel completion	Server	The client mirrors the timer for cosmetics only; only the server's completion spawns or applies anything.
Toggle and channel stop input	Owning client signals, server decides	Sent as a replicated ability task, never a client-replicated `EndAbility`.
Cast-completion cost and cooldown	Server	The activation prediction window has closed by then, so a client-side apply would never reconcile.
Charge count (`ChargesUsed`)	Server	Owner-only; the owning client learns it through the reliable `Client_SetChargesUsed` RPC (Gameplay Abilities cannot use replicated properties).
Equipping augments	Server	Replicated as registered subobjects.
Stateful augment accumulation	Server	Never read it directly for UI.
Combo transitions	Owning client predicts, server validates	Rejection rolls the client back.
Combo transition conditions	Server only	Clients skip evaluation entirely.
Game phases	Server only	Authority-only by construction.
Persistence snapshots	Server	Restored state replicates normally.

How combo prediction works

The owning client runs the full state machine locally, writes no replicated property, and sends one RPC per decision. The server re-runs the same logic authoritatively and either commits - writing CurrentNodeID and CurrentCombo, which replicate back - or rejects.

Window validation is tolerant rather than exact: the server accepts a transition inside window +/- min(half-RTT, Server Ping Leniency Cap). Requiring frame agreement would make combos unplayable above trivial ping. Tune the cap in Project Settings - lower for competitive, higher for co-op.

What replicates

Property	Condition	Why
`ActiveComboGrants`	`COND_OwnerOnly`	Only you need your unlock state; it is also progression data other players should not receive.
`DynamicEvents`	`COND_OwnerOnly`	Consumed by the owner's own prediction.
`CurrentNodeID`	`COND_OwnerOnly`	Used for rollback comparison on the owning client.
`CurrentCombo`	All clients	Simulated proxies need it to resolve combo completion.
`LastReachedEndPointID` + counter	All clients	How a remote client learns a combo finished.

Server trust

The server never acts on a client-supplied asset path

A transition request names a combo, but the server resolves it against its own armed watchers rather than loading whatever the client named. Both server RPCs are also rate limited, so a client cannot flood the reliable channel.

Testing it

Standalone PIE hides every one of these distinctions, because there is no client. Always finish a feature with Play As Client and at least 2 players. The two failures this catches most often are granting on the client instead of the server, and caching a PlayerState-owned ASC before it has replicated.