Runtime-spawned Actors

Placed Actors are authored content: WSRF knows them from the level, and can bring them back. Actors spawned while the game runs are different — nothing authored says they should exist at all. The framework treats them as a separate category with its own rules.

How origin is decided

EWSRFActorOrigin on the component:

Value	Meaning
Auto	Detected from how the Actor entered the world. Default.
Placed	Force placed-content rules
RuntimeSpawned	Force runtime rules

Auto is correct almost always. Override it only when a spawner produces something that should be treated as authored content, or the reverse.

The four behaviours

EWSRFRuntimeActorBehavior, on the reset policy:

Value	On a matching reset
RemoveOnMatchingReset	The Actor is destroyed. Default.
Preserve	Nothing happens to it
RestoreToCapturedState	It stays, and is returned to its captured state
Ignore	It is not managed during resets at all

Removal happens in its own pipeline phase — before placed Actors respawn — so a summoned enemy cannot briefly coexist with the placed enemy that is about to return.

A One Shot runtime-spawned Actor is never removed by a normal reset: One Shot records are unconditionally excluded from normal reset selection, so its behaviour is never even consulted.

Choosing one

Situation	Behaviour
Boss-fight adds, spawned waves, temporary hazards	RemoveOnMatchingReset
A summoned ally that should survive a checkpoint reset	Preserve
A spawned turret that should stay but re-arm	RestoreToCapturedState
Cosmetic Actors owned entirely by another system	Ignore

Registering a spawned Actor

With the component. If the spawned Actor’s class already carries a WSRF State Component, it registers itself at BeginPlay like any other Actor. Configure the preset and region on the class, or call SetResetPolicy / SetRegionMembership on the spawned instance before it registers.

Explicitly. RegisterActor(Actor, Options) on the subsystem registers any Actor with a FWSRFRegistrationOptions:

Field	Meaning
RequestedId	Ask for a specific Stable ID; leave invalid to generate one
Regions	Region membership
Policy	The full reset policy
Origin	Usually Auto
ResetPriority	Restore ordering among independent Actors
bAllowTransientId	Permit a session-only generated ID. Default true.

It returns FWSRFRegistrationResult: bSuccess, bAlreadyRegistered, bReboundToRetainedRecord, bRequiresInitialCapture, the assigned ActorId and EffectiveActorId, and a Message.

bReboundToRetainedRecord is the interesting one: it means this Actor took over an existing record — what happens when a destroyed placed Actor is respawned, or a streamed-out Actor comes back.

Transient IDs

A runtime Actor with no authored Stable ID gets a session-only generated one when bAllowTransientId is true. It identifies the Actor for the current session and is not expected to survive a save.

Unregistering

UnregisterActor(Actor, bForgetSnapshot) removes an Actor from the system:

• bForgetSnapshot = true (default) drops the record entirely — the Actor will not be respawned;
• bForgetSnapshot = false keeps the captured record while removing the live binding.

Use the first for an Actor whose lifetime your own system fully owns. Use the second when the Actor will come back and should reattach to its existing record.

Interaction with persistence

Persistent export covers Persistent and OneShot records. A runtime-spawned Actor left as Resettable — the normal case — is intentionally not written into a snapshot, because a save should not resurrect a wave of summoned enemies on load.

Demo

The demo map spawns a temporary runtime Actor and removes it on reset, colour-coded red. Press R and it disappears while the placed content returns.