Blueprint workflows (implementation checkpoint)

These recipes name the current reflected APIs. The standalone playable slice uses saved Blueprint main/pause screens, settings, controls, modal, RTS/RPG HUDs, readouts and a themed virtualized journal. See BLUEPRINT_MENUS_HUD.md, BLUEPRINT_RPG.md, BLUEPRINT_SETTINGS.md, BLUEPRINT_CONTROLS.md, BLUEPRINT_DIALOGS.md, BLUEPRINT_JOURNAL.md, BLUEPRINT_RTS_COMMANDS.md and Blueprint tooltips for exact graphs and runtime evidence; INSTALLATION.md explains setup. Runtime evidence includes controls capture/apply/cancel/defaults, prompt updates and editor-game restart persistence. Physical-device and release gates remain open. No inventory system is required. Game Master's bespoke design stays exclusive; these sample trees/assets are original.

Bring up your interface

Enable InterfaceForge, CommonUI and EnhancedInput. Set Project Settings → Engine → General Settings → Game Viewport Client Class to CommonGameViewportClient. Set Common Input Settings → Input Data to IFNavigationInputData for the quick-start Enter/Escape and generic controller accept/back bindings, or choose your own CommonUIInputData Blueprint. Do not overwrite an existing project's input data without checking its actions.

For focused-button Enter/Space activation, set Common UI Settings → Common Button Accept Key Handling to Trigger Click. Existing projects may still use Ignore; in that mode each button needs a triggering input action instead. The standalone example chooses Trigger Click. Keep CommonUI routing and synthetic controller accept intact. See Epic's accept-key setting and input technical guide.

Create a Widget Blueprint with parent IFScreen. Add your content and focusable CommonUI buttons (IFButton supplies a labeled default). In class defaults choose Input Policy: Menu, Game and UI, or Gameplay. Set Initial Focus to your first enabled control when constructing the widget. Use CommonUI's desired-focus Blueprint override for conditional targets. HUDs that should remain visible disable the inherited Is Back Handler default.

From the owning local PlayerController's BeginPlay:

flowchart LR
    B[Event BeginPlay] --> S[Get Local Player Subsystem: IFLocalPlayerSubsystem]
    S --> R[Create Root: IFRootLayout]
    R --> P[Push Screen: Menu, your WBP, optional Data]

Expected: that local player owns a safe-area layout with HUD/Menu/Modal CommonUI stacks. Push Screen calls Initialize Screen with your Data before activation. In an override, call the parent to retain Screen Data. Deactivate Widget returns through a stack; Go Back closes the top Modal/Menu. Engine Back handling supports the configured input data. Register Layer lets a custom IFRootLayout Blueprint supply its own CommonUI stacks.

Report a completed action

For brief action results, use Get Local Player Subsystem: IFNotificationSubsystem → Post Notification. Pass a Scope and use Dismiss Scope as that flow ends. Replace the passive body through Default Notification Entry Class on your root Blueprint; Blueprint notifications documents coalescing, lifetime, placement and live class/host refresh.

Respond to input once

In any IFScreen implement Event On Input Presentation Updated. Switch on EIFInputPresentation: Pointer, Keyboard, Gamepad, Touch. Change hint visibility, spacing or other presentation. The same event reaches HUD screens behind a modal, but only the top screen owns cursor/focus policy.

For a plain UserWidget use Get Local Player Subsystem: IFInputPresentationSubsystem, Get Input Presentation for the initial value, and bind On Input Presentation Changed in Construct. Unbind in Destruct. No detector is needed per widget. Focus restoration and cursor visibility still belong to the containing screen. The native service does not consume actions. It ignores key repeats, net mouse movement below six pixels within 0.2 seconds, and analog axes below 0.4 until a deliberate threshold crossing. Thresholds are exposed on the subsystem. Ignore Next Pointer Move precedes your own cursor warp. Engine simulated controller accept is recognized.

Expected: fresh keyboard input updates keyboard presentation; meaningful mouse travel/click/wheel updates pointer presentation; a controller press updates CommonInput and navigation presentation immediately. External CommonInput filters/locks and platform support still govern the effective family. Physical controller/touch evidence is pending; the API alone is not a compatibility claim.

Analog Intent Threshold defaults to0.4 and Analog Release Threshold to0.2. A held axis must return below the release threshold before another deliberate crossing can switch presentation, so constant drift/held-stick noise cannot repeatedly reclaim the interface. This extends CommonInput intent detection; it does not replace CommonUI navigation deadzones or consume the axis. Tune these properties on the owning local player's subsystem, not per widget. The platform device mapper's disconnect handler restores that player's last non-gamepad presentation only when its last active gamepad disconnects. Its actual physical behavior remains unverified. The user explicitly deferred hardware checks on2026-10-12 because no controller is available.

The root normally enables observation automatically. If your own flow temporarily calls Set Observation Enabled(false) while retaining screens, later call Set Observation Enabled(true). Re-enabling publishes a changed effective engine family to those existing widgets and updates the top screen's cursor/focus policy. If the family is unchanged, Pointer versus Keyboard is preserved. Input that occurred while disabled cannot be classified retroactively as a pointer/keyboard intent; a newly observed MouseAndKeyboard family uses Pointer until fresh keyboard input arrives. External CommonInput filters/locks remain respected.

Software edge tests operate the actual saved custom screen behind a dialog: subthreshold analog drift, deliberate crossing, held-axis suppression/release, unrelated/active device-mapper disconnect notifications, key repeats, touch start/end, keyboard restoration, observer resume and a caller-owned cursor warp. Device notifications are injected into the engine delegate without changing hardware connection state. Synthetic touch is a Win64 event-routing test, not mobile/touchscreen certification. Exact runtime evidence distinguishes these checks from the explicitly deferred physical tests.

IFActionPrompt resolves the current applied Enhanced Input key and asks CommonInput's configured platform/controller data for its brush. When a brush is unavailable, it shows the key's readable name rather than an empty prompt. Supply your project's CommonInput controller data to obtain device-specific art; the current sample opts into an original four-face-position generic set. Neither synthetic family switching nor a text fallback establishes glyph-art or device certification. See controls/remap recipe.

Show a cancellable dialog

Construct Object from Class → IFDialogData (use the owning screen as Outer). Set Title, Message, Confirm Label and Cancel Label; bind On Completed. Call Push Screen with Modal, IFDialog, and the data object. Switch on result Confirmed/Cancelled.

Expected: the HUD remains underneath a dark scrim. Cancel is initially focused. Escape/right-face Back returns Cancelled exactly once. Returning restores the opener's CommonUI focus. The dialog contains no gameplay operation; your callback decides what confirmation means.

Reusable entries

For a quick entry create a Widget Blueprint with parent IFEntryWidget. Implement On Entry Initialized and cast the data to your own model (or IFPresentationData). Store references to labels/images and set their values in On Entry Refreshed. Implement On Entry Selection Changed for the selected state and On Entry Released to cancel custom asynchronous work and clear external subscriptions/tooltips. The base handles ListView/TileView/TreeView object lifecycle and binds IFPresentationData.OnDataChanged.

For a completely custom UserWidget implement User Object List Entry and IFEntry. Route On List Item Object Set → Initialize Entry, On Item Selection Changed → Set Entry Selected, On Entry Released → Release Entry. You own binding teardown in this path. Never retain a previous model when the entry recycles. Modify a generic model's fields, then call Notify Data Changed once after the group of edits. Do not rebuild the whole list for one row.

When using IFEntryWidget, use its InterfaceForge | Entry hook events; the base already routes the engine list lifecycle. The similarly named UserListEntry → On Entry Released runs after the base clears its context. Use the InterfaceForge hook for cleanup that needs Entry Data, and do not wire both paths. Initialization with None is valid for a static entry; the current lifecycle fix releases that initialized context once even without a model. Journal contracts explain the hooks and current verification scope.

Progress independent of gameplay

For a complete different saved screen/entry with a Blueprint IFDataSource, playable actions, theme controls and a Designer root, follow Blueprint customization. The survey uses the same public contracts rather than a native gameplay controller cast. The outline variants below are additional procedural tools. Sakura's requested center-origin tint has its own independently authored IFCenterTint/M_IFCenterTint implementation and runtime evidence; see CENTER_TINT.md. BLUEPRINT_RPG.md documents the editable action-icon composition in the playable Emberwatch example. Physical-input and final polish gates remain open. Add Forge Progress in a Widget Blueprint. Choose Linear, Radial, Square Perimeter, Segmented or Charges. Set Fraction clamps a finite value to 0–1 and stops a previous cooldown. Start Cooldown accepts seconds and uses an absolute game-time endpoint. A zero duration completes immediately. Get Remaining Seconds and Get Displayed Fraction supply countdown labels. Game time pauses with the world. Reverse and Start Offset control fill direction/origin; square zero starts top-left and radial zero starts top. Segments controls both segmented and charge presentations. These native procedural styles do not require a backend or material. Material variants and visual corner refinements remain pending.