Skip to content

Destroy Actor / Set Life Span

At a glance

Lives in: Blueprint API / Actor - Target: an Actor - Blueprint returns: no value, just execution continues - C++ return: AActor::Destroy returns bool - Destroy timing: latent; normal destruction is completed at the end of the tick - Official docs: Destroy Actor, Set Life Span, AActor::Destroy

The one-minute version

  • Destroy Actor asks Unreal to remove that actor from the world. It does not instantly erase every reference in the same Blueprint node step.
  • Actor destruction is latent in normal gameplay: the actor is marked for destruction and the teardown completes at the end of the tick.
  • Stored references elsewhere are not automatically reassigned to None. After destruction, Is Valid should fail and calls through stale references should be guarded.
  • Components owned by the actor are torn down with the actor. Timers, overlaps, EndPlay, dispatcher bindings, and replicated destruction all have lifecycle consequences you should design for.
  • Set Life Span starts or changes a built-in destruction timer on the actor. A lifespan of 0 clears that timer.
  • Use Set Life Span for "this actor should clean itself up after N seconds." Use Destroy Actor when a game event has decided the actor should go now.

What Destroy Actor actually does

Blueprint's Destroy Actor node calls the actor destruction path. In C++, the underlying AActor::Destroy function reports whether the actor was destroyed or already marked for destruction, but the Blueprint node does not expose that boolean.

pseudocode of the engine behavior - not engine source

function DestroyActor(TargetActor):
    if TargetActor is None:
        execution continues
        return

    if TargetActor cannot be destroyed:
        execution continues
        return

    mark actor as pending destruction
    queue normal EndPlay/component/world cleanup
    actual removal completes at the end of the tick
    execution continues

"Latent" does not mean Delay. It means destruction is not a synchronous memory delete in the middle of your graph. The actor may still be the object currently executing this event, but it is on its way out and should not be used as if it will keep living.

What happens to references

Destroying an actor does not walk through your project and clear every variable that pointed at it.

InventoryManager.CurrentPickup = BP_Pickup_12
BP_Pickup_12 -> Destroy Actor

InventoryManager.CurrentPickup still has a reference slot,
but Is Valid(CurrentPickup) should now be false.

That is why reference owners need cleanup rules:

  • a trigger should remove an actor from its overlap array on EndOverlap or when the actor broadcasts/dies;
  • a widget should rebind when the player respawns;
  • an inventory manager should clear CurrentPickup if the pickup is consumed;
  • a component should unbind from long-lived external dispatchers during EndPlay if it registered itself as a listener.

Unreal's object system prevents normal gameplay destruction from becoming a C++ dangling pointer in Blueprint, but it does not make your game state correct. Guard optional/destroyable references and clear the variables that represent "currently selected," "currently held," or "current target."

Set Life Span

Set Life Span is the actor's built-in "destroy me later" timer.

Spawn Actor from Class BP_ImpactDecal
-> Set Life Span 8.0

When the lifespan expires, the actor destroys itself through the normal destruction path. Calling Set Life Span again replaces the remaining lifetime. Calling it with 0 clears the lifespan timer so the actor will not be destroyed by that timer.

Use Set Life Span for:

  • temporary impact actors;
  • one-shot pickup sparkle actors;
  • shell casings or debris that should clean up after a few seconds;
  • spawned helpers whose lifetime is independent of later gameplay decisions.

The common quick path is Delay -> Destroy Actor. The concrete cost is that the delay lives in one graph path with no actor-level meaning; replacing, clearing, or inspecting the pending lifetime becomes harder than using the actor's own lifespan.

EndPlay, components, and cleanup

Actor teardown sends normal lifecycle signals. The practical Blueprint point is simple: put cleanup where the dying actor/component owns the responsibility.

Examples:

BP_PoisonCloud EndPlay
-> Clear Timer by Handle
-> Call OnCloudEnded dispatcher if your design promises it

HealthComponent EndPlay
-> unbind from owner/external dispatchers as needed

BP_Pickup Destroyed/EndPlay
-> manager clears CurrentPickup if it points here

Components owned by the actor are unregistered/destroyed with it. If a component has an audio loop, timer, bound event, or reference into a manager, decide whether that cleanup belongs in the component's EndPlay or in the owning actor's death flow.

Do not rely on "the actor is hidden" as cleanup. Hidden actors can still tick, collide, play audio, or hold references unless you disable those systems.

Overlaps, timers, and dispatchers

Destruction can cause overlap end notifications as components unregister, but do not build critical gameplay on a vague "I hope EndOverlap fires in every case" assumption. If death/removal matters, make it explicit.

Safer patterns:

Pickup collected
-> Collector clears CurrentPickup
-> Pickup Destroy Actor

Enemy dies
-> Enemy.OnDeath dispatcher
-> AI/quest/widget listeners update
-> Enemy Destroy Actor or Set Life Span

Timers bound to an object that is being destroyed should not keep calling into that object, but timer handles still represent game state. Clear important handles in EndPlay so your intent is obvious when debugging.

Dispatcher bindings have two sides:

  • dispatchers owned by the destroyed actor go away with that actor;
  • if the destroyed actor/component bound itself to a longer-lived broadcaster, unbind during EndPlay so the longer-lived object does not keep stale listener entries around.

Multiplayer note

For replicated gameplay actors, the server should decide authoritative destruction. When the server destroys a replicated actor, clients are told that the actor is gone and their local copies are removed.

Common multiplayer traps:

  1. Client destroys only its local copy. The server still has the actor, so it can reappear or remain relevant to other clients.
  2. Client hides the actor instead of destroying on the server. Other clients and server gameplay state do not match.
  3. Client UI keeps an old pawn reference after server respawn. Rebind UI to the new pawn/component after possession changes.

Put authoritative health/death on the server, then replicate the result or let replicated actor destruction carry the actor removal.

When it fails (and what failure does)

Blueprint gives you no failure pin and no return value.

Common causes:

Cause What you see
Target is None Execution continues; nothing is destroyed.
Actor is already being destroyed Execution continues; references should already be treated as invalid.
Actor cannot be destroyed in that context C++ Destroy can return false; Blueprint node gives no boolean.
You called it on the wrong machine Local actor disappears on one machine but authoritative state disagrees.
You meant to destroy a component/widget Actor node does not remove just one component or UMG widget.

If later nodes still run after Destroy Actor, that is expected. Your own graph must stop using the target if the next logic assumes a live actor.

The pattern everyone actually uses

Pickup:

Player overlaps pickup
-> add item to inventory
-> clear player's CurrentPickup if it points to this pickup
-> Destroy Actor on pickup

Projectile:

BeginPlay
-> Set Life Span 5.0

On Hit
-> apply damage/effects
-> Destroy Actor

Enemy death:

Health reaches zero on server
-> disable collision and AI
-> broadcast OnDeath
-> play montage/effects
-> Set Life Span 3.0

The delay between death and removal is now actor-owned. If the enemy is cleaned up early, call Destroy Actor. If it should stay as a corpse, clear or avoid the lifespan.

Lookalikes - which one do I want?

Node/tool Use when Does not do
Destroy Actor A world actor should be removed now. Does not clear every external reference.
Set Life Span The actor should destroy itself after N seconds. Does not pause gameplay or hide the actor.
Set Actor Hidden In Game Actor should stop rendering but keep existing. Does not disable collision, tick, audio, AI, or input.
Set Collision Enabled Actor/component should stop blocking/overlapping. Does not hide or destroy it.
Remove from Parent A UMG widget should leave the viewport/parent. Does not destroy an Actor.
Destroy Component One runtime component should be removed. Does not destroy the owning actor.
Open Level The whole world should be replaced. Much larger lifetime boundary than one actor.

Rule of thumb: destroy removes lifetime, lifespan schedules destruction, hidden changes rendering, collision changes physical/query interaction.

Going deeper