Skip to content

Input Actions & Input Mapping Contexts

Enhanced Input splits "what the player is trying to do" from "which physical inputs mean that right now." Most beginner confusion comes from mixing those two jobs back together.

The one-minute version

  • An Input Action is the gameplay idea: Move, Jump, Look, Interact, Pause. It also has a value type, such as boolean, 1D axis, 2D axis, or 3D axis.
  • An Input Mapping Context is the control scheme that says which keys, buttons, sticks, or axes feed those actions in this player mode.
  • A modifier changes a raw input value before the action sees it. Negate and Swizzle are the reason WASD can become one 2D movement action.
  • A trigger decides when an action is considered started, triggered, completed, canceled, or ongoing.
  • Mapping contexts are added to a local player through the Enhanced Input subsystem. Creating the asset is not enough; an active player must have that context applied.
  • Legacy tutorials often show Project Settings action/axis mappings and old input events. Enhanced Input tutorials use InputAction and InputMappingContext assets.

The mental model

Enhanced Input has four beginner-facing pieces:

flowchart LR
    Key[Key, button, stick, axis] --> Context[Input Mapping Context]
    Context --> Modifier[Modifiers]
    Modifier --> Trigger[Triggers]
    Trigger --> Action[Input Action event/value]
    Action --> Gameplay[Your Blueprint logic]

The useful split is:

Input Action          = what gameplay code wants to hear about
Input Mapping Context = which physical controls feed those actions right now
Modifier              = how raw values are reshaped
Trigger               = when an action counts as fired

That means IA_Jump can stay the same action whether it comes from Space Bar, gamepad face button, or a remappable input preset. The gameplay graph listens for IA_Jump. The mapping context decides which device input reaches it.

Input Actions are the "what"

An Input Action is a data asset that names an input concept and gives it a value type.

Common examples:

Action Typical value type Beginner meaning
IA_Jump Boolean Pressed or not pressed.
IA_Interact Boolean One command-style input.
IA_Move Axis2D A 2D direction, usually X = right/left and Y = forward/back.
IA_Look Axis2D Mouse or right-stick look delta.
IA_Throttle Axis1D One signed or unsigned float value.

The value type matters. If IA_Move is accidentally a boolean action, the movement graph cannot receive a 2D vector. If IA_Jump is accidentally an Axis2D action, a simple button press becomes harder to reason about.

Blueprint code normally binds or listens to the action, not to the raw key:

IA_Jump Triggered
-> Jump

IA_Move Triggered
-> Action Value
-> Get 2D Axis Value
-> Add Movement Input

That is the core benefit. Your gameplay graph can keep saying "Move" or "Jump" while the active control scheme changes elsewhere.

Mapping Contexts are the "which keys, when"

An Input Mapping Context is also a data asset. It contains rows that connect physical inputs to Input Actions, plus optional modifiers and triggers on those mappings.

Examples:

Context Contains
IMC_DefaultGameplay Move, look, jump, interact, pause.
IMC_Menu Navigate, accept, back, tab left/right.
IMC_Vehicle Steer, throttle, brake, handbrake, exit vehicle.
IMC_BuildMode Place, rotate, cancel, cycle piece.

Contexts can be added and removed while the game runs. That is why the word "context" matters. The same A key might mean "move left" during gameplay, "tab left" in a menu, or "rotate piece" in build mode depending on which mapping contexts are active and which one has priority.

Normal gameplay:
    Add IMC_DefaultGameplay priority 0

Pause menu opens:
    Add IMC_Menu priority 10
    optionally remove or ignore gameplay input

Pause menu closes:
    Remove IMC_Menu
    gameplay context remains or is re-added

See Add Mapping Context for the API side: where to add the context, how priority works, and why local player subsystem timing matters.

Why WASD is one Axis2D action

In the old mental model, beginners often think:

W = MoveForward
S = MoveBackward
A = MoveLeft
D = MoveRight

Enhanced Input is cleaner if those keys feed one IA_Move action with a 2D value:

IA_Move value:
    X = right/left
    Y = forward/back

Then each key contributes to the same 2D vector:

Key Raw key value Modifiers Resulting IA_Move value
W +1 Swizzle axis to Y (0, +1)
S +1 Negate, then swizzle axis to Y (0, -1)
D +1 none (+1, 0)
A +1 Negate (-1, 0)

Now the movement graph only needs one action value:

IA_Move Triggered
-> Get 2D Axis Value
-> X feeds right-vector Add Movement Input
-> Y feeds forward-vector Add Movement Input

That pattern keeps keyboard, left stick, and other movement devices on the same action. The stick can feed a natural 2D value, while WASD is reshaped into the same kind of value with modifiers.

Modifiers reshape values

A modifier runs before the action value reaches your Blueprint event.

Common beginner examples:

Modifier idea Use when
Negate A positive key value should become negative, such as A = left or S = backward.
Swizzle A 1D key value should land on another axis, such as W becoming the Y value of a 2D move action.
Dead Zone Small analog-stick drift should be ignored.
Scalar A raw value should be multiplied before gameplay reads it.

Do not use four separate movement actions just to avoid modifiers. The quick path is easier to understand for one keyboard, but the concrete cost appears when you add gamepad, rebinding, UI glyphs, or movement code that now has to merge several actions back into one direction.

Triggers decide when the action fires

Triggers answer "when should this action count?" They are separate from the input's value type.

Examples:

Trigger idea Beginner use
Plain press/button behavior Jump, interact, pause.
Hold Charge, sprint hold, aim hold, long-press interactions.
Tap Dodge, quick interact, rhythm-style inputs.
Axis held past a threshold Movement/look values that should fire while nonzero.

Blueprint action events expose states such as Started, Triggered, Ongoing, Completed, and Canceled. Do not assume Triggered always means "pressed once." For an axis action, Triggered can update every frame while the input remains active.

See Started, Triggered, Ongoing, Canceled, Completed for the trigger-state details. The first rule is still: choose the action value type first, then choose the trigger behavior that matches the interaction.

How to recognize legacy input

Many tutorials still use the older input system. That does not make them useless, but it changes what you are looking at.

What the tutorial shows Likely system
Project Settings -> Input -> Action Mappings / Axis Mappings Legacy input
Blueprint events named InputAxis MoveForward or InputAction Jump without Input Action assets Legacy input
Content Browser assets named IA_Move, IA_Jump, IMC_Default, IMC_Player Enhanced Input
Nodes that add mapping contexts to an Enhanced Input subsystem Enhanced Input
Enhanced Input Action Event nodes with Started/Triggered/Completed pins Enhanced Input

If a UE5 template already has IA_ and IMC_ assets, follow the Enhanced Input model instead of adding old Project Settings mappings beside it. Mixing systems can work in advanced projects, but it makes beginner debugging much harder because two input paths can be firing or blocking each other.

When input seems broken

  1. The Input Action exists, but no active context maps anything to it. The Blueprint event is waiting for an action no key can currently produce.
  2. The Mapping Context asset exists, but it was never added to the local player. Assets in the Content Browser do nothing by existing.
  3. The context was added on the wrong machine or player. Enhanced Input mappings are local-player-facing. Server-only setup does not give a client viewport new controls.
  4. The action value type is wrong. A boolean action cannot produce a 2D movement vector.
  5. A higher-priority context is consuming the input. Menu or mode-specific controls can intentionally block lower-priority gameplay mappings.
  6. The event state is wrong for the interaction. For example, a held action may need Completed for release behavior, while movement usually uses a value that updates while active.
  7. The pawn is not possessed or not binding the action. Mapping keys to an action is separate from binding gameplay logic to that action event.
  8. A UI/input mode change is routing controls somewhere else. Input mode and mouse cursor state are separate from mapping contexts, but they often change during the same menu flow.

Use showdebug enhancedinput while playing to inspect active Enhanced Input state, and use Print String and the Output Log or breakpoints to prove which action events are actually firing.

Lookalikes - which one do I want?

Thing Use when Not the same as
Input Action Gameplay needs a named input event or value, such as Move or Jump. A key binding by itself.
Input Mapping Context A player mode/control scheme maps keys and devices to actions. The gameplay response to an action.
Modifier Raw values need to be reshaped before gameplay sees them. A trigger condition.
Trigger The action should fire only under timing/threshold rules. The input value type.
Add Mapping Context A local player should start using a context. Creating or editing the context asset.
Bind Action / Enhanced Input Action Event Blueprint or C++ should respond when the action fires. Mapping a key to the action.
Set Input Mode UI/game focus and mouse capture should change. Enhanced Input mapping context priority.
Enable Input A specific actor should accept input from a controller. The normal possessed-pawn Enhanced Input setup.

Going deeper