Change Keys and Gamepad Bindings

CalmUI provides mouse movement and clicks, wheel events, arrows, Tab/Shift+Tab, Enter/Space/Escape, D-pad and left-stick navigation, and all four gamepad face buttons: bottom = Accept, right = Back, left (X / □) = Secondary and top (Y / △) = Tertiary. Secondary and Tertiary have no keyboard default; bind a chord such as Enter + Shift / Enter + Alt in the profile asset or through Rebind CalmUI Input if keyboard players need them (see Secondary and tertiary). Left-stick directions resolve through the active D-pad bindings, with a dead zone and delayed repeat. Rebinding a D-pad key also changes its corresponding stick direction. Held directions repeat on the UI frame tick even when the host sends analog events only when the value changes. Releasing the stick or losing UI input ownership clears the held direction.

Set different defaults

1. In Unreal, create a Data Asset using Calm Ui Input Profile (UCalmUiInputProfile).
2. Set the keyboard/mouse and gamepad bindings in that asset.
3. Assign it in Project Settings → Plugins → CalmUI → Input Profile.
4. Run the game and test the controls.

Input Mapping Priority controls how this profile is ordered alongside other Unreal Enhanced Input mappings. Only change it if your game uses competing mappings.

Remap a control from Blueprint

The everyday prompt readers take the local Player Controller directly. Use the advanced Local Player API as Target only for profile editing, rebinding, reset, and change delegates.

For Rebind, choose the action, device, and new key. Handle its result:

• Applied: display the new binding.
• Conflict: ask the player whether to replace the existing assignment, then retry with Replace Conflict enabled if they agree.
• Invalid: keep the previous binding and ask for a valid key.

Changes are saved per profile and local player in GameUserSettings.ini. Resetting one player's profile does not reset another player's bindings.

Update button prompts

Use the GameUI ActionPrompt workflow and OnCalmUiInputPromptsChanged to cover device, binding and culture changes. Get CalmUI Action Prompt reads the navigation profile; Get CalmUI Gameplay Action Prompt reads the player's active Enhanced Input action mappings. OnCalmUiInputMethodChanged remains available for device-only notifications. Use OnCalmUiGamepadConnectionChanged for gamepad connection notifications. Provide your own licensed controller artwork if the game displays button icons.

Text editing is not an input-profile action. Use the game's text-entry controls as explained in Text entry.

Keep gameplay input out of the UI

CalmUI receives navigation through Slate before focus traversal, including when the host uses Unreal's UI-only input mode. Matching navigation presses are consumed only for the owning local player while the game viewport has focus and a CalmUI screen owns input. Pointer and wheel input still use the Player Controller. Two queries on the local player subsystem carry that decision:

• Is CalmUI Blocking Game Input: the focused screen stack uses ui-only or block-below. Switch the game's input model to its UI/modal mode here (and back when it turns false) so attack, camera zoom and the pause toggle stop firing under an inventory or dialog. OnCalmUiInputPolicyChanged fires with the new policy; Get CalmUI Input Policy reads it.
• Is CalmUI Pointer Over UI: the pointer rests on an interactive element (buttons, anything with an event handler) or a container marked data-calmui-interactive="true", or CalmUI holds a pointer capture. Test it before world clicks, hover and wheel zoom on passthrough and game-and-ui screens; mark HUD panels and drawers with the attribute so their body blocks the world too.

Under a passthrough screen CalmUI ignores keyboard and gamepad navigation, Accept and Back so the game keeps them. Navigation is not polled again after Slate delivery. While a screen owns the keyboard, let CalmUI handle Back itself (every screen wires @back) instead of also closing the top screen from the game's UI-cancel action.

For C++ binding-capture workflows, call UCalmUiLocalPlayerSubsystem::SetCalmUiNavigationSuspended(true) when capture starts and pass false on completion, cancellation, or owner teardown. Register the host's Slate capture processor before CalmUI's appended processor and consume captured events there. Suspension alone does not forward UI-only input to a Player Controller. Use HasCalmUiViewportInputFocus(SlateUserIndex) to restrict host capture to the owning user in the active game viewport window; it does not depend on the navigation suspension flag or screen input policy. The gate also accepts that player's focused CalmUI text sink in the viewport overlay, so Tab navigation continues during text entry. Text editing retains character, caret, selection and clipboard handling; Tab and Shift+Tab use the active navigation profile.

Host-owned input modes

By default CalmUI applies the player controller input mode on every screen input-policy change: GameOnly for Passthrough, GameAndUI for the others, plus the cursor and the move/look ignore flags. A host that already drives input from OnCalmUiInputPolicyChanged (its own mapping contexts, capture and lock rules) turns this off in Project Settings -> CalmUI -> Apply host input mode (bApplyHostInputMode=False under [/Script/CalmUiRuntime.CalmUiProjectSettings]). Leaving both active makes them fight: GameOnly puts the viewport into permanent mouse capture, and in that mode the click that re-acquires capture after a screen closes is swallowed before it reaches PlayerInput.

See Who owns the input mode for the query functions (IsCalmUiBlockingGameInput, IsCalmUiPointerOverUi, GetCalmUiInputPolicy) and the data-calmui-interactive overlay marker a host driving its own input modes reads.