Skip to content

Replicate Movement vs Replicated Variables

Replicate Movement is for an actor's network movement data. It is not a replacement for replicated health, ammo, movement mode, cosmetic offsets, or the rules that decide where the actor is allowed to move.

At a glance

Use this for: actors that appear in the right place on clients but still have wrong gameplay state, or state that replicates while motion does not - Main split: movement data vs your gameplay variables - Beginner rule: the server moves gameplay actors; variables describe extra state clients must know - Official docs: Set Replicate Movement, Replicate Actor Properties, and Networked Movement in the Character Movement Component

The one-minute version

  • Replicates lets the actor participate in actor replication.
  • Replicate Movement sends that actor's replicated movement data to clients.
  • A replicated variable sends that marked variable's value to clients.
  • Replicate Movement does not replicate every transform in your component tree. Treat the actor's root/capsule movement as the thing being networked first.
  • Replicate Movement does not send health, ammo, custom movement state, "is sprinting," "is aiming," "door is open," or UI data unless you replicate those separately.
  • Characters are special: Character Movement has prediction, saved moves, server checks, corrections, and smoothing. Do not judge all actors by a default Character.
  • Client-only movement of replicated gameplay actors can be corrected by the server. Move authoritative actors on the server, then let clients receive or predict the result.

Three separate switches

These settings answer different questions:

Setting Sends Beginner meaning
Replicates Actor existence and actor replication channel data. "This actor can be networked."
Replicate Movement The actor's replicated movement data. "Clients can receive where this actor is moving."
Replicated / RepNotify variable One specific gameplay value. "Clients can receive this state value."

For a moving pickup:

BP_Pickup:
    Replicates = true
    Replicate Movement = true
    ItemId = Replicated
    bConsumed = RepNotify

Replicate Movement handles where the pickup is. ItemId and bConsumed handle what it is and whether it is still usable.

What Replicate Movement is good for

Use Replicate Movement when the actor's server-authoritative location, rotation, or velocity should be visible to clients.

Good first examples:

  • a server-spawned pickup pushed by a moving platform;
  • a simple replicated objective actor;
  • a thrown non-character actor whose server movement is the truth;
  • a platform or door actor moved by server logic;
  • a projectile actor whose project-specific movement is simple enough to replicate as an actor.

For Characters, the normal Character Movement path is more than the actor checkbox. The owning client predicts its own movement, sends saved movement data to the server, and receives correction if the server disagrees. Other clients see smoothed replicated movement for that character.

What Replicate Movement does not send

Replicate Movement is not a "replicate everything about this actor" setting.

Missing thing Better owner
Health, ammo, score, door state Replicated or RepNotify variables.
Inventory contents Replicated inventory state, often owner-only if private.
Sprinting, aiming, stunned, dead Replicated state/enum if other machines need it.
Widget text or progress percent Local widget reads replicated state.
Mesh-only cosmetic lean/offset Local presentation or replicated pose/state if others need it.
Particle/audio component state Local presentation from replicated state or RPCs.
One-time impact cue Multicast/RPC if transient, or RepNotify state if durable.

If a remote client sees the actor in the right location but the wrong animation, UI, team color, damage state, or interaction state, Replicate Movement already did its job. You still need the gameplay state.

Root, mesh, and component offsets

For beginner debugging, think in two layers:

Actor/root/capsule movement:
    networked by Replicate Movement or Character Movement

Visual child components:
    relative offsets, animation, materials, widgets, VFX
    usually local presentation unless you replicate controlling state

Common trap:

Client sets Mesh relative location for a dodge
-> local client sees body slide
-> other clients do not see the same thing
-> server movement may later correct the actor/capsule

If the dodge changes gameplay position, move the capsule/actor through a server-authoritative movement path. If it is only a first-person camera or mesh flourish, keep it local or replicate a compact cosmetic state such as DodgeVisualState.

Characters are not generic actors

A default Character uses Character Movement. In multiplayer, that component does a specialized loop:

Owning client:
    predicts movement locally
    saves compact movement data
    sends move data to the server

Server:
    replays/checks the move
    accepts it or sends a correction

Clients:
    display smoothed movement for remote characters

That means:

  • changing Max Walk Speed only on the owning client can be corrected or disagreed with;
  • server-owned movement settings should match the gameplay truth;
  • custom movement modes need a replication plan;
  • animation reads movement results, but it should not become movement authority;
  • root motion and launch/teleport behavior should be tested with actual remote clients.

Do not copy a Character solution onto a physics crate, projectile, or elevator without checking what actually owns the movement.

Server teleports and forced movement

For authoritative gameplay movement:

Client asks:
    ServerUseDash(AimDirection)

Server:
    validates cooldown, stamina, direction, blockers
    moves/launches/teleports the actor
    updates replicated cooldown/state

Clients:
    receive movement correction/update
    update local presentation from replicated state

If a dormant or low-frequency actor changes position, the problem may be the replication timing around the actor, not the movement value itself. Wake or force relevance/update only when the feature really needs that immediacy; do not turn every actor Always Relevant because one door update felt late.

Physics-simulating actors

Physics adds another owner question:

Who is simulating the authoritative physics result?

For a beginner multiplayer project, server-authoritative physics is the safer mental model. Let the server apply gameplay impulses/forces to replicated actors, then clients receive movement. Client-only physics pushes can look responsive locally and then diverge or snap when the server's state arrives.

If the object is purely cosmetic debris, it may be better as local-only effects on each machine rather than a replicated physics actor.

When to add a replicated variable

Add a replicated variable when clients need a durable fact that movement does not describe.

Examples:

Moving elevator:
    Replicate Movement = true
    bIsActivated = RepNotify
    CurrentStopIndex = Replicated

Character:
    Character Movement handles normal movement
    bIsSprinting = RepNotify if remote animation/UI needs it
    bIsStunned = RepNotify if gameplay/presentation needs it

Projectile:
    Replicate Movement = maybe, depending on design
    DamageAmount usually stays server-side
    ImpactState replicated or multicast only if clients need confirmed impact

Replicate compact state. Do not replicate a variable every Tick just to rebuild a movement system by hand unless the project has outgrown built-in movement and you are intentionally designing custom networking.

When it fails, and what failure looks like

Symptom Likely cause
Actor exists on clients but does not move Actor replicates, but Replicate Movement is off or movement only happens on a client.
Actor moves but health/ammo/state is wrong Movement is replicated, but gameplay variables are not.
Remote client snaps back after moving Client moved authoritative gameplay state locally and the server corrected it.
Character sprint works only for host Speed/state changed only on authority or only on the local client, not through a server-owned replicated path.
Mesh looks offset differently per client A child mesh/camera/visual offset is local presentation, not actor movement replication.
Door/platform late joiner sees wrong pose The final state/position was sent as a one-time event instead of durable movement/state.
Physics object jitters or disagrees Multiple machines are trying to own simulation, or server updates are fighting local physics.
Teleport arrives late Actor update frequency, relevancy, or dormancy is delaying replication.

Print the actor name, net mode, authority, root location, mesh relative location, velocity, movement mode if applicable, Replicate Movement value, and the exact machine that changed each value.

What Replicate Movement does not do

  • It does not make the actor replicate if Replicates is off.
  • It does not replicate arbitrary Blueprint variables.
  • It does not make client-only movement authoritative.
  • It does not automatically replicate every child component's relative animation or cosmetic offset.
  • It does not replace Character Movement prediction/correction.
  • It does not solve physics authority.
  • It does not guarantee every client receives the actor while it is irrelevant or dormant.
  • It does not make widgets, sounds, or Niagara systems follow network state by themselves.

Lookalikes - which one do I want?

Tool Use when Not for
Replicate Movement Actor/root movement should be sent to clients. Health, ammo, score, UI, or custom state.
Replicated variable Clients need a durable gameplay value. Per-frame actor transform updates.
RepNotify Clients should run local presentation when state arrives. Client movement authority.
Character Movement A Character needs walking/falling/jumping with prediction/correction. Generic actor physics or elevators.
Set Actor Location You intentionally place or teleport an actor. Normal predicted Character walking.
Multicast RPC A transient movement-related cue should play for relevant clients. Reconstructing durable position/state for late clients.
Local visual offset Only the owning player needs camera/mesh polish. Gameplay collision or authoritative position.

The quick path is to turn on Replicate Movement and assume the feature is done. The concrete cost is that state bugs get mislabeled as movement bugs. Separate "where is the actor?" from "what state is the actor in?"

Going deeper