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.
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
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.
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)
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.
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.
Hi, I can confirm the issue of inifinite input triggers when the input is remapped is still occurring in UE 5.1, however, I managed to solve the problem quickly. It’s all about the false assumption that the “Ignore all Pressed Keys until Release” flag’s default value is true, but in fact you have to explicitly tell Unreal that you want it to be true.
Say for example that you have two input actions: IA_OpenInventory and IA_CloseInventory, both mapped on key I, on the Pressed Trigger type.
When IA_OpenInventory is triggered, you remove the current input mapping (IMC_Default) and add the new input mapping (IMC_Inventory). When IA_CloseInventory is triggered, you remove IMC_Inventory and add IMC_Default.
To prevent infinite close and open of your inventory, you need to make sure that the flag “Ignore all Pressed Keys until Release” on the RemoveMappingContext and AddMappingContext functions is explicitly set to true, for example by splitting the Options struct like in the image below. Leaving the default Options parameter probably leads to the creation of a struct with that flag set to false.
Sorry to necro, but I’m also seeing this on 5.2 and I was ready to resort to a more devious hack when I saw that manually unticking and ticking this flag fixed the issue. Software, never change.
I think I am having a similar issue on 5.1.1. I can’t seem to get the remove mapping to work. Does the PMI file need to be changes as well? I know the IMC works because when I manually change it in my VR_Pawn AND in the PMI_VRTemplate, it works. When I try to change the IMC context dynamically in the game I loose the motion controls.
Just fixed my problem. It was an actual bug. Turns out you CANNOT have the same “description” in multiple IMC files. If you do, then the hands do not work at all. You can have the same IA’s in multiple IMC’s but just no that little “description” field. Very frustrating little bug.
