Summary
While implementing a keybinding menu, I found that calling UEnhancedInputUserSettings::MapPlayerKey() with FKey() (None) correctly unbinds keyboard mappings, but fails to unbind gamepad mappings that have a default gamepad key.
The player key profile correctly stores the mapping as unbound, but UEnhancedPlayerInput rebuilds the runtime mappings using the original default key instead.
What Type of Bug are you experiencing?
Other
Steps to Reproduce
1 - Create a Player Mappable gamepad mapping with a default key (for example Gamepad_LeftShoulder).
2 - Register the Input Mapping Context with UEnhancedInputUserSettings.
Call MapPlayerKey() with the mapping name and FKey() (None).
3 - Rebuild the control mappings.
Expected Result
The action should become unbound and no longer respond to the default gamepad button.
Observed Result
The default gamepad button continues to trigger the action.
Affects Versions
5.7
Platform(s)
Windows
Additional Notes
Investigation
I tracked the issue to the Enhanced Input source.
After calling MapPlayerKey(None):
UEnhancedPlayerMappableKeyProfile::FindKeyMapping() reports:
Default Key = Gamepad_LeftShoulder
Current Key = None
This indicates the player profile correctly stores the unbound mapping.
However, during RebuildControlMappings(), GetPlayerMappedKeysForRebuildControlMappings(), QueryPlayerMappedKeys() calls DoesMappingPassQueryOptions(), which filters mappings based on the default key type.
The following comparison fails for an explicit None override:
const bool bKeyTypesMatch =
A.IsGamepadKey() == B.IsGamepadKey() &&
A.IsTouch() == B.IsTouch() &&
A.IsGesture() == B.IsGesture();
Where:
A = default key (Gamepad_LeftShoulder)
B = current player key (None)
Since:
A.IsGamepadKey() returns true
B.IsGamepadKey() returns false
the player mapping is rejected and RebuildControlMappings() falls back to the default mapping.
Why keyboard mappings work
For keyboard defaults, both the default key and None return false for IsGamepadKey(), so the comparison succeeds and the unbound mapping is applied correctly.
Notes
This appears to affect any gamepad mapping whose default key is a valid gamepad key. I originally discovered it while testing chord mappings, but the issue seems to be the device-type filtering rather than the chord trigger itself.
Can anyone confirm whether this is the intended behavior, or if this is a bug in the Enhanced Input implementation?