Command Identity
A command id names the action the user can activate. The starter command row still needs a valid FInteractionRuntimeCommandId. Use gameplay tag style names that stay stable across releases because command ids appear in prompt entries, UI helpers, activation requests, route identity, save-adjacent state, and Blueprint lookup helpers.
Activation Modes And Patterns
- Interactive commands wait for the assigned input action and runtime validation.
- AutoTrigger commands can activate from resolved availability without explicit user input and ignore multi-participant settings.
- Instant, Hold, and Multi-Tap patterns describe how input progress should be interpreted.
- Hold commands require a positive hold duration. Multi-Tap commands require at least one tap and a positive tap window.
Input Actions
Interactive commands require an input action. More markers require next and back input actions. Multi-participant cancel actions are optional, but without one the generated cooperative cancel control is not available. For command input, create a button-style UInputAction with Value Type set to Boolean, then add it to the runtime interaction input mapping context.
More Markers And Paging
A More marker is a row that pages the prompt surface instead of executing a command. Use More and Back actions when a target exposes more commands than the widget should show at once. The interactor exposes paging requests and the widget receives paging events so the UI can stay in sync.
Paging is resolved from displayable command rows, not raw marker count. If every command between two markers is disabled or hidden, that authored page is skipped. CurrentPage, TotalPages, More, and Back are calculated from the filtered displayable pages.
When a terminal command is expected to disable the final visible command, empty the active page, or leave the currently projected variant, start an interaction flow guard before the state-changing action. The guard lets the widget close on its own event instead of depending on a command row that may already have disappeared.
Prompt Providers
Prompt providers create text and prompt parts for command entries. The default provider can build available and failure text from standard prompt tokens. Custom Blueprint subclasses can override prompt building when a command needs project-specific text, formatting, or contextual parts.
Widget Payloads
Widget payloads travel with the resolved prompt data. A payload can provide a widget class override and apply custom payload data to the widget. Use payloads when a particular target, variant, or command needs a distinct widget presentation without replacing the full UI manager path.
Related Guides
Command Row Deep Dive
FInteractionRuntimeCommandDefinition is the main authoring row for a prompt entry. Row kind decides whether the row is a gameplay command or a paging marker. Activation mode decides whether the row is interactive or automatic. Input pattern decides whether a valid interactive input is instant, hold, or multi-tap. Input actions should match the command’s expected button-style behavior.
Prompt Text And Failure Text
Prompt providers let command text respond to runtime context. Use template tokens when simple text substitution is enough. Use a custom UInteractionRuntimePromptTextProvider when text depends on cooldowns, participants, failures, input family, target id, or project-specific state.
Command Row Validation
- Gameplay command rows need a stable command id.
- Interactive command rows need an input action.
- Hold commands need a positive hold duration.
- Multi-Tap commands need a positive tap count and tap window.
- More marker rows should use paging input rather than gameplay execution actions.
- Automatic commands should not be authored like player-input commands.