Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

PlayerInput vs InputActionAsset

Discussion in 'Input System' started by BorjaFAC90, Aug 11, 2020.

  1. BorjaFAC90

    BorjaFAC90

    Joined:
    Jul 21, 2020
    Posts:
    8
    Hi all,

    At the moment I am dealing with the inputs for keyboard+mouse and gamepad for a game, and I am using the new input system for the first time. I have seen that there are different ways to use it, and I have some doubts about the usage of the PlayerInput API and the optional InputActionAsset C# class that gets generated after setting up bindings.

    As far as I know, the PlayerInput is a wrapper intended to give more control and features to the input system, and (potentially) resulting in less code. In the other hand, using directly the InputActionAsset C# generated class you have the "raw" input, but if you want some features like autoswitching the scheme when an input from another device is executed, you have to do it by yourself.

    So far, I've been using the InputActionAsset class by creating an instance of it, and hooking up the events of my actions to some functions that handles those inputs.

    Then, I tried the PlayerInput so I can use the AutoSwitch option for the scheme and for having support for rebinding my inputs by the player, but I see that now I can't reach the events directly, and I need to find them by string (with FindActionMap("mapName").actions), and iterating over those actions, with a big switch statement checking the names of the events, just to hook up that input action (started, performed or canceled) to the function that I want. I think this is completely ugly. Another option is binding the events by editor, but my entities will be generated dynamically, so I can't do that. The last option is using the messages with functions that receives the InputValue instead of a CallbackContext, but I think that's even uglier and dirty...

    Am I doing something wrong? What approach should follow?

    PD: for more info, the game is a TPS that will support keyboard+mouse and any kind of gamepad, so I guess I will need a scheme for keyboard+m, and another for gamepad. And also an action map for UI controls and another for gameplay controls. Am I right? Is this correct?

    Thanks for reading me!
     
  2. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    ATM it's an either-or kind of deal. With PlayerInput, you loose the code generation aspect but gain a more well-rounded feature set. With the generated code, you get a simpler overall setup but lose some functionality compared to PlayerInput.

    We're looking at ways to bring the two approaches closer together. Not sure PlayerInput will directly work together with the the generated wrappers at some point but there's no good reason that the generated code couldn't directly support some of the stuff that PlayerInput is currently doing.
     
  3. BorjaFAC90

    BorjaFAC90

    Joined:
    Jul 21, 2020
    Posts:
    8
    I see, I will go with the PlayerInput for now then, I think I can handle some strings without dying too much from inside xD.

    Thanks for the answer!