Skip to content

Actor Relevancy, Owner-Only, and Dormancy Basics

A replicated actor is not broadcast to every client forever. The server decides which actor matters to each connection, whether only the owner should see it, and whether the actor is awake enough to send updates.

At a glance

Use this for: actors, variables, or multicasts that work for one client but not another - Main question: is this actor relevant to that connection right now? - Beginner rule: public global state belongs in GameState/PlayerState or always-relevant owners, not distant one-shot actors - Official docs: Actor Relevancy, Detailed Actor Replication Flow, and Actor Owner and Owning Connection

The one-minute version

  • Relevancy is per connection. An actor can be relevant to Client 1 and not relevant to Client 2 at the same time.
  • Unreal only sends replicated actor data to clients for which that actor is relevant.
  • A replicated actor that stops being relevant can disappear from that client until it becomes relevant again.
  • Owner-only actors or properties are meant for one owning connection, such as private UI/inventory/player-controller data.
  • Net Cull Distance, Always Relevant, Use Owner Relevancy, Net Update Frequency, priority, and dormancy affect whether and when clients receive updates.
  • Multicast RPCs are not global announcements. A multicast called by the server reaches clients for which that actor is relevant at the time.
  • Durable state should be replicated as state, so late joiners and newly relevant clients can reconstruct it.

Relevancy is an audience decision

Replication is not:

Server actor changed
-> send to every client immediately

It is closer to:

Server replication tick:
    for each connection:
        decide which replicated actors matter to this connection
        consider update frequency, priority, owner-only rules, dormancy
        send changed state/events for actors that pass

That is why a replicated enemy, projectile, pickup, or world widget can behave differently for different clients. Each connection gets its own view of what is currently relevant.

Authority, ownership, and relevancy

These terms are related, but they answer different questions:

Question Term
Who decides gameplay truth for this actor copy? Authority.
Which player connection owns this actor for RPCs/owner-only data? Owner / owning connection.
Should this actor be replicated to this connection right now? Relevancy.
Is this actor currently sleeping from replication updates? Dormancy.

Example:

BP_Weapon attached to Player 1:
    server has authority
    Player 1's connection owns it
    it may use owner relevancy
    private ammo details may be owner-only

A different client may still see a public weapon mesh or firing animation, but not receive private owner-only state.

Common relevancy levers

Beginner-level meanings:

Setting / idea What it changes
Always Relevant Actor is considered relevant broadly, often used for core framework/state actors.
Only Relevant to Owner Actor replicates only to the owning connection.
Use Owner Relevancy Actor follows its owner's relevancy decision. Useful for owned equipment.
Net Cull Distance Squared Distance beyond which the actor can stop being relevant.
Net Update Frequency How often the actor wants to send replication updates.
Net Dormancy Whether an actor can sleep instead of repeatedly checking/sending unchanged state.
Force Net Update / wake-style actions Push an update when an important changed actor needs to be considered sooner.

Do not start by turning everything Always Relevant and very high frequency. The cost is bandwidth and noise. First decide the intended audience for the state.

Owner-only state

Owner-only is for information one player should receive:

  • private inventory contents;
  • secret quest clue or hidden objective marker;
  • local ability cooldown details;
  • owning player's PlayerController data;
  • private failure reason for an interact/use request.

Shape:

Server:
    validates request
    changes owner-only replicated state on an actor owned by that connection
    or calls a Run on Owning Client RPC for private feedback

Owning client:
    receives private state/feedback

Other clients:
    do not receive that owner-only data

Do not put private data in GameState just because the HUD needs it. GameState is public match state. The local HUD can assemble public GameState data and private owner-only data from separate sources.

Public scoreboard and objective state

Public state needs a public owner:

Team score:
    GameState replicated variable

Per-player public score/name/team:
    PlayerState replicated variables

Door/open objective state:
    replicated objective actor or manager actor
    maybe Always Relevant if every player always needs it

Bad shape:

Objective actor is far away
-> server multicasts "objective complete" on that actor once
-> distant client never receives it
-> later scoreboard has no durable state to read

Better:

GameState.ObjectiveState = Complete  (RepNotify)
-> every relevant/public UI path can read current objective state
-> late clients get the current value when their GameState copy updates

Use the actor that matches the audience, not the actor that happened to detect the event.

Dormancy

Dormancy is a replication sleep tool. It is useful for actors that sit still with unchanged state most of the time:

  • a closed door that rarely changes;
  • a puzzle switch after its state is set;
  • a pickup spawner waiting between respawns;
  • a placed objective actor after initialization.

The beginner mental model:

Awake:
    actor is considered for normal updates

Dormant:
    actor can skip repeated update work while unchanged

Important state change:
    wake/flush/force update through the appropriate project path

Do not reach for dormancy while the basic feature is still broken. First prove the actor replicates, the server changed the value, the variable is marked for replication, and the client is intended to receive it.

Late relevance and late joiners

One-time events are fragile around relevance:

Server:
    MulticastPlayExplosion on BP_Barrel

Client A:
    relevant now -> sees explosion

Client B:
    far away or not connected yet -> misses explosion

That can be fine for a disposable explosion flash. It is not fine for the durable result:

Server:
    bBarrelDestroyed = true  (RepNotify)
    Health = 0
    collision disabled state applied

Now a late or newly relevant client can receive the destroyed state and show the correct barrel, even if it missed the original visual event.

Net update frequency is not instantness

Net Update Frequency says how often an actor wants to update. It does not guarantee every changed value is delivered this frame to every client. The server still has relevance, priority, channel, dormancy, bandwidth, and connection conditions to manage.

Good use:

High-ish frequency:
    important actors whose movement/state changes often

Low frequency:
    slow objective state, inactive pickups, decorative replicated props

RepNotify state:
    durable values clients can apply whenever the update arrives

If a value must feel instant for the owning player, add local prediction or owner-only feedback while still letting the server-owned result arrive later.

When it fails, and what failure looks like

Symptom Likely cause
Actor exists for host but not remote client Actor was never relevant to that client, or only the listen-server host saw server state.
Multicast reaches nearby client only Multicast ran on an actor not relevant to every expected client.
Client loses a replicated actor when walking away Distance-based relevancy removed that actor from the client's view.
Private inventory visible to everyone Private data was replicated through public state instead of owner-only state.
Door state changes on server but clients stay old Actor is dormant, not relevant, variable not replicated, or server never changed the replicated value.
Scoreboard missing late data Score/objective state was sent as a transient event instead of durable GameState/PlayerState data.
Owner-only actor goes to nobody Actor has no valid owner/owning connection.
Raising Net Update Frequency does not fix it The root problem is ownership/relevancy/state, not update rate.

Debug in this order:

1. Is the actor Replicates = true?
2. Did the server spawn or change it?
3. Is the actor relevant to this specific client?
4. Is it owner-only, and who owns it?
5. Is the value replicated or RepNotify?
6. Is the actor dormant or update-frequency-limited?
7. Was the event a one-time multicast when durable state was needed?

What relevancy settings do not do

  • They do not make a client authoritative.
  • They do not replicate widgets or local UI.
  • They do not make a multicast reach clients that are not relevant for that actor.
  • They do not preserve one-time events for late joiners.
  • They do not make private data safe if you put it in public GameState.
  • They do not replace replicated variables for durable world state.
  • They do not fix an RPC called from an unowned actor.
  • They do not make low-bandwidth connections ignore bandwidth limits.

Lookalikes - which one do I want?

Tool / setting Use when Watch out
Actor relevancy You need to know whether this actor reaches this connection. It is not the same as authority.
Only Relevant to Owner One owning client should receive an actor's updates. Requires a real owning connection.
Run on Owning Client RPC Server sends private feedback to one owner now. Not durable public state.
GameState Public match/objective state should be visible to clients. Not private player data.
PlayerState Public per-player data should replicate beyond the pawn. Not current body-only values.
Always Relevant Core state must be broadly available. Expensive as a default for every actor.
Dormancy Mostly unchanged replicated actors should sleep. Bad first move while still proving replication works.
Net Update Frequency You need to tune update cadence. Does not fix missing state, owner, or relevance.

The quick path is to make every replicated actor Always Relevant. The concrete cost is that bandwidth and debugging get worse as the project grows. Pick the right state owner and audience first.

Going deeper