Multiplayer and replication

What the plugin puts on the wire by itself - sea state and swimmer state - and what your game still has to synchronise.

Oceanology's water is deterministic given a position and a time, so most of it needs no network traffic at all: every machine evaluates the same Gerstner, spectral or FFT spectrum locally and arrives at the same surface. What does need replicating is the state that a designer or a gameplay event changes at runtime. That is exactly two things, and the plugin replicates both: the sea state, and the swimmer.

The sea state

AOceanologyWater replicates and is net-load-on-client, and it overrides ReplicateSubobjects to push its two wave sources down with it: the primary water waves and the breaking waves. Each source keeps a transient Effective Waves property replicated with push-model dirtying, so only a source whose parameters actually changed costs bandwidth. Set Effective Waves is the write path, and it takes the requesting actor and returns early unless that actor has authority, so a client cannot rewrite the ocean. On both server and client the OnRep invalidates every physics snapshot resolved from that source and asks the wave subsystem to rebuild GPU data, which keeps the rendered surface and the CPU physics answer on the same numbers.

Swimming

The swimming component replicates four properties and nothing else, all push-model: two gameplay tag containers plus the breath and drown counters. State Tags carries the authority-simulated situation, exactly one of Dry, Wading or Swimming plus any of Submerged, Drowning and Drowned. Control Tags carries the player's intent - Sprinting, Surface Locked, Ragdoll - and is deliberately a separate container so that a state update landing in the same frame cannot briefly revert a toggle the player just made. One before-and-after diff of the containers derives every side effect, and it runs identically on the authority and inside the OnRep, so clients take the same transitions the server did rather than a parallel approximation of them.

What is predicted, and by whom

• Movement is ordinary Character Movement input. Swim vertical and swim forward call AddMovementInput, so the engine predicts them like any other move and no custom RPC is involved.
• Control toggles are predicted locally. Sprint, surface lock and ragdoll apply the tag immediately on the owning client and then send a reliable server RPC, so the local response is instant and the server remains authoritative.
• Movement configuration is only touched on machines that actually run this character's movement - the authority and the owning client. Simulated proxies replay replicated movement untouched.
• Leaving the last water body is mirrored immediately on the owning client, dropping back to walking or falling, while the authoritative Dry state and the full movement-setting restoration follow through replication.
• Revive is a reliable multicast rather than a replicated counter, precisely because an OnRep also fires on initial replication and would give a late joiner a phantom revive the moment the actor became relevant.

On a dedicated server

A dedicated server has no renderer, so the GPU shallow water solver cannot run there. The simulation component detects that case - no rendering, dedicated-server net mode, or a feature level below SM6 - and falls back to the baked query state for the same region, so server-side gameplay queries still return the surface, depth and flow the clients are looking at. Primary wave evaluation is unaffected: the Gerstner, spectral Gerstner and FFT sources all publish CPU evaluators that run headless. Buoyancy pushes the water subsystem's water time to the physics thread every tick rather than the world clock, so server physics and client rendering sit at the same wave phase instead of drifting apart from world load.

Against the previous swimmer state model

This is one entry on the Galidar roadmap. For what already shipped in each release, see the Changelog.