Skip to content

Input Action Event and Enhanced Input Action Values

At a glance

Lives in: a Blueprint event graph with the Enhanced Input plugin enabled - Produces: execution pulses for an Input Action's trigger events plus an Input Action Value, Elapsed Seconds, and Triggered Seconds - Value type: Boolean, Axis1D, Axis2D, or Axis3D, chosen on the Input Action asset - Can appear to fail by: having no active mapping, binding on the wrong Blueprint instance, losing possession, reading the wrong value type, or letting context priority, consumption, UI focus, or pause block the path - Official docs: Enhanced Input, UInputAction, FInputActionValue, and FInputActionInstance

The one-minute version

  • An Input Action event is a binding to one Input Action asset. Create the asset first, then right-click in an eligible Blueprint event graph and search for the asset's name.
  • Finding the event in the palette does not mean it will fire. A local player still needs an active Input Mapping Context that maps a key or axis to that action, and the Blueprint instance must be on that player's input path.
  • The action asset's Value Type decides what its value means: Boolean, Axis1D (float), Axis2D (Vector2D), or Axis3D (Vector).
  • Read the matching typed value from the Input Action Value. A wrong-type read has no cast-failed pin; unused components can read as zero, hiding the setup error.
  • Started, Ongoing, Triggered, Completed, and Canceled describe the trigger lifecycle. They are not five names for Pressed and Released.
  • Elapsed Seconds counts how long the action has been evaluating. Triggered Seconds counts time spent in the Triggered state.
  • Keyboard and gamepad input originates on the owning local client. In multiplayer, send the resulting gameplay request to the server when the server must validate or replicate it.

What makes the event appear?

Create an Input Action asset in the Content Browser, for example IA_Move or IA_Interact. In a Character, Pawn, or PlayerController event graph:

right-click empty graph space
-> search for IA_Move
-> choose the Enhanced Input Action event for IA_Move

The event node is generated from the asset. Its output area exposes the five trigger-event execution pins and action-instance data.

If the action cannot be found in search, check:

  1. The Input Action asset exists and is saved.
  2. The Enhanced Input plugin is enabled and the project has been reopened if plugin state changed.
  3. You are searching in an event graph that accepts input events, not inside a function, macro, construction script, or a graph with incompatible context.
  4. Context Sensitive search has not hidden the node because the current Blueprint cannot receive that kind of event.

An active Input Mapping Context is not required merely for the event to appear in the palette. It is required for a physical key or axis to feed the action at runtime.

What makes it fire?

The normal runtime path has four separate links:

flowchart LR
    Device[Local keyboard or gamepad] --> Context[Active mapping context]
    Context --> Action[Input Action evaluation]
    Action --> Binding[Blueprint action event]
    Binding --> Gameplay[Your gameplay logic]

For a possessed Character, a typical setup is:

owning PlayerController
-> Enhanced Input Local Player Subsystem
-> Add Mapping Context(IMC_Default, priority 0)

IA_Move Triggered in the possessed Character
-> Get 2D Axis Value
-> split X and Y
-> Add Movement Input

The Input Action asset does not listen to hardware by itself. The Mapping Context chooses physical inputs, modifiers reshape their raw values, triggers decide the action state, and the event binding invokes your graph.

Likewise, the event has no built-in gameplay side effect. IA_Move does not move a pawn until your graph passes its value to movement logic. IA_Fire does not spawn a projectile until your graph asks for one.

The value type

Set Value Type on the Input Action asset to match the action's meaning:

Input Action value type Blueprint value Good examples
Digital (bool) Boolean Jump, interact, fire, toggle menu.
Axis1D (float) One real number Throttle, trigger pressure, zoom direction.
Axis2D (Vector2D) X and Y Move, look, touch-stick direction.
Axis3D (Vector) X, Y, and Z Motion-controller or genuinely three-axis input.

The event's Action Value pin is an FInputActionValue wrapper. Drag from it and choose the matching typed getter, such as Get 2D Axis Value for an Axis2D action.

IA_Move Triggered
-> Action Value
-> Get 2D Axis Value
-> X = right/left intent
-> Y = forward/back intent

Do not choose Axis3D just because Unreal world movement is 3D. A ground movement stick has two independent inputs, so Axis2D is normally the clearest contract. Your movement graph converts those two values into world-space forward and right directions later.

Wrong-type reads are quiet

FInputActionValue stores one declared value type, but its component access is permissive. Components that the value type does not use are kept at zero, and the native generic getter does not provide a runtime cast-failure branch.

That creates misleading results:

IA_Move is accidentally Digital (bool)
-> Get 2D Axis Value
-> one component may reflect the digital value
-> the unused component is zero
-> graph looks wired, but two-axis movement cannot work correctly

Treat Value Type as part of the asset's public contract:

  1. Open the Input Action asset and verify its Value Type.
  2. Use the getter for that exact type.
  3. Verify each component with a breakpoint or temporary print.
  4. Check that each Mapping Context key can actually contribute the needed axes, including any Negate or Swizzle modifiers.

There is no useful None case to branch on here. A zero value can mean neutral input, a dead zone, the wrong component, or an action that is not currently triggering. Prove the setup instead of treating zero as a single diagnosis.

The five event pins

Pin Meaning Common use
Started Evaluation began this frame. If the action also triggers immediately, Started is reported first. Begin press feedback or perform a simple press-once action.
Ongoing The action is still evaluating but has not met its trigger requirements. Update hold progress while a Hold trigger waits.
Triggered The trigger requirements are satisfied. Depending on the trigger, this can occur once or every active frame. Drive movement/look or commit an action when its trigger succeeds.
Completed An action that reached Triggered has finished. Stop a successful hold or clean up on normal release.
Canceled Evaluation stopped before the action successfully triggered. Abort an early-released hold or interrupted interaction.

For a plain jump button:

IA_Jump Started   -> Jump
IA_Jump Completed -> Stop Jumping

For an Axis2D movement action:

IA_Move Triggered -> read Vector2D -> apply movement input

For a hold interaction:

Started   -> show progress
Ongoing   -> update progress
Triggered -> commit interaction
Canceled  -> abort and hide progress
Completed -> finish successful cleanup

These are starting patterns, not universal aliases. A Tap or Released trigger can recognize success on release, while a simple active action can trigger every frame. See Enhanced Input trigger states for the full lifecycle.

Elapsed Seconds and Triggered Seconds

The action instance tracks two different clocks:

Output Counts
Elapsed Seconds Total time since the action began evaluation, including time spent Ongoing before it succeeds.
Triggered Seconds Time the action has actively spent in the Triggered state.

For a Hold trigger with a 0.5 second threshold:

at 0.3 seconds:
    state = Ongoing
    Elapsed Seconds ~= 0.3
    Triggered Seconds = 0

at 0.8 seconds:
    state = Triggered
    Elapsed Seconds ~= 0.8
    Triggered Seconds ~= 0.3

Use Elapsed Seconds for progress toward a condition. Use Triggered Seconds for time after success, such as sustained charge beyond the minimum. Neither value is a replacement for world time, a retriggerable timer, or a replicated server clock.

When querying an FInputActionInstance outside the event path, note that its official GetValue contract returns zero unless the current trigger event is Triggered. Do not build release-value logic around an assumed nonzero value on Completed or Canceled; store the last meaningful Triggered value if the design needs it.

Where should the binding live?

Blueprint Good fit Watch out for
Character or Pawn Movement and abilities owned by the currently possessed body. A respawned pawn is a new instance and needs its bindings/setup.
PlayerController Player-level controls that survive pawn swaps, menus, spectating, and selection. Forward pawn-specific work to the currently possessed pawn deliberately.
Actor with Enable Input A temporary actor that truly owns direct local input. It joins the controller's input stack and can compete or consume input.
Widget UI events through UMG's focus/navigation path. A gameplay Input Action event is not the same as a focused widget key event.

The quick path is to put every Input Action event on whichever Blueprint is open. The concrete cost is hidden ownership: respawn, possession swaps, split-screen, and menu focus become much harder to reason about. Put the binding on the object that owns the behavior's lifetime.

Context priority and consumption

Several active Mapping Contexts can refer to the same physical key. Priority decides which context is considered first, while consume settings decide whether lower-priority mappings also get the key.

On the Input Action asset, Consume Input is displayed as Consume Lower Priority Enhanced Input Mappings in current editor versions. When enabled, a triggered action can block lower-priority Enhanced Input mappings that share its input. The separate legacy-consumption option controls old Action and Axis mappings; it is not the same switch.

When two events compete:

1. list every active context for this local player
2. record each context priority
3. find every mapping that uses the physical key
4. inspect action and binding consume settings
5. verify which action reaches Triggered

Do not fix a priority problem by adding the same context repeatedly or by moving all contexts to extreme numbers. Give each mode a clear owner and add and remove it as that mode starts and ends.

UI focus and pause

Input Mapping Contexts, viewport input mode, widget focus, and pause are separate systems.

  • UI Only input mode routes keyboard/controller input to focused UI rather than normal gameplay input.
  • Game and UI lets UI handle input first, then can leave unhandled input for the PlayerController.
  • A focused widget can consume a key before gameplay uses it.
  • An Input Action only evaluates while paused if its Trigger When Paused setting permits it.
  • Adding a menu Mapping Context does not focus a widget or show the cursor.
  • Restoring Game Only does not automatically remove the menu context.

Treat menu entry and exit as paired transactions. Apply/remove the context, set/restore input mode, set focus, and restore cursor/pause state together. See Set Input Mode and Show Mouse Cursor.

Local players and multiplayer

Enhanced Input's normal gameplay subsystem is per local player. In split-screen, each local PlayerController has its own LocalPlayer subsystem, active contexts, and input route. Do not use Player Index 0 everywhere when you already have the owning PlayerController.

In network play:

owning client receives device input
-> local Input Action event fires
-> client performs allowed local feedback/prediction
-> client calls a validated Server RPC for authoritative gameplay
-> server changes replicated state

The server copy of a remote client's pawn does not receive that client's keyboard. An Input Action event also does not replicate itself. Replicate the gameplay request or resulting state through the appropriate networking path.

For listen-server testing, do not let the host window hide this distinction: the host is both server and a local player, while remote clients are not.

When it appears to fail

Use this order because each step proves one boundary:

  1. Correct Blueprint instance: Is the debugger attached to the possessed pawn or intended PlayerController, not an editor preview or old instance?
  2. Local ownership: Is this controller local on the machine/window where the key is pressed?
  3. Active context: Does that local player's subsystem contain the expected Mapping Context at the expected priority?
  4. Physical mapping: Does the context map this key/device axis to this exact Input Action asset?
  5. Action state: Does the action reach Started, Ongoing, or Triggered?
  6. Value contract: Does the asset's Value Type match the typed getter and the expected axes?
  7. Routing gates: Are consumption, UI input mode, focus, pause, or an ignore-input state blocking the intended path?
  8. Gameplay response: Does the downstream function act on the pawn or object you are actually watching?

showdebug enhancedinput is useful for the middle of this ladder. Blueprint breakpoints prove the receiving instance and downstream graph. Use both rather than treating either view as a complete diagnosis.

The C++ twin

This is original example code, not engine source:

#include "EnhancedInputComponent.h"
#include "InputAction.h"

void ATrainingCharacter::SetupPlayerInputComponent(
    UInputComponent* PlayerInputComponent)
{
    Super::SetupPlayerInputComponent(PlayerInputComponent);

    UEnhancedInputComponent* EnhancedComponent =
        CastChecked<UEnhancedInputComponent>(PlayerInputComponent);

    EnhancedComponent->BindAction(
        MoveAction,
        ETriggerEvent::Triggered,
        this,
        &ATrainingCharacter::HandleMove);
}

void ATrainingCharacter::HandleMove(const FInputActionValue& ActionValue)
{
    const FVector2D Move = ActionValue.Get<FVector2D>();
    AddMovementInput(GetActorForwardVector(), Move.Y);
    AddMovementInput(GetActorRightVector(), Move.X);
}

The C++ binding still needs the same active context, local ownership, value type, trigger, and possession setup as the Blueprint event.

Lookalikes - which one do I want?

Thing Use when Not the same as
Input Action event A Blueprint should respond to an action's trigger lifecycle. Mapping a physical key to the action.
Input Action Value You need the current typed bool/axis value delivered by the action. A key name or raw hardware event.
Input Mapping Context You need to define and activate key-to-action mappings for a local player. The graph that handles the action.
Input Modifier You need to negate, swizzle, scale, dead-zone, or otherwise reshape a value. A trigger condition or gameplay side effect.
Input Trigger You need timing or conditions such as Hold, Tap, Pressed, or Chorded Action. Value reshaping.
Any Key / key event You genuinely need a raw key rather than an action abstraction. A reusable, remappable Enhanced Input action.
UMG key/navigation event Focused UI should process a key. Gameplay action routing through a possessed pawn.

Going deeper