Bonfire & Checkpoint (Rest Sites)

WSRF 1.0 includes a Rest Site module — commercially, the Bonfire & Checkpoint system. The whole workflow:

Place any Actor. Right-click → Make Rest Site. Done.

This page is the overview. Each subsystem has its own page — see Going deeper for the full map.

Make Rest Site — one right-click

Select your bonfire, shrine, statue, lantern or terminal placed in the level and right-click:

Right Click
└─ World State Reset Framework
   └─ Make Rest Site

A small chooser asks for a built-in preset, an existing Rest Site to copy, or a saved profile — then one undoable transaction does the entire setup: the WSRF State Component and the Rest Site Component, Persistent configuration with a Stable ID, an explicit region, the Player Respawn and Fast Travel Arrival anchors pre-placed in front of the Actor, the Editor-only Thumbnail Capture View auto-framed from the Actor’s bounds, and the selected action configuration.

One Undo reverts everything. The behavior belongs to the placed instance, never to the mesh asset — the same mesh can stay scenery elsewhere, or be two different bonfires in two maps. Every anchor and the camera stay ordinary components you move with the normal gizmos. Automatic first → adjustable after.

The full step-by-step — identity, region, placement helpers, testing in PIE — is the Rest Site quick start.

The rest menu, at a glance

A Rest Site owns an editable action list. Native entries are handled by the module; everything else is routed to your project as an event:

Refilling potions, restoring health or advancing time of day are not menu entries — they are Project Rest Effects: the hook your project implements, executed during the rest sequence before the persistent capture, so refilled values are exactly what gets saved. The module never implements level-up, crafting or healing itself; it raises the event, your game answers.

Actions sort by Order, then lexically by ID; duplicate or empty IDs fail validation. Each action carries required/blocked Gameplay Tag Queries — no GAS needed — and the Project Bridge configured in Project Settings has the final word on eligibility. The full contract — capability gates, Hidden versus Disabled, dispatch and result meanings — is on Rest actions and custom actions.

Two workflows, one implementation

• AWSRFRestSite — a ready-to-place Actor: root, replaceable presentation mesh, a WSRF State Component configured persistent, the Rest Site Component, Player Respawn and Fast Travel Arrival arrow anchors, and an Editor-only Thumbnail Capture View camera provably absent from Shipping builds.
• UWSRFRestSiteComponent — the single owner of all Rest Site logic. Add it to a shrine, bonfire, statue, lantern or terminal your project already has.

The Actor delegates everything to the component and the subsystems, so both workflows behave identically. A Rest Site is identified by its existing WSRF Stable ID scoped by effective/container identity — no second ID system, and two copies of the same Level Instance keep independent state automatically.

Checkpoint states

States only move forward. Repeated calls return AlreadyInState without re-firing events, and stale data can never downgrade an activated bonfire. Discovery and activation modes, the authoritative activation order, save coalescing and the events are documented on Discovery and activation.

Presets

Apply Rest Site Preset configures a role in one click and everything stays editable afterwards. Registration requires a UWSRFStateComponent with an authored Stable ID; a site without one is refused with an actionable error rather than silently given a hidden identity. The initial action list each preset creates is tabulated in the quick start.

Rest Site Profiles — configure once, reuse everywhere

Configure your first bonfire, then click Save Setup as New Profile… — the setup becomes a project-owned Data Asset. Every next bonfire is Make Rest Site → your profile. Linked Profile (the default) keeps a live link — edit the profile later and every linked site follows, with no map edits; Copy Once makes the site independent; explicit Local Override groups let one site diverge — the Boss Arena bonfire follows the standard profile but disables Fast Travel.

A profile carries only reusable configuration. It never contains the Stable ID, Display Name, Region, thumbnail, anchor positions or Discovered/Activated state: each Rest Site remains a unique checkpoint. A broken profile reference is a Health Check error, never a silent fallback. The resolution order and the seven override groups are on Profiles and local overrides.

Fast travel and player respawn

Same world — Request Same World Fast Travel: only Activated destinations are executable (Discovered ones can be shown locked), and streamed destinations are loaded through a temporary World Partition streaming source with a timeout — never a blind teleport.

Cross world — Request Fast Travel: the source world’s snapshot is captured into the multi-world registry, a pure-data pending operation survives OpenLevel, and the player is placed at the exact Rest Site’s Arrival Point in the destination world. Both flows are detailed on Fast travel.

Respawn — the module never detects death; your project decides and calls Respawn At Last Rest Site. The sequence ends with a WSRF.Reset.PlayerDeath region reset before the player is placed at the Respawn Point — the world is restored before you stand in it. The player is never teleported to (0,0,0). See Death and respawn.

Every operation is exclusive (RejectedBusy while another runs), carries a timeout, and completes exactly once with a structured result.

The default menu UI — replaceable by design

The module ships a neutral, fully functional rest menu: mouse, keyboard and gamepad navigation, soft-loaded icons and thumbnails, disabled reasons displayed. No CommonUI, no Enhanced Input, no GAS. Replacement is two-level: swap the Widget classes in Project Settings, or replace the entire Presenter — the UMG-free seam that receives a pure, pre-evaluated view model. See Rest Site UI customization.

Editor tooling and thumbnails

• Health Check — a pure analysis of the selected site with plain-language findings and explicit one-click safe fixes.
• Preview Menu — see the resolved menu in the editor, without PIE, without touching anything.
• Viewport visualizer — lines from the site to its Respawn, Arrival and camera anchors.
• Capture Thumbnail — photographs the actual level from the site’s camera into a project Texture2D with a deterministic name (T_RS_<World>_<Id>_Thumbnail). Explicit button only; a manually assigned image is never replaced silently. See Thumbnails.

Nothing of the capture pipeline exists in a Shipping build — proven by automated checks on every package.

The rest sequence

An accepted Rest is a locked, correlated operation with exactly one completion report:

1. Validate — site, player, region, WSRF idle
2. Lock the operation and activate the site
3. On Rest Started your fade, animation or camera move hooks in here
4. Transition barrier Immediate, Next Frame or Manual Continue — always with a timeout
5. Reset Region — WSRF.Reset.Rest enemies return, the Boss stays dead
6. Project Rest Effects refill flasks, heal, advance time — before anything is saved
7. Capture persistent WSRF state so the refilled values are exactly what gets saved
8. Save — per configured mode
9. On Rest Completed — structured result, exactly once

A second Rest while one is active returns RejectedBusy; a Rest requested while a WSRF Core reset is running is refused rather than queued. A partial region reset continues by default and completes as SucceededWithWarnings with the full WSRF report attached — the advanced Abort On Reset Failure setting turns that into a stop. Failed rest effects stop before capture; a failed save reports failure at the save phase without pretending the world reset didn’t happen.

Multi-world Quick Save

One WSRF world snapshot per world, the discovered/activated Rest Site descriptors and the Last Activated Rest Site per local player — nothing else. No inventory, health, resource schema, arbitrary blob or project object ever enters it. Four save modes — Disabled, WSRF Quick Save, Project Save and Both — and with your own SaveGame, Build Rest Site Save Data hands you the pure-data envelope to store as a property. Migration, quarantine of future-version snapshots and the world-identity redirects are covered on SaveGame integration.

Architecture and Core safety

The module ships as separate plugin modules (WorldStateResetFrameworkRestSites, a UI module and an Editor module) on top of the WSRF Core Runtime. The only Core change made for it is one additive, read-only function — Get WSRF World Identity. A project that only uses Reset World Region configures no Rest Site, no save and no UI, and sees no behavioral change.

Going deeper

Page	Covers
Rest Site quick start	Make Rest Site step-by-step, presets, placement helpers, PIE test pass
Profiles and overrides	UWSRFRestSiteProfile, Linked/Copy Once, the seven Local Override groups
Discovery and activation	The state machine, modes, activation order, events
Rest menu actions	Native and custom actions, tag queries, dispatch, results
Fast travel	Same-world and cross-world travel
Death and respawn	Respawn At Last Rest Site and the death reset
SaveGame integration	Save modes, the Quick Save envelope, migration and quarantine
UI customization	Default widgets, the Presenter seam, input handling
Thumbnails	Capture Thumbnail and manual thumbnail assignment
Settings reference	Every Rest Site project setting in one table