Hello Epic.
Are there any Plans to fix the Gamepad D-Pad for firing in UMGs?
I mean this: Unreal Engine Issues and Bug Tracker (UE-28825)
Sure, there‘s a workaround via overriding the KeyDown function. But a Workaround isn‘t a solution.
More than 2 Years a Bug.
I hope for some Fix in the near Future.
Hi, I have looked at this issue and determined it is working as intended (by design).
The keyboard arrow keys and the gamepad d-pad are hard coded to be used for UMG navigation (plus some other buttons like enter/space/…). Basically the button or other widget that has focus in the viewport eats the input before it gets to the widget blueprint overridden OnKeyDown function. Should you want to use those keys/buttons, you will need to do your logic in On Preview Key Down as illustrated below/attached (but need to return Handled instead of Unhandled to eat the input);
I hope that helps. Cheers,
So there is no way to use them with Input Keymapping in the Project Preferences?
Cause every Action Event with D-Pad isn´t firing on hit.
Dpad keys set as action events should be fine as I always use them. It might be that they don’t work when in combination with Input mode UI (untested by me).
In Input Mode UI only, only the UI-fired (OnKeyDown) evets are fired as far as I can tell. D-pad, Face Button Bottom, Arrow Keys and Enter are handled somewhere up the hierarchy so those will be beyond reach in the widgets, unless you do it on OnPreviewKeyDown. This, however, destroys the navigation system up in the hierarchy, so you have to make your own.
With input mode Game and UI, you can access all commands from the player controller and fire events in the UI. However there are some issues like timer handles not triggered when the game is paused, so if you want to repeat the events while inputs are held down, well, prepare for some blueprint spaghetti.
Hovered and Focus aren’t tied together in most ways, I think there could be an intermediary state “selected” to handle the focus in a more discrete way, especially for menus where no complicated interactions is needed. This would remove the need of doing polling to update the UI with keyboard unless you do what Epic does with Fortnite.
Also, if you change the background color with focus and want to drive the UI animations only with that, you still run into the issue where if you select something and then hover on top of it with a mouse, the hovered color will be applied on top of what you set as the focus color. There is seemingly no way to disable the hovered color changes in the editor.
The way how Epic handles it in Fortnite is by only allowing players to use either mouse or gamepad, keyboard use is very limited. What they do is that when you use a gamepad, the mouse cursor is hidden and moved on top of the selected item. If you make a few selections with a gamepad and then move your mouse, you’ll notice that the mouse will be on top of the selected element. So, the gamepad “selection” will use the hovered color, just with an invisible cursor.
You can get the location of an object in the canvas by using Slot as Canvas Slot, well, to some extent at least. The issue is that for any objects instead of a vertical box and whatnot it sends a null value (0,0,0) (EDIT: if it is not directly a child of canvas it does not get the value). If you want to get it done in blueprints I’d wager moving all the buttons where you want them to be, programming separate logic (maybe even navigation with OnPreviewKeyDown) for gamepad and then moving a hidden mouse cursor appropriately, and not allowing WASD / Arrow navigation.
Sliders are also weird, you can navigate on top of them easily, but they require additional “capture” to active the slider for gamepad / keyboard. You need to also release the slider if you want to get out of the slider mode with arrow keys and numpad keys, but surprisingly, not when you are using the left thumbstick (which is the easiest to accidentally mess up especially with little to no leniency in deadzoning). The Fortnite 3D scale slider does not work this way. I’d probably emulate it with a hit test invisible progress bar, under which there is a non-keyboard focusable slider, and simply have some command to emulate the slider when there is a horizontal gamepad input.
It would be better if the navigation keys were at least editable, and there was more documentation on the system… but dunno. Any of the approaches that doesn’t involve modifying the system at a deeper level seem to have their own quirks you’ll end up having to deal with.