Rest actions and custom actions

Rest Actions are data-driven menu entries. The Rest Site subsystem evaluates them and routes execution; Widget Blueprints only display the evaluated model and return user intent.

Native actions

The reserved native Action IDs are:

Action ID	Display purpose	Authoritative route
Rest	Rest at this site	Existing Rest coordinator
FastTravel	Open destination selection	Presenter, then Request Fast Travel with an explicit destination
Save	Save from this Rest Site	Effective Save capability and Save Mode policy

Do not reuse these IDs for unrelated Custom Actions. Labels may be localized or changed without changing routing.

Calling Execute Rest Action with FastTravel directly returns Requires Destination Selection. WSRF never chooses an arbitrary destination — see Fast travel.

Action contract

Each FWSRFRestAction exposes:

Field	Purpose
Action ID	Stable FName used for routing; not derived from the label
Display Name	Localizable player-facing FText
Description	Optional localizable FText for custom presentation
Icon	Optional soft Texture2D reference
Order	Primary deterministic sort value
Enabled	Authored availability switch
Required Tags	Gameplay Tag Query that must pass
Blocked Tags	Gameplay Tag Query that must not pass
Close Menu After Execute	Whether a completed action asks the Rest Menu to close
When Unavailable	Keep the row Disabled or make it Hidden

The computed presentation row additionally contains bCanExecute, bVisible, Disabled Reason, Evaluation Status, and Execution Kind: Native Rest, Native Fast Travel, Native Save, or Custom.

Effective capability gates

Evaluate Rest Action applies the complete effective Rest Site configuration:

• Save requires Save Enabled and a Save Mode other than Disabled.
• Fast Travel requires Fast Travel Enabled.
• Every Custom Action requires Custom Actions Enabled.
• Rest follows the Rest Site’s existing Rest/region configuration.
• Incompatible actions are Busy while another Rest Site operation owns the operation lock.

The same evaluator is used by the menu model and authoritative execution. A custom Widget cannot bypass the rules by calling Execute Rest Action directly.

All automatic save triggers are secondary to Save Enabled:

Save Enabled AND trigger enabled AND Save Mode is not Disabled

Ordering and duplicates

Runtime order is:

1. ascending Order;
2. lexical Action ID as the deterministic tie-break.

Order never depends on TMap iteration. The Details panel provides Up and Down controls that rewrite Order values transactionally.

Empty or duplicate Action IDs are errors and prevent ambiguous execution. Native IDs are reserved. Custom IDs may be any valid project FName, for example:

• Custom.LevelUp
• Custom.Craft
• Custom.Spells
• Custom.SkillTree
• Custom.Storage
• Custom.PassTime
• Custom.Talk
• MyGame.Companion
• MyGame.BurnItem

WSRF does not implement RPG behavior behind these IDs.

Hidden versus Disabled

When Unavailable decides what an unavailable action looks like:

• Hidden removes an unavailable action from the menu model.
• Disabled keeps it visible and focusable, supplies a Disabled Reason, and rejects Confirm without executing gameplay.

The official UI can play the configured Unavailable sound for a Disabled row. Custom widgets receive the already-evaluated state and should not recalculate it.

Gameplay Tag conditions

Required and Blocked Gameplay Tag Queries work without GAS. WSRF aggregates the available tag source and evaluates the query before asking the Project Bridge.

If the project uses a custom tag source, pass it through the advanced Explicit Tag Source pin. When project tags change while the menu is open, call Refresh Rest Site Menu; there is no polling Tick.

Project eligibility

Override Can Execute Rest Action in the configured Project Bridge to apply game-specific rules. It receives:

• Action;
• Rest Site handle;
• local-player index;
• aggregated Gameplay Tags;
• tag-query result and reason.

This hook must be side-effect free. It is used to describe menu availability and to authorize execution.

Custom Action execution

The authoritative flow is:

1. the player requests a Custom Action ID;
2. WSRF performs one authoritative evaluation;
3. WSRF rejects invalid, disabled, tag-blocked, project-denied, or Busy requests;
4. WSRF emits On Custom Rest Action Requested once as a pre-execution notification;
5. WSRF calls Execute Custom Rest Action With Context exactly once;
6. the Project Bridge returns Success or Failure.

The context provides the Action, Rest Site handle, PlayerController, local-player index, and aggregated tags. The legacy Execute Custom Rest Action override remains supported through the default forwarding implementation.

A synchronous re-entry guard prevents a Custom Action callback from executing itself recursively. Long-running custom workflows remain project-owned.

Result meanings

Action evaluation/execution distinguishes:

• Succeeded
• Accepted
• Disabled
• Blocked By Tags
• Denied By Project
• Invalid Action
• Duplicate Action ID
• Unsupported
• Rejected Busy
• Failed
• Requires Destination Selection

Disabled Reason follows the real cause instead of reporting every refusal as a tag failure.

Custom submenus

WSRF does not provide a generic submenu stack. A project can:

1. handle Custom.LevelUp, Custom.Storage, or Custom.Craft in the Project Bridge;
2. open its own Widget Blueprint;
3. leave Close Menu After Execute off to keep the Rest Menu available behind it, or enable it to close;
4. call Refresh Rest Site Menu after project data changes;
5. reopen the Rest Menu through the existing API when the project submenu exits if it was closed.

Profiles and Local Overrides

The action array belongs to the Profile unless Override Actions is enabled. Local Actions then replace the entire inherited array; they are never merged by Action ID.

When actions are Profile-owned, Add Common Actions asks whether to edit the linked Profile or create a Local Actions Override from the effective list. See Profiles and local overrides.

Icon fallback

An explicit valid Icon always wins. If it is empty:

1. native Rest, Fast Travel, and Save use their bundled defaults;
2. known common Custom Action IDs use bundled mappings when the asset exists;
3. any remaining action uses the generic bundled fallback.

An invalid non-null soft path produces a diagnostic and falls back rather than leaving an empty image. Assets are resolved for presentation, not loaded on every navigation input.

Health Check

Rest Site validation reports empty or duplicate IDs, reserved-ID collisions, empty labels, invalid icon paths, incompatible native actions, disabled save/travel/custom capabilities, and hidden local actions beneath a linked Profile. Missing icons are warnings when a fallback exists.