Goal
This recipe builds an interactable surface with more command rows than should be shown at once. Paging lets the user move through entries while keeping command ids stable.
Author The Surface
- Create a point and active variant with multiple command rows.
- Give every gameplay command a stable
FInteractionRuntimeCommandId. - Add More marker rows where the surface should expose paging.
- Assign input actions to More and Back controls where the user should navigate pages.
- Keep execution actions on gameplay command rows, not on marker rows.
Runtime Behavior
The interactor exposes the current page through the projected surface. UI can call RequestNextCommandPage and RequestPreviousCommandPage or bind the visible control entries. The widget should render page controls as controls, not as gameplay commands.
More marker rows define authored page boundaries, but the runtime filters the projected page set. Pages with no displayable command entries are skipped and are not counted in CurrentPage or TotalPages. If no later displayable page exists, the next-page control is disabled. If no displayable page exists for the surface, paging is cleared and no prompt surface is emitted.
Verification
- The first page shows the expected command rows.
- More moves to the next displayable page without changing target focus.
- Back returns to the previous displayable page.
- Disabled-only or requirement-hidden pages are skipped and do not increase the shown total page count.
- Activating a command on any page activates the correct command id.
- Changing focus clears or resets the page according to runtime surface behavior.
Common Problems
If paging controls show as commands, check row kind. If paging does nothing, check More/Back input actions and interactor paging requests. If the wrong command activates after paging, check duplicated or unstable command ids.
Large Surface Authoring Tips
Group commands by player intent. Put the most common command on the first page. Keep destructive or rare commands away from the same input position as common commands. Use stable command ids so page reorder does not break Blueprint code, save data, or command analytics.
Widget Requirements
The widget should show current page entries, More/Back controls, and command availability per row. Do not render hidden rows as disabled entries unless the projected surface supplies them as unavailable. Page changes should update the displayed row set without losing focus or rebuilding unrelated widget state.
Failure Diagnosis
- More control missing: no marker row, marker hidden by row rules, or no input action.
- Back control missing: page state does not expose a previous page or input is missing.
- Wrong command activates: duplicated ids or widget row mapping is stale.
- Rows disappear after page change: widget is clearing surface state but not rebuilding from the new projection.
Combining Paging With Requirements
Requirements can change which rows are visible or unavailable. Test paging with every relevant requirement state: all commands available, some unavailable, some hidden, and cooldown active. Pages that become empty after disabled-state or hide-policy filtering are skipped, so the displayed page count can shrink or paging can disappear entirely when only one displayable page remains.
Combining Paging With Composite Points
Composite surfaces can gather commands from multiple points. When adding paging to composite surfaces, verify composite order, page order, marker placement, and command id uniqueness. The widget should not assume every row came from the same point.
Command Identity Across Pages
Page position is not command identity. A command should remain identifiable by FInteractionRuntimeCommandId even if a designer reorders rows or changes page size. Blueprint logic, analytics, save data, and execution actions should depend on ids and runtime context, not on visual row number alone.
Authoring Review
- Every gameplay row has a command id.
- Marker rows are used only for paging controls.
- Common commands are reachable without excessive paging.
- Dangerous commands are not placed under the same input as common commands after a page transition.
- Requirement changes do not leave a page with no useful entries.
Testing Requirement States
Test the surface with requirements passing, failing as unavailable, failing as hidden, and with cooldowns active. A surface that pages correctly when all commands are available can still break when rows are hidden or unavailable.
Guarding Terminal Page Changes
If the command that completes a page also disables the last visible entry or makes the active variant leave, use Interaction Action Begin Flow Guard before the state-changing action. The widget can respond to the flow guard start event, play its close transition, and then clear the guard. This avoids a custom widget being left behind after the prompt surface becomes empty.