Haven’t done that myself, I use the default input system for now. that sounds awful though since a key press on a keyboard should just be 0 or 1 and nothing else… I’d be shocked if something that basic does not work XD. Maybe the events are firing at a different rate?
1 Like
I think the problem is the examples Epic put out don’t work the way you’d expect them to for keyboard. That config works great for a Gamepad.
They have ONE Input Action for IA_Move. So IA_Move will only fire once, in one direction. On gamepad, the direction is correct. On keyboard, the direction is based on the order in which you list the keys in the default Epic configuration, none of which are correct if you have multiple keys pressed.
To change this, for Keyboard Only I think you need to delete the keyboard IA_Move triggers, and add 4 different input actions IA_MoveForward, IA_MoveBackward, IA_MoveLeft, IA_MoveRight, which are mapped to your WASD keys instead of all 4 going to IA_Move.
With such a setup, pushing all 4 keys simultaneously should result in zero movement.
EDIT: I tried this on my Lyra project, it works great. 
5 Likes
Nice workaround, it doesn’t look so “enhanced” since it requires a more complex setup, but thanks for the solution!
They should implement it by default in the templates considering how many people play on keyboard! I hope it will come in the next updates.
2 Likes
It’s not really any more complex. It just treats each key independently which is I think what the old input system used to do too?
I documented exactly what I did here to make it easy for others to duplicate:
EDIT: I did submit a UE Engine bug for this, along with the fix. Hopefully they do fix this for Lyra and Third Person Template and wherever else it’s not working as expected.
3 Likes
In the old input system you only had MoveRight and MoveForward, the opposite inputs only had a negative value, it’s not a huge issue but now you have to setup the events twice. Honestly, I’m just happy that it works!
Thank you again for reporting it!
1 Like
With the old system (no Enhanced Input and no CommonUI) I ran into odd behavior using the slate navigation keys (arrow keys and tab), such as tab keys going to a path you can’t return from, arrow keys not navigating into a direction or not detecting a widget in a direction:
Are there improvements on this with Enhanced Input or CommonUI, or any plugin at all?
The point of CommonUI is to make sure that stuff doesn’t happen anymore.
It forces construction of the UI such that arrow keys & gamepad buttons all work consistently and reliably. (Assuming you set up the widgets correctly).
1 Like
Thanks for uncovering this flaw! I’ve used EnhancedInput on a few projects now, and never knew about this. Thanks to @xi57 as well, for figuring out a workaround! I’ll be using it in all my projects going forward.
2 Likes
Thoughts on this?
Regarding Enhanced Input plugin I am very happy with it and with the amount of new possibilities it provides regarding control. So it is a total yes for me, plus not found many bugs or issues while using this plugin. It seems any problem is found and fixed quite quickly. Enabling/Disabling Input mapping contexts is very useful and I can use without enabling the ability system. Moreover, you learn to avoid certain actions on certain scenarios. For example, I avoid tap on UI control because it does not guarantee press and release triggers, if you hold the button past the tap time there is no button release, so it may give you problems when “game and UI” input mode is set.
However discussion has derived in commonUI which has nothing to do with the topic of this forum post xD.
I am in general very disappointed with commonUI, documentation on customizing it for special use cases is missing. I followed video tutorials that appeared last summer and I have tested the “contentExamples” map and its widgets. Also several incomplete workarounds to missing features people has provided.
It has many bugs I reproduced in several different projects, ie: Default input data actions for accept are not working and are hard-coded. Focus is lost when changing from a widget to another if tapping gamepad accept button while widget transition animations play.
I think it needs still a couple of years of development. It should be marked as an experimental plugin (which indeed if you look at epic games unreal engine github is under HEAVY development and testing).
CommonUI does not look like working on becoming a versatile tool suitable for different kinds of games and needs. Right now it hardcodes the keys and forces the input mode to be “ui only”, among other things xD. Navigating through UI buttons with keyboard, gamepad and mouse is not tested in hybrid scenarios. Don’t think in a dark souls like UI which can be controlled while also being able to move the character (this would be suitable for MMORPG like intensive inventory RPG).
Instead of focusing on having a solid base without bugs, it seems a race towards implementing many ui widgets now, even though there still exist game breaking errors that forbid its use in production.
CommonUI should still be marked as “experimental”, because it is totally broken right now, if you lose focus.
2 Likes
I’ve been using CommonUI in my projects for a while, and I too have concerns about it. I initially gravitated to the plugin because UMG’s gamepad support is so, so terrible and I had a really tough time finding resources for putting together menus, that can handle both gamepad and mouse + keyboard support with ease.
Now that I’m learning how to remap Enhanced Input actions, I’m noticing some friction between Enhanced Input and CommonUI. Sure, I can use CommonActionWidgets to display inputs on the screen, but what if those inputs are for remappable actions? Updating all of those together, and keeping things consistent seems like it’ll be rough. That, along with some of CommonUI’s other “quirks”, have got me thinking about trying to reduce my reliance on the plugin.
1 Like
I know I’m late to the party on this but I am not a fan of the Enhanced Input system. I like the OPTION of both. There are pros and cons on either side. I don’t like being forced to switch.
Yes, “somebody” thinks the new way is better and it may be for them. But to me, it’s unintuitive. I have been going in circles trying to get the most basic aspects of it to work, reading the boards and abysmal documentation to learn about it, when I could just be making my game. If it worked out of the gate, I doubt we’d be having these “Yay or Nay” sessions about it, but there’s a steep-af learning curve. It’s not a straight switch. The entire setup for it is literally patch-worked in. It doesn’t play nice with UI (neither did the old one, really)…, and I think it’s cool that it has built-in timings for pressed, held, etc, but getting access to that data in C++ seems awkward.
And for a company that should be well-versed on gauging user experience, I don’t think this was work-shopped well enough before rollout.
In both systems you can control it with an axis mapping meaning only one input action is required, the only thing more complex in the new system is the overall set up but otherwise it’s great
Welcome to 2024 
How is local splitscreen input doing? Any splitscreen or UMG nastyness still present in the latest, or are we all good? Looking back at the old input system months later, what do you prefer?