Skip to content

showdebug enhancedinput and Input Debugging

At a glance

Run in: the PIE or Development-build console for the exact player viewport you are testing - Command: showdebug enhancedinput - Shows: the selected debug target's runtime Enhanced Input mappings, actions, values, trigger state, and related modifier/override information, with layout varying by engine version - Returns: no Blueprint value; it draws a debug overlay - Cannot prove: that the intended Blueprint instance handled an event or that downstream movement, UI, RPC, or replication succeeded - Can appear to fail by: targeting the wrong PIE window/player, using the wrong debug target, opening no console, or testing a Shipping build that strips development console/debug facilities - Official docs: Enhanced Input, Console Commands, and UEnhancedInputLocalPlayerSubsystem

The one-minute version

  • Start PIE, focus the player viewport, open its console, and enter showdebug enhancedinput.
  • First read the overlay header. Confirm the selected pawn/controller/player belongs to the exact local player and PIE window whose key you are pressing.
  • The overlay can expose runtime context/mapping rows, action state and value, elapsed trigger information, modifiers, and mappings overridden by another context. Exact labels vary by engine version.
  • It is a player-input evaluation view, not a Blueprint execution trace. If IA_Move shows Triggered with the right value, put a breakpoint on the action event in the intended Blueprint instance next.
  • The overlay does not consistently show numeric context priority. Query the local player's Enhanced Input subsystem with Has Mapping Context and its found-priority output, or log priority where contexts are added.
  • UI Only mode, focused widgets, pause, consumption, possession, and input stack ownership can still block the route around an otherwise valid mapping.
  • In multi-client PIE, run and read the command in each client window separately. The host's local input proves nothing about a remote client.
  • Shipping builds strip console commands and debugging tools that are not for end users. Treat this overlay as a development diagnostic, not a shipped support feature.

Run the overlay

In Play In Editor:

1. Start PIE.
2. Click the player viewport or PIE window you intend to test.
3. Open the PIE console, normally with the project's configured console key.
4. Enter: showdebug enhancedinput
5. Close the console and exercise one input at a time.

Enter the same command again to toggle that debug category off. If your project remapped or disabled the usual console key, use the editor's console entry or the project's configured route rather than assuming one keyboard layout.

The overlay may offer target-cycling keys in its header. Follow the keys shown by that engine build, and stop when the named debug target/player matches the instance you intend to inspect.

The first line is part of the test result. Record:

PIE window/client:
selected debug pawn:
selected controller/player:
physical device and key:
expected Input Mapping Context:
expected Input Action:

Without that identity, a correct-looking overlay can belong to the wrong local player.

What the overlay can reveal

Epic documents the command as the runtime view for a project's action and axis mapping information. In current Enhanced Input builds, that view can include:

Overlay evidence What it helps prove
Selected debug target/player Which local runtime input owner the view is describing.
Context sections Which runtime-applied contexts contributed mappings for that player.
Action rows Which Input Actions are represented by those mappings.
Trigger event/state Whether an action is None, Ongoing, Triggered, or otherwise transitioning.
Action value and time Whether the final bool/axis value and active duration resemble the input you expect.
Key/axis rows Which physical mappings feed the action.
Modifier visualization How supported modifiers, such as Dead Zone, reshape the value.
Override text Which higher-precedence mapping displaced a competing mapping.

The layout is a diagnostic implementation detail, not a serialized API. Fields and formatting can move between engine versions. Make claims from what your overlay actually prints, and use subsystem/Blueprint queries for facts the current overlay omits.

For example:

overlay shows:
    IA_Move = Triggered
    value = (0, 1)

this proves:
    this selected player's Enhanced Input evaluation produced forward intent

this does not prove:
    the intended Character event ran
    Add Movement Input targeted this pawn
    Character Movement accepted the request
    a server RPC arrived

What still needs the Blueprint debugger

Use an instance-specific breakpoint when the question is "did my graph run?"

1. Open the Blueprint that should own the Input Action event.
2. While PIE is running, choose the exact runtime instance in Debug Object.
3. Put a breakpoint on the action event or first downstream function.
4. Press the input in the matching PIE window.
5. Inspect Action Value, Controller, Pawn, and branch conditions.

The Blueprint debugger proves things the overlay cannot:

  • which Blueprint instance received the event;
  • which execution pin fired;
  • what typed value the graph extracted;
  • whether a branch, gate, validity check, or interface call stopped execution;
  • which pawn/component/object became a function target;
  • whether a client attempted an RPC or local-only effect.

If the overlay shows the action Triggered but the breakpoint never hits, focus on binding and input-stack ownership. If the breakpoint hits with the right value, stop editing mappings and move downstream.

See Breakpoints and watch values for selecting the live instance and reading execution flow.

Contexts, priorities, and overrides

Context presence and context priority are separate facts. A context can be applied and still lose a key collision to a higher-priority context.

The overlay can list contexts and mark mappings as overridden. It does not guarantee that every engine version prints each context's numeric priority. For an exact check:

owning PlayerController
-> Get Local Player
-> Get Enhanced Input Local Player Subsystem
-> Has Mapping Context(IMC_Expected)
-> record Return Value and Found Priority

Also log the context asset and priority at every Add/Remove Mapping Context call during the failing transition:

Add IMC_Default priority 0
Open inventory
Add IMC_Inventory priority 50
Close inventory
Remove IMC_Inventory

When the overlay reports an override, inspect both actions' Consume Lower Priority Enhanced Input Mappings settings as well as context priorities. Priority determines evaluation precedence; consumption determines whether a lower-priority mapping sharing that input can continue.

Do not fix a collision by repeatedly adding the default context or assigning every context a huge number. The concrete cost is an untraceable lifecycle and new collisions during menus, vehicles, dialogue, and respawn. Give temporary contexts paired add/remove paths and log those transitions.

Action values, modifiers, and trigger states

Read the overlay from left to right as a pipeline:

physical key/axis
-> mapping and modifiers
-> final typed action value
-> trigger evaluation
-> Input Action event

Use the symptom to choose the next boundary:

Observation Next check
Key row is absent Wrong context, stale mappings, wrong local player, or wrong key asset.
Key row exists but final value is zero Device value, Dead Zone, Scalar, Swizzle, action value type, or pause/input routing.
Value is correct but state stays Ongoing Hold/timing requirement or another explicit/implicit/blocker trigger.
State reaches Triggered but Blueprint breakpoint misses Wrong binding owner/instance or input component stack.
Blueprint breakpoint hits but behavior is absent Downstream movement, gameplay state, target reference, authority, or replication.

For an Axis2D action, verify X and Y independently. A correct magnitude with swapped components is a modifier problem, not a trigger problem. A nonzero raw stick that becomes zero after Dead Zone is a tuning result, not missing input.

See Enhanced Input modifiers and Input Action values for those two contracts.

Possession and input-stack ownership

Enhanced Input can evaluate an action for a local PlayerController while the gameplay object you expected is not receiving it.

For a Character-owned binding, prove:

PlayerController Get Pawn == Character instance under test
Character Get Controller == that PlayerController
Character Is Locally Controlled == true on the input-owning client
Blueprint Debug Object == that same Character instance

Respawn creates a new pawn instance. A mapping context stored on the local player can remain active while the old pawn's binding disappears. Conversely, a PlayerController binding can continue firing while downstream code still references the destroyed pawn.

Actors using Enable Input join a PlayerController input stack. A higher input component or a consumed binding can prevent a lower one from seeing the same input. The overlay can prove action evaluation for the player, but use breakpoints and Enable/Disable Input to prove which Actor input component handled it.

Local players and multiple PIE windows

Enhanced Input's normal player subsystem is per local player. In split-screen or multi-client PIE, "the context is active" is incomplete; the full statement is "the context is active on Local Player N in this world/window."

Use this test discipline:

  1. Give each PIE window a visible client label.
  2. Click Client 1, run the overlay there, and record its selected player.
  3. Press one input only in Client 1 and capture the action result.
  4. Repeat independently in Client 2.
  5. On the server, inspect the RPC or replicated result, not raw remote-client keyboard input.

Separate-process PIE gives each client its own process and console. In a shared-process PIE setup, viewport focus and debug-target selection still decide which local world/player you are observing. Do not rely on Get Player Controller 0 when the owning PlayerController or widget Owning Player is already available.

The listen-server host is a special case: it is both the server and a local player. A host action firing does not prove a remote client's local subsystem or input path is configured.

UI input mode and focus

An Enhanced Input context can be correct while viewport/UI routing sends the key elsewhere.

Check these separately:

State Question
Input Mode Game Only / Game and UI / UI Only Is gameplay input intended to receive keys in this mode?
Focused widget Which widget owns keyboard/controller focus?
Widget event handling Did the focused widget handle/consume the key?
Menu Mapping Context Was it added at the intended priority and removed on close?
Cursor/capture Does mouse capture match the current mode?

In UI Only mode, a gameplay Input Action event going quiet can be expected. Put a breakpoint on the focused widget's key/navigation handler and on the gameplay action event to find the route. In Game and UI, UI gets an opportunity to handle input before the PlayerController path, so consumption still matters.

Menu exit should restore all paired state: remove the menu context, restore input mode, focus the viewport as needed, restore cursor/capture, and unpause if the menu paused the game. See Set Input Mode and Show Mouse Cursor.

Pause

Pause adds another independent gate. An Input Action asset has Trigger When Paused; without it, the action is not expected to trigger during game pause.

For a pause-menu close action:

IA_Pause:
    Trigger When Paused = true

open:
    add menu context
    set UI input mode/focus
    pause game

close:
    action or focused widget receives input while paused
    unpause game
    remove menu context
    restore gameplay input mode

Do not confuse game pause with a Blueprint breakpoint pausing execution. The latter freezes the debugged world so you can inspect it; action timers and input evaluation will not progress normally while execution is suspended.

Stale control mappings

The local subsystem builds runtime control mappings from applied contexts. Supported add/remove and player-mappable operations request rebuilds, normally for the end of the frame. During editor iteration or custom runtime mutation, the asset you are looking at and the player's built mapping list can diverge.

Symptoms include:

  • the overlay still shows an old key after a Mapping Context edit;
  • a newly added modifier is absent from the runtime visualization;
  • one PIE player has rebuilt while another local player has not;
  • a binding works only after restarting PIE.

Use a bounded recovery path:

1. Stop PIE and save the Input Action/Mapping Context assets.
2. Restart PIE and verify the overlay again.
3. For a deliberate runtime mapping change, call the supported
   Request Rebuild Control Mappings path on the affected subsystem, or
   Request Rebuild Control Mappings Using Context for every subsystem using
   that context.
4. Observe OnControlMappingsRebuilt before testing the new mapping.

Rebuilds apply at the end of the frame by default. Force Immediately makes the rebuild synchronous, but forcing each of several context changes individually has a performance cost. Batch the intended changes and use the default unless same-frame availability is a real requirement.

Do not use Clear All Mappings as a generic refresh. It removes valid contexts and turns one stale-mapping question into a lifecycle reset.

Isolate device input with injection

When the mapping looks correct but a physical device is suspect, Enhanced Input's development console can inject a known key value:

Input.+key Gamepad_Left2D X=0.7 Y=0.5
Input.-key Gamepad_Left2D

Use the exact internal key name shown by Unreal's key picker. Always send the matching Input.-key command so the simulated key does not remain active.

Interpret the result narrowly:

injected value reaches IA_Move
-> mapping/modifier/trigger path can process that key
-> physical device or device routing remains suspect

injected value also fails
-> stay in context/mapping/modifier/trigger/local-player diagnosis

Injection does not prove the hardware works, and it does not prove the downstream Blueprint binding. It is one controlled input to the same ladder. showdebug devices is another complementary device-oriented command in Epic's Enhanced Input guide.

Shipping-build limits

Unreal's Shipping configuration strips console commands, stats, and profiling tools that are not intended for end users. Do not design a support procedure that requires players to run showdebug enhancedinput in a normal Shipping build.

For shipped diagnostics, build a deliberate surface appropriate to the game:

  • gated development or QA builds with the overlay available;
  • structured logs for context transitions and control-mapping rebuilds;
  • a support screen that reports active control scheme and bound keys without exposing arbitrary console execution;
  • telemetry around input mode, possession, and rejected server requests where privacy and product policy permit it.

Do not re-enable a broad command console in Shipping just to recover one debug overlay. The concrete cost is exposing commands and state that Shipping strips for security, integrity, and product reasons.

The repeatable debug ladder

Run the ladder in order and stop at the first failed proof:

1. Correct window
   Focus and label the exact PIE client/local player.

2. Correct runtime owner
   Confirm selected controller, local player, pawn, and Debug Object instance.

3. Correct context
   Has Mapping Context is true; record Found Priority.

4. Correct physical mapping
   Overlay shows the expected key/axis feeding the exact Input Action.

5. Correct modified value
   Verify value type, components, Dead Zone/Scalar/Swizzle result.

6. Correct trigger state
   Exercise press, hold, release, and cancellation; observe state transitions.

7. Correct routing gates
   Check context override/consumption, input mode, widget focus, and pause.

8. Correct binding instance
   Breakpoint hits on the intended pawn/controller/actor.

9. Correct gameplay consumer
   Downstream target, movement/component state, branch, and authority are valid.

10. Correct network result
    Owning client sends the request; server validates; replicated state returns.

This order prevents a common debugging loop: changing Mapping Contexts when the action already triggers, then changing movement when the event never reaches the possessed pawn.

Lookalikes - which one do I want?

Tool Use when Not the same as
showdebug enhancedinput Inspect one selected player's runtime Enhanced Input mappings, values, and trigger state. A Blueprint execution trace or Shipping support UI.
Blueprint breakpoint/watch Prove a particular graph instance and branch executed. A complete view of active contexts and mapping overrides.
showdebug devices Inspect device-oriented debug information. Proof that an Input Action binding ran.
Input.+key / Input.-key Inject a controlled input value during development. A physical hardware test.
Print String / Output Log Record owner identities, priorities, context transitions, and downstream state over time. A live mapping visualization.
Has Mapping Context Query one subsystem for context presence and exact found priority. Proof that a mapped action actuated.
Request Rebuild Control Mappings Reapply runtime mappings after a supported change. Adding a missing context or binding an action event.

Going deeper