First off, I am quite glad that both the input and the UI system are getting more attention lately both in the engine and through plugins.
Regardless of my own opinions about the plugins I am quite curious if Enhanced Input is the new standard for game developers. Will this by default replace the old input system such as creating input mappings in the project settings entirely anytime soon? What estimated percentage of the community is using this plugin and is it expected to grow?
The reason I ask this is that I prefer to work with the latest developments but are also cautious not to jump “to soon”, so what are your experiences? Is this plugin becoming the engine’s standard? How easily can you set up dynamic keybindings?
I have been postponing integration of my plugins with this one for a while now for the following reasons:
I dislike UAssets, I am a git user and prefer everything text nice and clear in one place.
I dislike context based input. I don’t want one button to mean 4 things just for UX. I keep it clean and implement button response on a controller / pawn level, not on a data asset.
I still use the project settings to set up input and keybindings.
Enhanced is the default option from 5.1 onward & the old system will be deprecated with time. You can keep a single mapping setup if you want. You can implement it like the old one, you just have extra options on top.
That would be great I feel like all the additions are too specific to a certain project in mind. For example if you’d make something advanced like a DCS flight simulator (tons of curve control, double mappings, per vehicle files) you’d certainly be writing your own system anyway. But good to know where the engine is heading so I can adapt to the community needs.
im using it for now. In my case, it suits my project.
I like the way it is abstracted - very similar to a custom system I was using before. The way you just swap out input “maps” makes sense to me.
As with a lot of epic stuff though, if I run into issues getting it to work, and I dont know enough to understand the source code (or just dont want to put in the time to reverse engineer), I often take the basic idea of it and then make my own version using blueprints.
I haven’t had to do that with EI but I did that way CommonUI.
Now you mention CommonUI which was also in my mind, it is still experimental but (scuse me) not usable… It only implements part of slate widgets and doesn’t fix the original issues we had with Slate, not even with the new viewport class. Still dealing with random focus loss where the mouse or controlls randomly stop working… For example, make a clean first person template project, add a text input box to the viewport, click it and add some text, commit and see how all controls and focus screw up. When I saw that I immediately uninstalled it and made my own framework in a percentage of CommonUI’s size (it’s bloated?). CommonUI is definitely a no for me at this stage, yet it also seems the community is pushed into that direction.
Hmm the text input change has nothing to do with common ui.
There was an update regarding how it registers changes to the input (on a c++ level). Committing with enter will no longer change the underlying text (there is an internal caching system that doesn’t seem to update like the old one). You have to set your value manually overriding the commit. (found this out replying to an older forum post)
yeah from commonUI the only thing that I use is the stack widget. But its not hard to recreate that either with blueprints.
But the basic principle of how it works has still been very helpful to me. The idea of push/pop widgets from a stack.
Well, I do use the activatable widgets as well. Having them auto-manage focus does save me some work. But like you said, it can be fussy about focus loss so there’s been a few times I’ve had to hardcode some failsafes to manage that. It would be nice to know a more proper way to implement it, but if that knowledge means digging through Lyra for the next 2 months, I’d rather just make a simpler system and keep working on my game :).
It’s a bit hard to explain what I meant with that without showing it on video but there are quite a few unsolved focusing problems with Slate (for many years) which I thought CommonUI fixed with their new viewport implementation but I was disappointed to find out none of that was really different. Basically there are so many ways focus and input screws up that the original Slate can be impossible to work with unless you first build a frame on top of it with workarounds and fixes to keep the focus from going mad. No plugin so far provided a stable base besides what I am working on.
That’s where I always say “screw it I’ll do it myself” cause those plugins don’t stick to a single goal they implement a bunch of things I don’t need. Optimally a module does one thing and does it well.
But about the focus loss, it is a problem which lies in both UI and input and all leads back to the implementation of Slate on the engine level sadly. To just give an example:
Releasing mouse in controller game + ui input mode makes window lose focus and screws axis events until a mouse button is held again.
clicking a backround widget screws focus, now a gamepad would have no way to retrieve it.
interacting with ui then removing the ui or focusing the gameport does not return controls to the pawn.
Just very very basic things like that can’t be fixed by building a roof (plugin) on a broken part of the engine (the walls). I’ve been able to work around it but any new clean project is honestly not fit for a serious game project without my “workaround frame”.
I’ve been experimenting with ways to simplify focus restoration when navigating through menus or when removing a focused elements but such a restoration process is often very different per implementation, just focusing to the top window or last focused valid widget in a history list is not a 1 fix for all so some manual work will still be required.
What I do expect though from the engine is that full focus loss to the UI should never be possible unless forced by the programmer. Think of how the web browser works, you can click anywhere but hitting tab restores keyboard focus (we need that for gamepad etc). Also I expect that in case focus is lost from the UI the controls must be fully restored to the controller or pawn which is currently not the case. Controls can get stuck in a mode where nothing works unless you click the window or somehow break out of control hell.
Ever since I learned how to integrate Enhanced Input into my projects, I’ve found it impossible to go back! It’s more involved and takes more work to set up than the default input system, but it’s absolutely worth it.
For me, one of the biggest benefits is additional options/flexibility for gamepad controls. if I wanna have actions that require holding a button, simultaneous button presses, all sorts of stuff…it’s way easier than trying to hack it together using Blueprint nodes alone.
I see you folks are also talking about CommonUI…I love it when it works, and utterly despise it when it doesn’t Still, it’s been my best (non-Marketplace) option for universal widget interaction with different input devices. I’m not very experienced with UI stuff, so I’m only using the ActivatableWidgets and WidgetStacks for now.
There’s a bug in UE5.1 that keeps putting my CommonUI widgets at the top-left corner of the screen, and I really hope it gets fixed in the next update. Some people have found workarounds, but they haven’t worked for me so I’m waiting.
Certainly! That’s the beauty of the UE Marketplace, open-source plugins on Github, and the like. It’s important for people to have options.
And I totally get the desire to have an add-on that only provides what you need, without any extra fluff. Something tells me I’ll probably never touch half the stuff that CommonUI has to offer.
In my experience this is what often leads to the code bloat but also the bugs that people are experiencing, code that says does “A” but actually does “B” and “C” is a very bad sign. mini modules are the best modules.
I’ll try to make a real tutorial for this, but for now I’ve outlined the major steps to take control of the mouse with CommonUI here:
The problem is when you use CommonUI, it has complete and total control over the mouse and over user input. So you have to work within its framework.
Once you hack the engine to make CommonUI more accessible (easy hacks) then it will stop stealing inputs and swapping things on you when you don’t want or expect it to.
I don’t know exactly what is going on in your github post. The situation you describe there (Input(Game + UI) + bShowMouseCursor) never worked properly in the original because of an issue with the sceneviewport:
After making the changes I mentioned in that post, my UE 5.1 Lyra project now works great with mouse visible and invisible during Gameplay.
Note that I had to use All (Game+Menu) input mode, since that is the only way to get CommonUI “Escape” key handling to work. It seems that the Game only UI mode is not useable with CommonUI, at least the way Lyra 5.1 has it hooked up.
An issue I encountered with Enhanced input is that opposite inputs are not really cancelling each other (like they used to do before).
If you use the default UE5.1 templates you can easily reproduce it: press A and D (or W and S) at the same time and the character will move instead of standing still. Do you know how to fix this?
I feel like all the additions are too specific to a certain project in mind. For example if you’d make something advanced like a DCS flight simulator (tons of curve control, double mappings, per vehicle files) you’d certainly be writing your own system anyway. But good to know where the engine is heading so I can adapt to the community needs.
Still, it’s been my best (non-Marketplace) option for universal widget interaction with different input devices. I’m not very experienced with UI stuff, so I’m only using the ActivatableWidgets and WidgetStacks for now.