Menu UI customization

Replacing the Rest Site menu presentation at three levels — assign widget classes, duplicate the neutral templates, or build from the WSRF widget contract — plus input prompts and the presenter seam.

WSRF ships with official Rest Menu, Fast Travel, and destination-row Widget Blueprints. They remain the automatic fallback and are ready to use. Projects can replace any of the three presentation classes without changing WSRF gameplay code.

UI class resolution follows the same rule as the rest of the Rest Site presentation system:

Project Settings -> Rest Site Profile -> Local UI Override

The local override is the existing Override UI Widget Classes group. It replaces the three UI class values together; no serialized property was renamed.

Level 1 — assign Widget Classes

Use the official widgets as supplied, or select project Widget Blueprints in:

  • Rest Menu Widget Class
  • Fast Travel Widget Class
  • Fast Travel Destination Row Widget Class

Project Settings provide the global defaults. A Rest Site Profile can select shared classes for many sites. A local UI override can select classes for one site.

If a selected class is missing or does not derive from the required WSRF widget contract, WSRF reports a clear diagnostic and uses the corresponding official Widget Blueprint. It does not fall back to a raw C++ layout.

Level 2 — duplicate the neutral templates

The templates under /WorldStateResetFramework/RestSites/UI/Templates are intentionally neutral and are never assigned automatically:

  • WBP_WSRF_RestMenu_Template
  • WBP_WSRF_FastTravel_Template
  • WBP_WSRF_FastTravelDestinationRow_Template

Duplicate the required template into the project Content folder, rename it, edit its UMG hierarchy, then assign the duplicated class in Project Settings or a Rest Site Profile. The official showcase widgets and Demo remain unchanged.

Level 3 — create a UI from the WSRF contract

Create a Widget Blueprint derived from the matching WSRF base class:

SurfaceParent classData supplied by WSRFBlueprint requests
Rest MenuWSRFRestSiteMenuWidgettitle, evaluated actions, icons, availability, disabled reasons, input family and promptsRequest Rest Site Menu Action, Request Rest Site Menu Back
Fast TravelWSRFFastTravelViewWidgetdestinations, region, thumbnail, current/available state, disabled reason, input family and promptsRequest Destination Selection By Handle, Request Destination Travel By Handle, Request Back To Rest Menu
Destination RowWSRFFastTravelDestinationRowWidgetone evaluated destination rowRequest Destination Selection, Request Destination Travel

The widget is presentation only

The widget receives already-evaluated presentation data. It must not search the World, inspect the registry, decide travel availability, or manipulate snapshots and persistence.

Example: a project Fast Travel view

  1. Duplicate WBP_WSRF_FastTravel_Template as /Game/UI/WBP_MyGame_FastTravel.
  2. In Fast Travel Model Changed, call Get Fast Travel Destinations and build the visual list.
  3. Display each row’s Display Name, Region, Thumbnail, bIsCurrent, bCanTravel, and Disabled Reason.
  4. When focus changes, call Request Destination Selection By Handle.
  5. On Confirm, call Request Destination Travel By Handle. On Back, call Request Back To Rest Menu; this returns to the Rest Menu instead of closing the Rest Site session.
  6. Assign WBP_MyGame_FastTravel to Fast Travel Widget Class in Project Settings, a shared Profile, or one site’s local UI override.

For a completely custom row, duplicate WBP_WSRF_FastTravelDestinationRow_Template, assign it to Fast Travel Destination Row Widget Class, and use Destination Row Changed to refresh its visuals.

The view model contract

The evaluated menu row is the Blueprint presentation contract (the action list itself is covered in Rest Menu Actions). It contains the authored Action, optional Description, resolved icon, availability, disabled reason, evaluation status, and computed Execution Kind (Native Rest, Native Fast Travel, Native Save, or Custom). Custom widgets should never compare reserved Action ID strings to rediscover the native route.

Native actions remain authoritative:

  • Rest runs the Rest coordinator.
  • Save follows the effective Save capability and configured Save Mode.
  • FastTravel opens destination selection. Calling Execute Rest Action with FastTravel directly returns Requires Destination Selection; it never chooses a destination arbitrarily. Travel begins only through Request Fast Travel with an explicit destination.

For a custom ID such as Custom.LevelUp, WSRF evaluates the effective capabilities, tag queries, operation busy state, and Can Execute Rest Action Project Bridge hook. If allowed, Execute Custom Rest Action With Context is the single authoritative gameplay callback. Its context includes the action, Rest Site, local-player index, aggregated tags, and PlayerController. The legacy Execute Custom Rest Action override remains supported through the default forwarding implementation.

On Custom Rest Action Requested is notification-only. Do not execute gameplay from that multicast event, or the action may be handled twice.

Refresh after project state changes

There is no polling Tick. If a custom action changes tags, currency, inventory, quest state, or another condition while the Rest Menu remains open, call Refresh Rest Site Menu after the project data is ready. WSRF rebuilds the existing Presenter model and sends the normal refresh callback.

Project-owned submenus

WSRF does not own Level Up, Storage, Crafting, or their navigation stacks. A typical Blueprint flow is:

  1. Handle Custom.LevelUp, Custom.Storage, or Custom.Craft in the Project Bridge.
  2. Open the project’s Widget Blueprint.
  3. Leave Close Menu After Execute disabled to keep the Rest Menu open behind the project UI, or enable it to close the Rest Menu.
  4. When the project submenu closes, refresh the still-open Rest Menu, or reopen it with the existing Rest Site menu API.

Custom action callbacks are synchronous in WSRF 1.0. Long-running project flows remain project-owned; WSRF only guards the synchronous dispatch against re-entry.

Input prompts

Both public menu contracts expose the current prompt family and the resolved Confirm/Back glyphs and labels. Missing glyphs are valid: custom widgets should render a text-only fallback. Device presentation never changes Rest Site gameplay rules.

Asset loading and fallback

WSRF resolves the selected soft classes when the menu opens, not on every navigation event. Invalid project classes produce a diagnostic and fall back to the official current WSRF Widget Blueprint for that surface.

Replacing the presenter

Widget classes cover normal visual customization. For an advanced presenter implementation, replace Menu Presenter Class (default WSRFRestSiteUMGPresenter) in Project Settings — it opens and coordinates the Rest Site UI.

Editing actions inherited from a Profile

When a linked Profile is authoritative and Override Actions is off, Add Common Actions asks for an explicit choice:

  • Edit Linked Profile opens the shared asset; or
  • Create Local Actions Override copies the current effective list, enables the local override, and adds the chosen action in one transaction.

WSRF never writes a hidden local action that has no effect, and it never edits a linked Profile silently from an Actor. The Details panel also provides Up and Down controls; each move rewrites deterministic Order values. Runtime ties remain deterministic by Action ID.

Destination thumbnails shown by the Fast Travel view come from the thumbnail workflow. For the module as a whole, see the Bonfire & Checkpoint overview.

Last updated: 2026-09-04

Type to search titles, sections and keywords.