Blueprint key remapping

The current four-tab settings example embeds IFBindingEntry rows directly under IFSettingsMenu, sharing the parent Apply/Cancel session. Follow settings composition for that workflow. The standalone screen below demonstrates the lower-level remapping APIs and owns its own separate transaction; do not nest it inside a shared settings session.

WBP_AshenControls is an IFScreen Blueprint with two InterfaceForge Key Selector controls (keyboard/mouse and controller), an IFActionPrompt, status text and Apply/Cancel/Restore defaults buttons. IFKeySelector is Unreal's InputKeySelector with theme and text-size presentation; it does not own mappings. Developers may use the ordinary engine selector or their own capture interface with the same remapping APIs.

Few-node first-slot recipe

Get IFRemappingSubsystem through Get Local Player Subsystem using the owning player. On On Activated, call Begin Edit and store its Boolean result as OwnsRemapSession. Show Failure Reason if it fails. Editing is allowed only while this screen owns the session.

flowchart LR
    A[Selector: On Key Selected] --> B[Break Input Chord: Key]
    B --> C[Stage Registered Key]
    C --> D{Return Value}
    D -->|False| E[Failure Reason → status text]
    E --> F[Refresh selector from registered preview key]
    D -->|True| G[Has Pending Changes → unsaved status]

Stage Registered Key receives Mapping Name = IFExampleInteract, Family = Keyboard or Gamepad, and Key. It resolves the actual registered slot/hardware identifier. It rejects invalid/analog/incorrect-family keys, reserved navigation keys and conflicting keys under the configured policy. No guessed DefaultKeyboardMouse hardware name is needed. For multiple slots or hardware-specific interfaces, use Get Registered Mapping → Set Members in FMapPlayerKeyArgs → Stage Key Mapping instead.

To refresh: Get Registered Preview Key → Make Input Chord → Set Selected Key. Surround programmatic updates with your RefreshingKeys Boolean; do not stage mappings from the selector's refresh event. The Blueprint example gates On Key Selected while refreshing. Keyboard capture disables gamepad/modifier chords; the controller row permits gamepad capture and validation rejects wrong-family keyboard selections. This example maps single digital keys, not modifier combinations.

Apply calls Apply, branches on its result, then clears ownership and deactivates on success. Failure leaves the draft open. Cancel/Back clears ownership, calls Cancel and deactivates. Event Destruct also cancels an owned abandoned session. Restore defaults calls Stage Registered Default for each displayed family, refreshes selectors and still requires Apply. The IFActionPrompt displays the applied engine mapping, so it changes when Apply rebuilds controls, not while a draft is merely staged.

Key profiles use Unreal's EnhancedInputUserSettings. Enable those settings and register a player-mappable Input Action/Mapping Context before opening controls. The sample registers IFExampleInteract for keyboard E and Gamepad Face Button Left; saved remaps replace those defaults. Gameplay routing stays in the example controller. UI acceptance/back remain the CommonUI input-data actions and reserved keys; the example does not remap its only exit.

UE5.6's engine Save Settings has no returned I/O result. Remapping Apply can report validation/profile/mapping failures; it cannot currently report a disk-save failure through that engine call. Persistence must be verified on target platforms. UI preference Apply separately checks SaveGameToSlot's result. This limitation should remain explicit in a release that uses the stock Enhanced Input saving API.

Evidence boundary

UE5.6.1 build and Blueprint authoring passed, 0 commandlet errors/warnings. Initial compilation repairs addressed a local name shadow and an unexported editor helper method; no engine files changed. First real-RHI opening found a style-lifetime crash: UE5.6's InputKeySelector style setters hand the caller's style address to Slate. IFKeySelector now retains resolved styles as widget-owned fields; rebuilt live opening/reopening/capture passed. Staging G showed an unsaved binding while the applied prompt remained F; Back cancelled it and reopening restored F. Apply G changed the Blueprint HUD prompt; clean restart retained G. The opt-in engine-event fixture resolved the current registered G binding and triggered the actual Enhanced Input SelectNext action (Scout 1 → Scout 2). This is engine integration evidence, not physical-device proof. Packaged BlueprintSlice also captured/applied G and staged default E while the applied prompt stayed G. No physical controller is currently reported by XInput 1.4 (four disconnected slots); this does not enumerate every possible non-XInput/touch device. Physical controller/touch acceptance stays open.

Early native-window G/E pulses did not trigger the gameplay action: diagnostics showed down/up reaching the controller on one frame,2ms apart. The later120ms Slate-event fixture did run after Begin, resolving the persisted G mapping; the controller received down on frame243, Enhanced Input dispatched SelectNext on244, and release arrived on304. Scout1→2 was observed. Input-route evidence records both attempts. This proves that software Slate→viewport→controller→Enhanced Input route at its recorded revision, not physical input or every newer packaged revision.

Current glyph revision: the example opts into original neutral CommonInput face-position art; remap Apply refreshes IFActionPrompt in place, and empty Action Label shows only a glyph/readable key. RPG header keeps the cue visible beside scrolling prose with a.62shared divider. Current29Blueprint source/archive runtime proof is5.6; the newer28-class sample proof above predates it. Glyph authoring recipe and exact runtime/limitations. Physical controller tests remain explicitly deferred.