How does Mapping Context Priority work in Unreal Enhanced Input?

When you add a mapping context with AddMappingContext, the Priority integer determines which context consumes a key first. Higher priority wins. If a context has a binding for a key and the action modifiers allow it to fire, lower-priority contexts will not see that key event unless the higher-priority context explicitly does not consume it.

Why is my menu input also firing gameplay actions?

Your UI mapping context is not at a higher priority than the gameplay context, or both contexts are bound to the same key and neither consumes it. Add the UI context with a higher priority when the menu opens, and remove it when the menu closes.

Can I remove a specific mapping context without removing others?

Yes. Call RemoveMappingContext with the specific IMC asset. Other contexts remain active. This is how you layer UI over gameplay: add the UI context when the menu opens, remove it when the menu closes, and the gameplay context underneath is untouched.

Fix: Unreal Enhanced Input Mapping Context Priority

Quick answer: Assign clear priorities (Gameplay = 0, Vehicle = 10, UI = 100), add and remove mapping contexts as state changes, and use the showdebug enhancedinput console to verify which contexts are active. Higher priority wins; same-priority contexts can fight each other.

Enhanced Input is Unreal’s replacement for the legacy Input Action system, and it is strictly better — once you understand how mapping contexts layer on top of each other. The confusion comes when you add a UI and discover that opening a menu still lets the character fire their weapon, or that entering a vehicle doesn’t stop walk input. The fix is mechanical, but you have to know which mechanism to use.

How Mapping Contexts Work

A mapping context (IMC_...) is an asset that maps physical keys to Input Actions. Your PlayerController adds contexts to a local player’s EnhancedInputLocalPlayerSubsystem, and each context has a Priority integer assigned at add time.

When a key is pressed, the subsystem walks through all active contexts in priority order (highest first). The first context that has a binding for that key fires the action. By default, fired actions consume the input and stop lower-priority contexts from seeing it.

The Symptom

You have a Gameplay context with WASD movement and a UI context that uses the same keys for menu navigation. When the menu opens:

WASD moves both the character and the menu cursor.
Escape closes the menu and also triggers a gameplay pause.
Clicking a button also fires the gameplay primary fire action.

Or you get into a vehicle:

Accelerating the vehicle also moves the character ghost walking forward.
Steering moves the camera as if you were looking around on foot.

All of these are priority or consumption bugs.

The Fix: Assign Priorities

Document a priority table for your project:

Gameplay (IMC_Gameplay)   Priority = 0
Vehicle  (IMC_Vehicle)    Priority = 10
Menu     (IMC_Menu)       Priority = 100
Cutscene (IMC_Cutscene)   Priority = 200
Debug    (IMC_Debug)      Priority = 1000

Higher priority wins. The numbers are arbitrary — use widely-spaced values so you can insert new levels later without renumbering. When you open a menu, add IMC_Menu on top of the existing IMC_Gameplay. Gameplay bindings are still registered but the menu bindings sit above them and consume the input first.

Adding and Removing Contexts

// C++: Add menu context on menu open
void AMyPlayerController::OpenMenu()
{
    if (auto* Subsystem = ULocalPlayer::GetSubsystem<
        UEnhancedInputLocalPlayerSubsystem>(GetLocalPlayer()))
    {
        Subsystem->AddMappingContext(MenuMappingContext, 100);
    }
}

void AMyPlayerController::CloseMenu()
{
    if (auto* Subsystem = ULocalPlayer::GetSubsystem<
        UEnhancedInputLocalPlayerSubsystem>(GetLocalPlayer()))
    {
        Subsystem->RemoveMappingContext(MenuMappingContext);
    }
}

In Blueprint, use the Add Mapping Context and Remove Mapping Context nodes on the Enhanced Input Local Player Subsystem. The add node takes the IMC asset and a priority integer.

Always remove contexts when they are no longer needed. Leaving a cutscene context active after the cutscene ends blocks gameplay input until the player restarts.

Consume or Pass Through

Each Input Action has a Consume Input property in the Input Action asset. By default it is true, which means when the action fires, lower-priority contexts do not see the key. Set it to false for actions that should pass through — for example, a chat key that should still be processed by both the chat system and a debug HUD that also listens.

Layering for Vehicles

Vehicles are a common layering case. Gameplay has WASD for walking. Vehicle has WASD for throttle and steering. Both use the same keys.

Option A: Swap contexts. When entering a vehicle, remove IMC_Gameplay and add IMC_Vehicle. When exiting, remove IMC_Vehicle and add IMC_Gameplay. The player can never walk while driving — which is what you want.

Option B: Priority stacking. Add IMC_Vehicle at a higher priority than IMC_Gameplay. The vehicle context consumes the keys and the gameplay context never sees them. Leave the gameplay context active for actions that should still work (e.g. Escape to pause).

Option A is cleaner and harder to misuse. Option B is flexible but requires discipline.

Debugging with showdebug

Press backtick (`) in a PIE session and type showdebug enhancedinput. A debug HUD appears showing every active mapping context, its priority, every action in every context, and which actions fired this frame. If your bug is “my UI keeps triggering gameplay,” this display tells you exactly why: you will see both contexts active at the same priority or the gameplay context not being consumed.

Verifying the Fix

Open a menu, press every menu key, and confirm no gameplay actions fire. Close the menu, press every gameplay key, and confirm they work again. Enter a vehicle, drive, exit, and walk. If any action triggers at the wrong time, check the priority table and the add/remove calls.

“Enhanced Input is a stack of mapping contexts. Think of it like CSS z-index: the higher number is on top. Get the numbers right and every layering problem becomes a one-line fix.”

Related Issues

For actions that never fire at all, see Unreal enhanced input action not triggering and Unreal enhanced input not responding. For widget input being swallowed, see Unreal Common UI widget not receiving input.

Leave big gaps between priority numbers. Priorities at 0, 10, 100, 1000 are much easier to insert between than 1, 2, 3, 4.