Search Unity

Easy way to get "Next Button Press"?

Discussion in 'Input System' started by Marscaleb, Jul 8, 2020.

  1. Marscaleb

    Marscaleb

    Joined:
    Jan 7, 2014
    Posts:
    1,037
    Does this new input system have a simple function for retrieving the next button press?
    I want to use it for assigning controls in-game. When prompted, the player presses the button they want to assign to a given action.

    With the old system I had to set up a bunch of custom code to check every possible button for being pressed on that frame. Do I have to do that again or is there an easier built-in function where I can just receive whatever button the player presses next?
     
  2. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Code (CSharp):
    1. ++InputUser.listenForUnpairedDeviceActivity;
    2. InputUser.onUnpairedDeviceUsed +=
    3.     (control, eventPtr) =>
    4.     {
    5.         if (!(control is ButtonControl button))
    6.             return;
    7.         Debug.Log("Button pressed: " + button);
    8.     };
     
  3. Marscaleb

    Marscaleb

    Joined:
    Jan 7, 2014
    Posts:
    1,037
    I... don't understand this code. But that comes down to my understanding of C# and programming in general. I suppose I would be better off to ask my questions about that elsewhere.
    Thank you for the reply.
     
  4. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    To give some more context, the InputUser API has functionality to listen for when a device is used that isn't paired to any InputUser. The listening comes with a noticeable overhead (there's a change pending that reduces the overhead but it's still an overhead) so it has to be enabled manually. This is done by

    Code (CSharp):
    1. ++InputUser.listenForUnpairedDeviceActivity;
    It's a counter. The feature is enabled as long as the counter is positive.

    When InputUser detects the use of an unpaired device, it will invoke the onUnpairedDeviceUser callback. This is what the second part hooks into. It installs a delegate in the event so that when the callback happens, the delegate is called.

    The callback receives the control that was used and the input event that contains the input that triggered the callback. The event pointer you can usually ignore. The control is something like, for example,
    Gamepad.buttonSouth
    .

    So, the first line in the delegate checks whether the control was a button or not and ignores the callback if it wasn't.

    After that check you know that a button was pressed.

    A simpler one line wrapper API is on the TODO list.