Skip to content

Add Mapping Context

At a glance

Lives in: Blueprint API / Input; target is an Enhanced Input Subsystem Interface - Returns: nothing - Changes: the active Input Mapping Context list for a local Enhanced Input subsystem - Can appear to fail by: using the wrong local player/subsystem, adding a context with no matching action bindings, losing the binding on respawn, or letting a higher-priority context consume the input - Official docs: Add Mapping Context, Remove Mapping Context, Enhanced Input, and IEnhancedInputSubsystemInterface

The one-minute version

  • Add Mapping Context makes an Input Mapping Context active for a local Enhanced Input subsystem. The context asset does nothing until some local player has it applied.
  • The target is not the pawn. The common Blueprint chain is: get the relevant PlayerController, get its local player, get the Enhanced Input Local Player Subsystem, then call Add Mapping Context.
  • Priority matters. Higher-priority contexts are applied first and can block lower-priority mappings when input is consumed.
  • Add Mapping Context does not bind gameplay events. Your pawn, controller, or component still needs to respond to the Input Actions.
  • Use Remove Mapping Context when a temporary mode ends, such as menu, vehicle, build mode, dialogue, or inspect camera controls.
  • Respawn bugs usually come from mixing three separate jobs: the local player has mappings, the possessed pawn has bindings, and the controller decides which pawn receives input.

What it actually does

Enhanced Input separates the mapping asset from the player currently using it. An InputMappingContext asset says:

W, A, S, D -> IA_Move with modifiers
Space      -> IA_Jump
E          -> IA_Interact

Add Mapping Context says:

This local player should use that mapping context now, at this priority.

At beginner altitude:

flowchart LR
    PC[PlayerController] --> LP[Local Player]
    LP --> Subsystem[Enhanced Input Local Player Subsystem]
    Context[Input Mapping Context asset] --> Subsystem
    Subsystem --> Actions[Input Action values/events]
    Actions --> Bindings[Your Blueprint bindings]

The call changes the subsystem's active mapping-context list, then Enhanced Input rebuilds the control mappings for that player. It does not create the context asset, does not edit the asset permanently, does not possess a pawn, and does not automatically create action events in your Blueprint.

The pins that matter

Pin Meaning
Target The Enhanced Input subsystem/interface you are modifying. For a normal player, this is the local player's Enhanced Input Local Player Subsystem.
Mapping Context The InputMappingContext asset to activate, such as IMC_DefaultGameplay or IMC_Menu.
Priority Higher-priority contexts are considered before lower-priority contexts. Use this for temporary modes and UI layers.
Options Advanced add/remove behavior for how the subsystem handles the mapping change. Beginners usually leave it at the default.

The node has only an execution output. It does not return success/failure, the previous priority, or the active context list.

The pattern everyone actually uses

For a single-player Character project using Enhanced Input:

PlayerController BeginPlay
-> Get Local Player
-> Get Enhanced Input Local Player Subsystem
-> Add Mapping Context
   Mapping Context = IMC_DefaultGameplay
   Priority = 0

Then the possessed Character or PlayerController binds/responds to the actions:

IA_Move Triggered
-> read Vector2D action value
-> Add Movement Input

IA_Jump Started or Triggered
-> Jump

That separation is intentional:

Mapping Context active?  = can physical input produce IA_Move?
Action binding present?  = does any Blueprint respond when IA_Move fires?
Pawn possessed?          = does movement input drive the pawn you are watching?

You need all three for normal movement to work.

The C++ twin, for the curious (our own example code):

#include "EnhancedInputSubsystems.h"
#include "InputMappingContext.h"

void ATrainingPlayerController::BeginPlay()
{
    Super::BeginPlay();

    ULocalPlayer* LocalPlayer = GetLocalPlayer();
    if (!IsValid(LocalPlayer))
    {
        return;
    }

    UEnhancedInputLocalPlayerSubsystem* Subsystem =
        LocalPlayer->GetSubsystem<UEnhancedInputLocalPlayerSubsystem>();
    if (!IsValid(Subsystem) || !IsValid(DefaultGameplayContext))
    {
        return;
    }

    Subsystem->AddMappingContext(DefaultGameplayContext, 0);
}

Where should I call it?

Use the place that owns the control scheme.

Place Good for Watch out for
PlayerController BeginPlay Default gameplay controls for the local player. Make sure you are running for the local player whose viewport should receive input.
PlayerController when a mode opens/closes Menus, build mode, inspect mode, dialogue, inventory, vehicles. Remove temporary contexts when the mode ends.
Pawn/Character after possession Pawn-specific controls that only make sense while that pawn is controlled. The pawn may not have a local player if it is not possessed by a local PlayerController.
Widget or UI flow through its owning player Menu-specific contexts paired with focused UI. Do not guess Player Index 0 inside widgets when an owning player reference exists.

The quick path is to put Add Mapping Context in the Character's BeginPlay because the template did something nearby. The concrete cost appears during respawn, possession swaps, split-screen, or UI-owned flows: BeginPlay belongs to an actor instance, but mapping contexts belong to a local player subsystem. For default player controls, a local PlayerController setup is usually clearer.

Priority

Priority resolves overlaps between active contexts.

Example:

IMC_DefaultGameplay priority 0:
    E -> IA_Interact
    W/A/S/D -> IA_Move

IMC_Menu priority 10:
    E -> IA_Accept
    W/A/S/D -> IA_Navigate

When the menu context is active at a higher priority, it can take the same physical keys first. That is the point: the same keyboard should mean gameplay controls during gameplay and menu navigation during the menu.

Use a simple convention early:

Priority range Example use
0 Default gameplay.
10 Temporary gameplay mode: build mode, vehicle, inspect mode.
50 Menu or dialogue controls.
100 Modal override that should win over everything else.

The numbers are your project convention. The important part is leaving space between tiers so you are not constantly renumbering later.

Removing contexts

Add Mapping Context is half of the lifecycle. Temporary contexts need a matching exit path:

Open inventory
-> Add Mapping Context IMC_Inventory priority 50
-> Set Input Mode Game and UI or UI Only
-> Show Mouse Cursor true

Close inventory
-> Remove Mapping Context IMC_Inventory
-> Set Input Mode Game Only
-> Show Mouse Cursor false

Remove Mapping Context removes a specific context from the subsystem. Epic's Blueprint API notes that removing a context that is not currently applied is safe, so it is fine for cleanup paths where the context may already be gone.

For drastic mode resets, Enhanced Input also exposes clear/rebuild operations on the subsystem interface, but beginner code should usually remove the exact temporary context it added. Clearing everything can also remove the default gameplay context you still needed.

Why input dies after respawn or possession swap

Respawn exposes the difference between mappings, bindings, and possession.

Common causes:

  1. The new pawn is not possessed. The mapping context can be active, but movement input will not drive an unpossessed pawn.
  2. The new pawn never bound the actions. If bindings live in the pawn, the new pawn instance needs its input binding setup to run.
  3. The old pawn added a pawn-specific context and the new pawn did not. Context setup in an actor's BeginPlay is easy to lose when actor instances change.
  4. A death/menu context is still higher priority. The respawned player is receiving input, but a temporary context is consuming the keys first.
  5. The context was added on the server only. A client viewport needs its local player subsystem configured on that client.
  6. Input mode was changed during death/menu flow and never restored. Set Input Mode is separate from mapping contexts, but both can be part of the same transition.

Debug in this order:

1. Is this pawn possessed by the player controller?
2. Is the expected mapping context active for the local player?
3. Is the expected Input Action event firing?
4. Is the action value the type/value you expect?
5. Is the movement or gameplay response using the pawn you are watching?

showdebug enhancedinput helps inspect Enhanced Input state while playing. Breakpoints and watch values help prove which Blueprint instance is actually receiving the action.

When it appears to fail

The execution wire continues, so failure usually looks like "I added the context, but no input happens."

Common causes:

  1. The Target subsystem is None. You did not get a valid local player subsystem before calling the node.
  2. The Mapping Context pin is None. The variable or asset reference was never assigned.
  3. The context has no mapping for the action you are listening to. For example, the graph listens to IA_Interact but the active context maps E to IA_Use.
  4. No Blueprint is bound to the action. Add Mapping Context enables input to produce the action; it does not tell gameplay what to do with it.
  5. A higher-priority context consumes the same key. Your lower-priority gameplay action never receives that key.
  6. The action value type is wrong. An Axis2D movement graph cannot read a useful Vector2D from a boolean action.
  7. The call runs for the wrong local player. This is especially common in split-screen, widgets, and network testing.
  8. You changed input mode, focus, or pause state separately. A valid mapping context does not guarantee the intended Blueprint path can receive or process input.

Use Print String and the Output Log to print the controller name, subsystem validity, context name, action value, and pawn being controlled.

Lookalikes - which one do I want?

Node or concept Use when Not the same as
Add Mapping Context A local player should start using an Enhanced Input context. Binding gameplay behavior to an action.
Remove Mapping Context A temporary context should stop affecting the local player. Clearing every mapping.
Clear All Mappings You are deliberately resetting the subsystem's active contexts. Normal mode cleanup.
Input Action Event / Bind Action Blueprint/C++ should respond when an action fires. Mapping keys to that action.
Input Mapping Context asset You are editing which keys/buttons feed actions. Applying that context to a player.
Set Input Mode UI/game focus, cursor capture, or menu routing should change. Enhanced Input context priority.
Enable Input A non-possessed actor should receive input from a controller. The usual possessed-pawn Enhanced Input setup.
Possess A controller should drive a different pawn. Applying controls to the local player subsystem.

Going deeper