Skip to content

Has Authority / Switch Has Authority / Is Locally Controlled

These nodes do not all mean "am I the server?" They answer different questions about one actor or pawn copy on the machine currently running the graph.

The one-minute version

  • Has Authority asks whether this actor copy has network authority. For normal replicated gameplay actors, that usually means the server copy.
  • Switch Has Authority is the same question as an exec branch: Authority path or Remote path.
  • Is Locally Controlled asks whether this pawn is controlled by a local controller on this machine. It is for local player input, camera, UI, and owner-only presentation.
  • A listen-server host's pawn can be both Authority and Locally Controlled. A remote client's pawn copy is usually Locally Controlled on that client but not Authority. The server copy of that remote pawn is Authority but not that client's local UI copy.
  • Authority is actor-specific. It is not a perfect "server process" test: standalone games and some client-local actors can also report authority.
  • Use Get Net Mode when you need the process mode: Standalone, Listen Server, Dedicated Server, or Client.

The three questions

Question Node Use it for
"Is this actor copy allowed to make authoritative state changes?" Has Authority / Switch Has Authority Server-side gameplay: damage, score, replicated spawns, pickups, match rules.
"Is this pawn the one this machine's local player controls?" Is Locally Controlled Local UI, camera, input presentation, first-person mesh visibility, local-only audio.
"What kind of network process is this?" Get Net Mode or net mode checks Dedicated-server UI/audio guards, listen-server testing, standalone/client/server diagnostics.

Do not use one node to answer all three questions. The most common multiplayer bugs come from asking the right question with the wrong node.

Has Authority

Has Authority returns a Boolean for a target actor:

Does this actor copy have network authority?

In the default server-authoritative model, the server's copy of a replicated gameplay actor normally has authority. Client copies are remote proxies.

Good uses:

Event AnyDamage
-> Switch Has Authority
   Authority: subtract health, update replicated state, award score
   Remote: do nothing

Overlap on replicated pickup
-> Has Authority?
   true: grant item and destroy pickup
   false: ignore or ask server through an owned actor

But authority is not exactly the same as "this machine is a server":

  • In standalone play, actors have authority because there is no remote server.
  • A client-spawned local cosmetic actor can have local authority over itself because it is not the server's replicated gameplay actor.
  • The Remote pin means "this copy is not authoritative for this actor," not "this graph is definitely running on a remote client process."

Use Has Authority for actor authority. Use net mode when you need process identity.

Switch Has Authority

Switch Has Authority is a branch node with two exec outputs:

Authority:
    this actor copy is authoritative

Remote:
    this actor copy is not authoritative

It is convenient when both sides need different work:

BeginPlay on replicated actor:
-> Switch Has Authority
   Authority:
       initialize replicated gameplay state
       start server timer
   Remote:
       prepare local presentation only

Avoid this shape on client input:

Input Fire
-> Switch Has Authority
   Authority: ServerFire or FireWeapon
   Remote: nothing

That makes the listen-server host work and remote clients do nothing. Input is local to the owning player. The better shape is:

Input Fire on locally controlled pawn/controller
-> local cosmetic response if desired
-> call ServerFire RPC

ServerFire:
-> validate cooldown/ammo/weapon
-> authoritative fire result

The client does not need authority to ask. It needs an owned actor path for the Server RPC. The server side of the RPC does the authoritative work.

Is Locally Controlled

Is Locally Controlled lives on Pawn. It returns true when that pawn is controlled by a local controller on the machine running the graph.

Use it for local player presentation:

Pawn BeginPlay / possession-ready setup:
-> Is Locally Controlled?
   true:
       create local HUD
       add input mapping context
       show crosshair
       use first-person mesh visibility
   false:
       skip local UI/input setup

Good jobs:

  • create or bind local widgets;
  • add Enhanced Input mapping contexts for this local player;
  • choose first-person vs third-person mesh visibility;
  • play local camera shake;
  • run local aim/crosshair traces for preview;
  • avoid showing every player's damage vignette on one client.

Poor jobs:

  • applying damage;
  • awarding score;
  • spawning replicated gameplay actors;
  • changing replicated inventory truth;
  • deciding whether the server should accept an action.

Local control is about the player's local view and input, not gameplay authority.

What the common cases look like

For a player pawn in a two-player listen-server test:

Machine / pawn copy Has Authority? Is Locally Controlled? Meaning
Listen-server host's own pawn, on host window Yes Yes The host is both server and a local player.
Remote client's pawn copy, on that client No Yes This client owns input/presentation for that pawn, but server has authority.
Remote client's pawn copy, on the server Yes Usually no for local-player UI purposes Server authoritative copy of that remote player.
Other player's pawn, on a client No No Simulated view of someone else.
AI pawn on server Yes Not a local human player Server/AI control, not player UI.
Dedicated server player pawn Yes No local player UI Server authority with no local screen/input.

The exact timing can matter during spawn and possession. If a pawn has no Controller yet, Is Locally Controlled may not be meaningful. Do local-player setup from possession/restart paths, PlayerController, or a short "current pawn changed" rebinding path rather than assuming every BeginPlay already has the final controller.

Server, owning client, simulated proxy

Unreal also describes actor roles:

Role idea Beginner meaning
Authority This copy is authoritative for the actor. For replicated gameplay actors, usually the server.
Autonomous Proxy A client copy that owns player input for that pawn and may predict/correct movement.
Simulated Proxy A client copy of an actor controlled elsewhere, simulated from replicated updates.

You do not need to start by wiring every graph around role names. But you do need the mental model:

Server copy:
    decides gameplay truth

Owning client copy:
    captures local input and shows local presentation

Other client copies:
    display replicated/simulated results

Has Authority points at the first. Is Locally Controlled points at the second for pawns.

Patterns that work

Damage

Projectile hit / weapon trace result:
-> if this is on a client, send request through owned Server RPC
-> server validates hit
-> server Apply Damage
-> damaged actor Switch Has Authority
   Authority: subtract health, set RepNotify Health, handle death

Do not let every client subtract health locally. They can show prediction or cosmetic feedback, but the server-owned health value is the result.

Local HUD

PlayerController BeginPlay or OnPossess:
-> create HUD widget locally
-> bind to current pawn/PlayerState
-> no Has Authority gate needed for local UI

If you create the HUD only on Authority, remote clients will not get their UI. If you create it for every pawn copy, one client may create UI for other players. Use local player ownership.

Input and server request

IA_Fire Triggered on owning client:
-> Is Locally Controlled guard if inside pawn
-> play local muzzle/camera feedback if desired
-> ServerFire(AimData)

ServerFire:
-> validate
-> spawn replicated projectile or apply hitscan damage
-> update replicated ammo/state

The input path is local. The result path is authoritative.

Dedicated-server guard

BeginPlay:
-> Get Net Mode
   Dedicated Server: skip audio, camera, widgets, local-only VFX
   Listen Server / Client / Standalone: allow presentation if locally relevant

A dedicated server has no player screen. Has Authority alone is not enough to decide whether UI/audio should run, because dedicated servers are authority too.

When it fails, and what failure looks like

  1. Remote client input does nothing. A graph put input work behind the Authority branch, so only the host/server path ran.
  2. Every client sees one player's UI effect. A local presentation change was replicated or multicast instead of guarded by local control/owning client.
  3. Dedicated server tries to create widgets or play camera effects. The graph checked Authority instead of net mode/local player.
  4. Client-side damage snaps back. The client changed local state but the server did not accept or replicate that change.
  5. Server RPC is dropped. The client called it on an actor it does not own.
  6. BeginPlay gives the wrong answer. Possession/controller setup was not ready when local-control logic ran.
  7. A client-local actor reports authority. It is authoritative over its own local-only copy, not over replicated gameplay truth.

Debug prints should include:

Actor display name
Has Authority
Is Locally Controlled (if Pawn)
Get Net Mode
Owning Player / Controller name
Local Role / Remote Role if available

Print from the graph that is actually running. Multiplayer bugs are often "this code ran, but in the wrong world."

Lookalikes - which one do I want?

Check Answers Use when
Has Authority Is this actor copy authoritative? Server-owned gameplay state changes.
Switch Has Authority Which exec path for authority vs remote? Splitting server state setup from client presentation.
Is Locally Controlled Is this pawn controlled by a local controller here? Local player UI/input/camera/presentation.
Is Local Player Controller Is this PlayerController local to this machine? Controller-owned UI/input paths.
Get Net Mode Is this Standalone, Client, Listen Server, or Dedicated Server? Process-mode debugging and dedicated-server guards.
Actor Owner / Owning Connection Which player connection owns this actor? Server RPC eligibility and owner-only replication.

The quick path is to put Switch Has Authority before every multiplayer node. The concrete cost is that it mixes authority, ownership, process mode, and local UI into one branch. Use the branch that answers the question you are actually asking.

Going deeper