Control on Gamepad fires Attack once, then stops responding

Development Platform & Builds
, ,
1

We are using UE version 5.21. We are using 100% Blueprints , and have no experience with C++.

We have developed the game Moroi. We have an issue that we can’t solve: When switching from KBM to Gamepad, and we press A (Use) the game fires the Attack (Attack is mapped to a different button than A) once, and then control stops working. You need to switch back and/or mash buttons to regain control.

We saw that the problem starts before execution goes into the Enhanced Input Action.

2

Steps to Reproduce

3

Good day, I have two suspicions of what is going on:

  • Either Gamepad A is pressing a keyboard focused on-screen UMG widget. Gamepad navigation lets you navigate UMG menus with directional buttons and pressing a menu button with A. If the game’s input mode is Game and UI, that’s what might be consuming A as a UI action.
  • Or CommonUI might be taking the Gamepad A input and processing it as a mouse click.

Both are issues that have been reported in the past. Do you know if any of these two explain what you’re running into?

4

Hi Zhi Kang, and thanks for the answer!

We have it like this: [Image Removed] The trouble is that both Input modes ( Game and Game & UI ) are being used. If I disconnect the Game & UI node, the bug does not happen any longer, but the ranged weapon stops working :frowning:

5

However, I think Common UI could also be a problem, this started around the time we implemented Common UI

6

Since CommonUI might be the problem, please take a look at the discussion here and see if the suggestions there help: [Common UI stealing gamepad buttons from enhanced [Content removed]

This thread also has suggestions to try: [EnhancedInputSystem vs CommonUI: always converts Gamepad face button bottom as Mouse left click [Content removed]

Can you check both out and see if your problem is the same as theirs, and try the suggested workarounds?

7

[Image Removed]This is chosen as the answer. From what I understood and “translated” into blueprint, it is checking if the command came from the Gamepad. I tried redoing it in BP:

[Image Removed]Is this the correct translation? If so, should we use this to check if the “rogue” command is registered as a click, but is in fact a wrong Gamepad command?

Thank you.

8

I believe translating that snippet to blueprint doesn’t help as ideally you want to have CommonUI completely ignore an input so it gets passed onto the game. I don’t believe there is a blueprint place where you can insert that logic.

I’m reaching out to a colleague who is more familiar with this problem. They may reply some time later.

9

Hi,

I’d recommend enabling the Slate Debugger (SlateDebugger.Start in the console) and reproducing the issue to get a better sense of what might be happening here. CommonUI does it’s own input swapping detection through a preprocessor which runs prior to anything else, but I don’t think that would interfere with your InputMode swapping here. It does sound a bit like the A button is causing a click event (which the slate debugger could verify), especially if clicking triggers an attack in your KBM setup. I’d keep an eye out for focus change events in the debugger to see where focus ends up after pressing A, as that will indicate which widget will receive all future gamepad input. We’d expect it to land on the viewport (since that’s where input is forwarded along to the player controller and processed as “game” input), but perhaps some other logic is moving focus elsewhere.

Best,

Cody

10

Hi , could you please advise further? We dont know how to fix this. Thanks!

11

Thank you Cody, we’ll most likely take the 2nd approach.

We use the controller to navigate, shoot, interact with menus, about everything ( Moroi is a top down hack’n’slash-shooter ), and the game can also use KBM.

Do you think if we use version 1, it would still be ok for us?

If not , version 2 it is :blush:

12

Hi,

The second option should work, since that event fires when the input method changes (compared to the Any Key event, which requires receiving a key event in your player controller).

13

I think we fixed it. Your solution seemed to work !

[Image Removed]

Thanks a lot, this was of huge help! :folded_hands:

14

Thank you very much. I think the best solution would be for a C++ wizard to modify some file (or teach me how to) and then me placing it in the game.

15

Hey Cody,

Good call on the Slate Debugger! We’ve reproduced the bug, and this appeared in the text:

[Image Removed]It shows correcly that the Gamepad button is pressed on the 1st line, but on the 3rd it also lists the LMB !

So this is the smoking gun.

Curious on how to proceed with this further.

Thanks!

16

Hi,

This will be caused by the second possibility Zhi Kang mentioned above, where CommonUI is simulating a mouse click. We do this by default to trigger hover states on buttons when navigating with CommonUI, so there are two ways to work around this:

  1. If you don’t need that features, you can disable it outright by unchecking “Link Cursor to Gamepad Focus” in your project settings
  2. You could try moving your “input method changed” logic to CommonUI’s InputMethodChanged event. You can access this in Blueprints through the CommonInput subsystem, and that event should fire and give you a chance to change the input mode a bit earlier. Once the input mode is set to Game Only, the virtual click from CommonUI should be unable to interact with any UI elements

There are also some workarounds where you can manually move the cursor if needed, but I’d expect one of those two approaches to work here. Let us know if you have any trouble.

Best,

Cody