[4.10.1] "Set Input Mode Game and UI" locks input for a second player in splitscreen mode

Branch: ‘Binary’, vanilla version from Epic.

Build version: 4.10.1-2791327+++depot+UE4-Releases+4.10

Detailed description of the issue: “Set Input Mode Game and UI” locks input for a second player when in splitscreen mode.

Expected behavior: Second player input is not locked by “Set Input Mode Game and UI” call.

Repro Steps

(“Player#” means player controller reference, obtained through call of “Get Player Controller #”, where # - is a number)

  1. Prepare a setup with 2 player controllers, with split screen enabled (vertical).

  2. Create a fullscreen widget “TestWidget” with a “TestButton” button within.

  3. Instantiate “TestWidget”, specifying the Player0 as an owner.

  4. Add widget “TestWidget” to the viewport

  5. Call “Set Input Mode Game and UI” for Player0 with TestWidget’s “TestButton” as a focus target.

  6. Remove the instantiated widget from the viewport.

  7. Observe that Player1 input is ignored, while Player0 input is working properly

  8. Adjust the setup so the “Set Input Mode Game and UI” is called for Player1 after the widget is removed and observe that it doesn’t solve the issue

  9. Adjust the setup so the “Set Input Mode Game Only” is called for Player1 after the widget is removed and observe that it solves the issue.

Repro rate: 10/10

System Specs: Windows 7, 64-bit. Connected input devices: 2 Xbox One controllers, USB keyboard, USB mouse.

Hello Crio.Kpekep,

I was unable to reproduce this issue on our end after creating an example base on the steps provided. I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide any steps that may have been missing from the original steps provided?
  3. Could you provide detailed information on how you have your controls setup for handling the individual character inputs?
  4. Could you provide screen shots of any blueprints that may be involved with this issue?

Hello Rudy,
Thank you for a prompt response.
Unfortunately I am out of the office till 7th of January and can’t provide you with the proof setup. If it is possible, please wait and I will provide an archive with example.

Hello Crio.Kpekep,

I wanted to update this thread with reminder of the need for additional information. I will be happy to assist you further upon your return around the 7th of January.

Hello Crio.Kpekep,

We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will offer further assistance.

Thank you.

I have the same problem. I may have found the source of the issue, when creating a widget, you have to set one player as the owning player, which ever this is, the other players input is blocked somehow when the widget is selected, using the mouse. This happens even with the “set input mode game and UI” node used on the event construct of the widget. Note that the additional player is index 1, the cursor is visible and obliviously controlled by controller index 0. The problem happens when the ui is selected by being clicked on, at this point only the input from controller 0 gets through to the game. Once the game is selected again, all input works as is should.

Hello The Cheese Dragon,

Would it be possible for you to provide an example project that reproduces this issue?

I have found another way, the problem arises when the mouse clicks on the widget. At that moment the other player is unable to receive input, however since it is a local multiplayer game one player would have to be able to interact with the ui without a mouse anyway so (as I should have done before) I have decided to keep the mouse hidden and have created functionality to interact with the menu with half the keyboard or a controller instead.

I’m happy with my solution so you can mark this as answered unless someone else comes along, thanks.