Unexpected Input Switching Between Gamepad and Mouse in UI After Upgrading to Engine 5.6

Development Programming & Scripting UI
, ,
1

We’ve had an issue across our UI since updating the engine to 5.6.On many screens (e.g. our in-game menu containing a list of buttons), switching between gamepad and mouse causes control clashes. Navigating through the menu with the gamepad causes the mouse to regain control each press and jump to another button (even though the mouse is never physically moved).After digging into the engine code, we discovered we could prevent this flitting between controls by making a small change to the common input preprocessor to have it ignore the mouse move events for a frame after pressing any pad buttons:

`bool FCommonInputPreprocessor::HandleKeyDownEvent(FSlateApplication& SlateApp, const FKeyEvent& InKeyEvent)
{
const ECommonInputType InputType = GetInputType(InKeyEvent.GetKey());
if (IsRelevantInput(SlateApp, InKeyEvent, InputType))
{
if (IsInputMethodBlocked(InputType))
{
return true;
}

// [hexworks] >> ignore next mouse move event so control doesn’t switch away from gamepad.
bIgnoreNextMove = true;
// [hexworks] <<

RefreshCurrentInputMethod(InputType);
}
return false;
}`Is this a reasonable change and have you had this issues reported for other devs? It may be that we’re experiencing the problem as our UI is a hybrid of legacy systems and CommonUI (or, perhaps, we’re doing something else wrong you could advise on).

2

Hi,

That seems like a reasonable enough workaround, though it may be worth trying to track down a root cause since it seems like mouse inputs are coming through and being processed unexpectedly. I haven’t seen other reports of something changing here, but we’re still fairly early in the 5.6 release cycle so it’s tough to say how widespread it may be. You might try dropping a breakpoint in UCommonInputSubsystem::SetCurrentInputType to see if you can catch the moment when it unexpectedly tries to switch to mouse+keyboard, that callstack might give you an idea as to what’s going wrong.

Another thought would be to try disabling Slate.EnableSyntheticCursorMoves, I wouldn’t expect that to be a problem since it’s on by default but it’s worth a check.

Best,

Cody

3

Thanks, we will apply then the code change and also check out what you propose.