Destroyed Actors and respawn

Hiding an Actor is easy to reverse. Genuinely calling Destroy() is not — the object is gone, its references are stale, and something has to remember what it was. That is what WSRF keeps.

Presence, not a boolean

When an Actor leaves play, WSRF classifies the reason and stores it as EWSRFActorPresence:

Presence	Meaning
Loaded	The Actor exists right now
Destroyed	Genuinely destroyed during play; the record is kept for respawn
StreamedOut	Its level, cell or Data Layer unloaded; not destruction
Removed	Managed removal, such as a runtime Actor cleaned up by a reset

What the record keeps

For a destroyed placed Actor, the record retains:

• the Stable ID, and the effective identity (Stable ID + container context);
• the Actor class, as a soft class reference;
• the source level package and the container identity it belonged to;
• the captured automatic state, including transform, tags and mesh component state;
• the captured Custom State, if the Actor implemented IWSRFResettable;
• region membership, policy, reset priority.

No AActor pointer is retained. Records hold weak references and pure data.

Exact-once respawn

During a matching reset, the pipeline respawns missing placed Actors before restoring automatic state, and each record can respawn exactly once per reset operation. The report counts it in Respawned.

The respawned Actor:

1. is spawned from the recorded class into the recorded source level or container;
2. receives the original Stable ID rather than generating a new one;
3. is rebound to the existing record;
4. receives the captured automatic state;
5. has its attachments rebuilt;
6. receives its Custom State through the interface.

Because the ID is preserved, every other Actor’s stored reference to it still resolves after the respawn.

Failing loudly instead of guessing

If WSRF cannot prove the correct source level or container, it fails the record with an error in the report instead of spawning into the Persistent Level.

That is a deliberate trade: a wrong-level respawn produces an Actor that looks right, is in the wrong streaming container, and quietly breaks the next unload. An explicit RestoreFailed in the report is easier to diagnose than that.

Requirements for a respawnable Actor

Requirement	Why
The class must be spawnable	Abstract, deprecated or otherwise non-spawnable classes cannot be recreated
The class must be resolvable at runtime	The record stores a soft class reference
The source level must be available	The Actor is spawned back into its own container
The record must be Resettable	A Persistent or consumed OneShot record is meant to stay gone

Editor validation checks the first two before you ever run the game — see Validation and debug visualization.

Destroyed Actors that should stay gone

A OneShot pickup that has been consumed is a record whose absence is the correct state. It is not respawned by a reset, and its absence is exported in a persistent snapshot so it stays consumed across sessions.

References to a destroyed Actor

Never store a UObject reference to something that can be destroyed and respawned. Store its Stable ID and resolve it when you need it:

Capture:  Write Stable Id ("LinkedLever", Lever -> WSRF State Component -> Get Stable Id)
Restore:  Read Stable Id ("LinkedLever") -> Find Loaded Actor -> cast -> use

By the time WSRF Restore Custom State runs, every Actor that had to respawn already exists, so the lookup succeeds. Full example in Custom state and dependencies.

Attachments across a respawn

Attachment metadata — parent Stable ID, socket name, relative transform — is part of the automatic snapshot. The pipeline restores attachments in their own phase, after respawn and automatic state, and always parents before children.

If the parent is not managed by WSRF, the child’s attachment cannot be deterministically rebuilt. Validation reports that as an unmanaged attachment parent.

Diagnostics

Where	What it tells you
FWSRFResetReport::Respawned	How many Actors were recreated
FWSRFResetReport::Failed and Errors	Which records could not be restored, and why
GetActorPresence	The current presence of one Stable ID
World State Inspector	Destroyed, StreamedOut and Pending Restore rows, live in PIE

Demo

The demo map contains three genuinely destroyed breakable props specifically to prove this path. Break them, press R, and they return with their original identities — verified by the Lever/Door relationship, which resolves after both Actors were destroyed and respawned.