FAQ
Direct answers about level reloading, destroyed Actors, Blueprint-only support, checkpoints, SaveGame boundaries, World Partition, Level Instances and multiplayer.
Does WSRF reload the level?
No. A reset restores the state of the records in the requested region: existing Actors return to their captured state, destroyed placed Actors respawn, runtime Actors are removed, attachments are rebuilt and Custom State is restored. The map is never reopened, so loading screens, streaming state and everything outside the region are untouched.
Does it work with genuinely destroyed Actors?
Yes. Destroy() is supported rather than worked around. The record keeps the Stable ID, the class,
the source container and the captured state, and a matching reset respawns the Actor exactly once
into its original container with its original identity.
The documented limits: the class must be spawnable and resolvable, and the source level must be available. If the correct container cannot be proven, WSRF reports a failure instead of spawning into the Persistent Level.
Does it require Souls Destruction Framework?
No. There is no dependency in either direction. The Runtime module depends only on Core,
CoreUObject, Engine, GameplayTags and PhysicsCore.
Does it require Coalborn?
No. Coalborn is GreyFox Studio’s internal game project. The plugin contains no reference to it, and an audit for project-specific includes, paths and content references is part of every development phase.
Can I use it in Blueprint-only projects?
Yes, and that is the intended workflow. The component, presets, subsystem, reset nodes, Custom State Writer and Reader, and both persistence nodes are all Blueprint-callable. Normal use requires no client C++.
Does it include a bonfire / checkpoint system?
Yes — the Rest Site / Checkpoint module: placeable
Rest Sites (or a component for your own shrine/bonfire Actor), discovered and activated states, a
configurable rest action menu, a normative rest sequence and a multi-world Quick Save. It is
optional and layered on top of the Core: a project that only wants Reset World Region never has
to configure a Rest Site, and player-progress logic (health, souls, leveling) remains your
project’s — the module raises events and Project Bridge hooks, your game answers them. The module
ships in version 1.0.0 — see the
release notes.
Is WSRF a SaveGame system?
No. It is a persistence adapter.
The boundary, precisely
WSRF provides no slots, files, autosave, cloud storage or save UI. It captures Persistent and One
Shot world state as pure data, and applies it back. Your project’s USaveGame stores it.
Does it support World Partition?
Yes, within the validated scope: World Manifest build and validation, effective identity using Stable ID plus container context, StreamedOut versus Destroyed classification, and Pending Restore for Actors that are unloaded or have never loaded during the session.
It does not force unrelated cells or inactive Runtime Data Layers to load in order to perform a reset.
Does it support Level Instances?
Yes, validated within the stated scope. Repeated Level Instances receive distinct container
identities, so the same authored Stable ID in two copies resolves to two independent records. Use
Reset World Region In Context and Find Loaded Actor In Context inside instanced content.
Does it support multiplayer?
Not currently. Network replication is not implemented, not validated and not advertised.
Stated honestly
Do not plan a networked feature around WSRF until replication support is announced in the changelog.
Can I store custom gameplay state?
Yes, through the versioned Custom State API. Implement WSRF Resettable, write named typed values
with UWSRFStateWriter during capture and read them back with UWSRFStateReader during restore.
Supported types are bool, int64, float, double, enum, name, string, vector, rotator, transform, Gameplay Tag, Gameplay Tag Container and Stable ID. Object references, arbitrary object graphs and generic containers are deliberately excluded.
Can a permanent shortcut stay open while enemies respawn?
Yes — that is the point of separating persistence mode from reset triggers. The shortcut door is
Persistent, so resets skip it entirely. The enemies are Resettable, so the same reset returns
them. Both live in the same region and respond to the same checkpoint.
What happens to Actors spawned during play?
They are classified as runtime-spawned, and their policy decides:
RemoveOnMatchingReset (default), Preserve, RestoreToCapturedState or Ignore. Removal happens
before placed Actors respawn, so a summoned enemy never coexists with the placed one returning.
Do managed Actors tick?
No. Neither the state component nor the subsystem enables Actor or component tick, and the editor Inspector has no permanent tick either. Registration captures once; resets visit indexed records.
Which engine versions are supported?
Unreal Engine 5.7 and 5.8, both validated — 5.7.4 and 5.8.1 respectively — with strict plugin builds, editor, game and shipping targets, and independent-project functional tests. No other version is claimed.
Is it finished?
The plugin is version 1.0.0 and no longer marked as a beta version in its descriptor. The
framework is feature-complete — including the Rest Site / Checkpoint module — has passed a full
independent code audit, and is now published on Fab. See the
release notes.
Where do I report a problem?
By email — see Support. Include the plugin version, the engine version, the validation code or report, and the reproduction steps.
Last updated: 2026-09-09