Enhanced Input Limitations and Bugs

So, I came across two problema with the new input system.

1 - When trying to create a new input mapping by code, the function to add inputs does not take in the modifiers or triggers, and the struct that comes out is not a ref, just a copy, so altering that after does nothing. So, creating a nre input, unless it’s very simple, becomes impossible.

2 - The second one is a bit more weird. If I try to disable an input mapping after an input is pressed, it seams like the system reboots and never stop calling the input. To be more clear:
I have an “Aim” input, and when it starts disables jumping (No reason, just testing the system), and it calls a print string Aim. When I realease the jump is added back in and a print NoAim is called.
The problem is that if the remove mapping context is called after the input, in started for example, the started it’s called on like on tick, Printinf the “Aim” multiple times and when release, the “NoAim” it’s never called. The screenshots will help to understand. Both Aim and Jump inputs are simple inputs with no triggers or modifiers.
Without the remove, the code flows as expected.


AimBugPrintString

I’m doing something wrong it those cases?
If not I will report bugs.

Thanks for your time.

1 Like

I’ve encountered what is probably the same issue. I was adding then removing a mapping based on an input being triggered then completed. It seems the state of the input gets lost with the add mapping call. If they need to reset input states when mappings change, then the mappings are less than ideal. Every use case I can think of using them for could involve other input occurring at the time that we’d want to continue on with. Even switching from an “InGame” mapping to a “UI” mapping when you go to the pause screen could be problematic.

Hey guys, same “problem” here with some UI. I try to AddMappingContext when I open a widget to add new inputs and remove them when I close it.

Add and Remove MappingContext totally rebuild control mappings. We can check that just by diving into the code of this functions :

void IEnhancedInputSubsystemInterface::AddMappingContext(const UInputMappingContext* MappingContext, int32 Priority)
{
	// Layer mappings on top of existing mappings
	if (MappingContext)
	{
		if (UEnhancedPlayerInput* PlayerInput = GetPlayerInput())
		{
			PlayerInput->AppliedInputContexts.Add(MappingContext, Priority);
			RequestRebuildControlMappings(false);
		}
	}
}

So, when using a “Pressed” trigger on an input, adding a mapping context on Triggered, and holding down the input when playing, the event is invoked infinitely. Would be cool to have a documentation on this behavior, as I spent a lot of time understanding why my pressed input was not working as expected ! And if someone has a workaround, I would take it with pleasure :smiley:

I would like to add that SetInputMode functions also add strange behavior, kind of resetting the input’s states as well… I’m invoking SetInputModeGameAndUI in the event handler of an input with Pressed trigger.

Struggling with the same issue currently, it would be awesome if someone has a solution.

Every possible use case for removing and adding context mappings that I can think of would require me to NOT fire the “started” event once it happens.

E.g. I can have a bunch of buttons on my controller down and then press the Inventory button. At that point, I’d probably remove the default gameplay context and add the new UI context. That would trigger a bunch of “Started” events for the UI inputs.

A real scenario example:
Gameplay input mapping context has an “Inventory” action that opens the inventory on “Started”
UI Input mapping context has a “Quit” action that closes the inventory on “Started”

Opening the inventory causes the gameplay input mapping context to be removed and the UI input mapping context to be added.
Result: pressing the button now infinitely triggers the inventory on and off while its down.

Without being able to handle UI inputs correctly, I had to come back to the default input system until this plugin is upgraded to a better version :confused:

This sounds like fix for point 2: https://github.com/EpicGames/UnrealEngine/commit/35c3a22eccf5f15f351fd4f66e257c1e286b9971

3 Likes

Yes, this does look like exactly what I would need. Thanks for bringing the good news!

With what Skylonxe linked it seems like a fix for it would be deployed to the launcher versions with the official release (the commit points to 5.0 PR)

1 Like

I was wondering if anyone else has ran into trouble saving remapped keys for actions in a mapping context. When I unmap and remap an action while running in PIE it will change the underlying Input Mapping Context asset. So next time the game is launched the new key is remembered. If I do this in stand alone or a packaged build the new keybindings aren’t saved.

1 Like

It seems that proper support for Enhanced Input remapping has been submitted 2 days ago :slight_smile:

https://github.com/EpicGames/UnrealEngine/commit/7fde77ae25c2968f6747a3b6026fc300b9b52b5f

1 Like

I’m currently using 5.0.2 and the issue of “pressed” firing indefinitely, when the input is used to add, remove, or somehow change the Enhanced Input Subsystem, is still present. While it would be ideal for it to be fixed. In the meanwhile, for inputs such as key rebinding, or switching to a UI navigation mapping context on opening the menu, the “Tap” trigger should still work, it doesn’t seem to suffer from the perpetual firing, and in most instances, it shouldn’t make much of a difference.