Get Owner / Set Owner¶
At a glance
Lives in: Blueprint API / Actor - Returns: Get Owner returns an
Actor reference that can be None; Set Owner returns no value -
Fails by: returning None, changing only the wrong relationship, or
having no useful networking effect - Official docs:
GetOwner,
Set Owner,
Component Get Owner,
and Actor Owner and Owning Connection
The one-minute version¶
- Actor
Get Ownerasks, "what actor is this actor's optional Owner actor?" Many actors have no Owner, soNoneis normal. Set Ownerchanges that actor-owner pointer. It does not attach actors, possess pawns, set the damage Instigator, or make one actor contain another.- The actor Owner relationship is used mostly by networking: owning connections, owner-only relevancy, owner relevancy, and Run on Server permission paths.
- Component
Get Owneris a different relationship. On a component, Owner means "the actor this component belongs to." On an actor, Owner means the optional actor-owner chain. - In multiplayer, set owner on the server/authority for replicated gameplay
actors. A client-side local
Set Ownerdoes not grant permission to call server remote procedure calls (RPCs). - If you meant "stick this weapon to my hand," use attachment. If you meant "who caused this damage," use Instigator/damage pins. If you meant "who controls this pawn," use possession.
What they actually do¶
Unreal has several relationships that sound like ownership. This page is about the actor-to-actor Owner pointer:
flowchart LR
PC[PlayerController] -. owns .-> Character[Player Character]
Character -. owns .-> Weapon[Weapon Actor]
Weapon -- attached to socket --> Mesh[Skeletal Mesh Component]
The dotted arrows are actor Owner links. The solid arrow is attachment. They can point through the same gameplay objects, but they are not the same system.
The nodes behave roughly like this:
pseudocode of the engine behavior - not engine source
function Actor.GetOwner():
return Actor.Owner, or None
function Actor.SetOwner(NewOwner):
Actor.Owner = NewOwner // NewOwner can be another actor, or None
update owner-dependent engine bookkeeping
The Owner pin on Spawn Actor from Class
sets the same relationship during spawn. Set Owner changes it later.
Why networking cares:
- A client can only call Run on Server events on actors the server considers
owned by that client. In practice, the actor's owner chain must reach that
player's
PlayerController. - Owner-only replicated actors or owner-only conditions need a valid owning connection.
- Use Owner Relevancy can make an actor follow its owner's relevancy decision.
The conceptual decoder is Ownership and lifetime.
When it fails (and what failure does)¶
Get Owner can return None. Set Owner has no success pin.
Common causes:
- The actor simply has no Owner. Placed props, pickups, manager actors, projectiles, or environment actors often do not need one.
- You called component Get Owner and actor Get Owner interchangeably. Component Owner is the containing actor. Actor Owner is the optional networking/ownership chain.
- The owner chain does not reach a PlayerController. Setting a weapon's owner to a random world actor does not give a client permission to call server RPCs on that weapon.
- You set owner on the wrong machine. The server's ownership decision is the one that matters for replicated gameplay actors and server RPC permission.
- The actor is not replicated or not using owner-only behavior. Owner can still be a useful local reference, but it will not magically replicate an actor or make clients receive it.
- You expected attachment or lifetime cleanup. Actor Owner does not move the actor, parent it, destroy it with the owner, or attach it to a socket.
- You expected damage credit. Damage uses Event AnyDamage / point damage / radial damage pins such as Instigated By and Damage Causer. Actor Owner is not automatically "who caused the hit."
Failure usually looks like Get Owner returning None, a cast after it
failing, owner-only replication going to nobody, or a Run on Server event
silently not reaching the server because the actor is not owned by that client.
The node itself does not choose a fallback owner, attach the actor, retry later,
or print a guaranteed warning.
The pattern everyone actually uses¶
For server-spawned equipment that the owning player will operate:
Server equips weapon
-> Spawn Actor from Class BP_Rifle
Owner = PlayerCharacter
Instigator = PlayerCharacter
-> Attach Actor to Component hand socket
-> store EquippedWeapon reference on character/component
That gives the weapon an owner chain like:
Weapon Owner -> PlayerCharacter Owner -> PlayerController
Now owner-only visibility or an owned server RPC path can be reasoned about. The attach node still handles the hand socket. The Instigator still handles damage responsibility.
For a temporary effect that nobody needs to own:
Spawn impact decal / VFX / sound helper
-> leave Owner empty unless owner relevancy, owner visibility, or RPC access
is actually needed
Do not set Owner by habit. It is not a general "this belongs to me" label.
The C++ twin, for the curious (our own example code):
void ATrainingCharacter::EquipWeapon(TSubclassOf<AActor> WeaponClass)
{
if (!HasAuthority() || !WeaponClass)
{
return;
}
FActorSpawnParameters Params;
Params.Owner = this;
Params.Instigator = this;
AActor* Weapon = GetWorld()->SpawnActor<AActor>(
WeaponClass,
GetActorTransform(),
Params);
if (!IsValid(Weapon))
{
return;
}
Weapon->AttachToComponent(
GetMesh(),
FAttachmentTransformRules::SnapToTargetNotIncludingScale,
TEXT("hand_r_socket"));
}
Owner is not attachment, possession, Instigator, or Outer¶
The same word causes several beginner bugs:
| Relationship | Query / node | Means |
|---|---|---|
| Component owner | Component Get Owner |
Which actor contains this component. |
| Actor Owner | Actor Get Owner / Set Owner |
Optional owner actor, mostly for networking ownership/relevancy. |
| Attachment parent | Attach Actor / Attach Component | Which scene component transform this object follows. |
| Possession | Possess, Get Controller |
Which controller drives this pawn. |
| Instigator | Spawn/damage Instigator pins | Which pawn is responsible for gameplay consequences such as damage. |
| Outer | C++ GetOuter() |
UObject containment for memory/loading, mostly hidden from Blueprint. |
If the actor moves with another actor, think attachment. If the pawn receives input or AI, think possession. If a client needs permission or owner-only replication, think actor Owner.
Multiplayer rule¶
Actor Owner matters to networking, so set it where networking authority lives: the server.
Beginner-safe shape:
Client presses Equip
-> Run on Server request on owned pawn/controller
-> server validates
-> server spawns replicated equipment
-> server sets Owner to the player pawn/controller path
-> replicated actor/state reaches the intended clients
Changing Owner on a client copy does not convince the server that the client owns the actor. If a Run on Server event fails from an equipped actor, print:
- the actor name;
- net mode;
Has Authority;Get Owner;- whether the Owner chain reaches the player's PlayerController;
- whether the actor replicates and is relevant to that client.
Lookalikes - which one do I want?¶
| Node or concept | Returns / changes | Use when |
|---|---|---|
| Actor Get Owner | Optional actor Owner, or None |
You need networking owner/relevancy or an explicit actor-owner relationship. |
| Set Owner | Changes actor Owner; no success return | Server changes owner chain for equipment, owner-only data, or RPC access. |
| Component Get Owner | Actor that contains the component | A component needs its owning actor. |
| Attach Actor to Component | Transform parent/child relationship | The actor should follow a socket/component. |
| Possess / Get Controller | Controller-to-pawn control link | You need input or AI control, not networking owner. |
| Instigator | Pawn responsible for spawned actor/damage | Damage credit, team checks, or "who fired this projectile?" |
| Get Player Controller | Player slot's controller | You need local player input/UI/camera ownership. |
| Get Actor Of Class | Some actor in the world | You are searching, not following an owner relationship. |
Rule of thumb: Set Owner only when you can name the networking or owner-only reason. Otherwise use the relationship that matches the job: attachment, Instigator, possession, component ownership, or a stored reference.
Going deeper¶
- Ownership and lifetime - the four Unreal relationships that use "owner."
- Spawn Actor from Class - the Owner and Instigator spawn pins.
- Blueprint Custom Events as RPCs
- why Run on Server needs an owning client path.
- Actor relevancy, owner-only, and dormancy basics
- owner-only replication and relevancy debugging.
- Possess / Un Possess / Get Controller
- controller/pawn control links.
- Attach Actor To Component - socket and transform attachment.
- Event AnyDamage / Apply Damage
- damage Instigator vs Damage Causer.
- Official docs: GetOwner, Set Owner, Component Get Owner, Actor Owner and Owning Connection, and AActor.
- Engine source (requires engine access - we do not reproduce it here):
AActor::GetOwner,AActor::SetOwner,AActor::GetNetOwner,AActor::IsOwnedBy, and owner relevancy checks inEngine/Source/Runtime/Engine/Private/Actor.cpp; declarations inEngine/Source/Runtime/Engine/Classes/GameFramework/Actor.h.