Death and respawn

WSRF does not detect Player Death. Your game decides when death occurred, applies its game-specific consequences, then asks WSRF to return the player to a checkpoint.

Normal Blueprint workflow

1. Project detects Player Death.
2. Apply project-owned death rules when appropriate.
3. Call Respawn At Last Rest Site.
4. Optionally present a fade through the Respawn lifecycle events.
5. Restore project-owned Health or other gameplay state.

For a targeted revive, call Respawn At Rest Site with an explicit Activated Rest Site handle.

Destination semantics

• Last Activated Rest Site is the persistent checkpoint selected by Activation or successful configured travel.
• Current Rest Site is the transient runtime view and is reconstructed from Last Activated Rest Site after load.
• A normal reset does not deactivate Rest Sites.

If no Rest Site has ever been Activated, Respawn At Last Rest Site returns an immediate explicit rejection. WSRF does not invent a checkpoint or teleport to World Origin.

Placement points

Respawn always uses the destination’s Player Respawn Point for:

• World Partition streaming preparation;
• final Pawn position;
• Pawn rotation;
• Controller rotation.

The Fast Travel Arrival Point is separate and is never substituted for Respawn. Select each helper component in the Actor’s Components tree to position and rotate it independently.

Older sites without an explicit helper may retain a documented component-transform fallback for compatibility; use Health Check to remove that ambiguity from production content.

Same-world respawn

WSRF validates the operation, waits at the configured transition barrier, prepares the destination, resets the configured region with the Player Death reason when enabled, places the Pawn, and completes exactly once. The region is restored before the player stands in it.

Cross-world respawn

WSRF stores only pure pending data across Open Level. After the destination world loads it:

1. verifies World Identity and configured redirects;
2. applies the destination world’s compatible WSRF snapshot;
3. re-resolves the exact live Rest Site;
4. prepares streaming;
5. performs the Player Death region reset when enabled;
6. places and rotates the player at the Player Respawn Point;
7. completes exactly once.

No Actor, Pawn, Controller, or World pointer is serialized across travel.

Transition and project presentation

Transition modes are Immediate, Next Frame, and Manual Continue.

For a custom death screen:

1. bind On Respawn Started;
2. start the project’s fade, montage, sound, or loading presentation;
3. call Continue Respawn Transition with the operation ID when Manual Continue is ready;
4. finish project presentation from On Respawn Completed.

Failure fallback

Accepted same-world and cross-world failures use the same Handle Travel Failure Project Bridge contract. The project may place the player at a game-specific fallback. WSRF guarantees a single final result and does not call fallback twice.

Pre-acceptance rejection, including “no Last Activated Rest Site,” remains an immediate ticket result so Blueprint can choose its own title-screen, PlayerStart, or other policy explicitly.

Re-entry

Only one Rest Site operation is active. A second Respawn, Rest, Fast Travel, or Quick Load request is rejected as Busy while the operation is in progress.

Project-owned responsibilities

WSRF does not own:

• death detection;
• Health restore or revive rules;
• Inventory consequences;
• Currency or experience loss;
• soul-recovery mechanics;
• death animation or mandatory fade.

Use On Respawn Started, On Respawn Completed, Project Bridge hooks, and your normal Blueprint systems to implement them.

Note that loading a save is not a death: the Quick Load and project-save workflows never issue the Player Death reset or apply death penalties. For the module as a whole, see the Bonfire & Checkpoint overview.