How to get which Control Scheme is used in context.

In my game which is a top down shooter, I aim the player using the Right Analog stick on gamepad, and mouse on keyboard. Right now the only way I can think of to differentiate the 2 is have 2 actions "MouseAim" and "GamepadAim" and handle them differently. However both return a Vector2 and I was thinking it would be easy to have something like

Code (CSharp):

1.  
2. if(context.GetControlScheme() == ControlsControlSchemes.Gamepad){
3.     //do gamepad stuff
4. } else if(context.GetControlScheme() == ControlsControlSchemes.MouseKeyboard){
5.      //do keyboard and mouse stuff
6. }
7.  
8. /* Notes:
9. "Controls" is the name of my .inputactions asset so it generates the C# class "Controls"
10.  
11. If I named them like "Player" the enum would be "PlayerControlSchemes"
12. */
13.  

Or something to this effect, GetControlScheme() would return a "ControlsControlSchemes" that triggered the event. and there'd be an enum for each control scheme generated by the Controls. Even a string compare would work here where GetControlScheme() would return a string of the control scheme's name

Am I crazy to think this should be possible? Am I missing something in the unfinished docs?

Thanks for the help in advance!

 

The generated C# classes ATM actually do not really use control schemes. Much of what PlayerInput&InputUser do around control schemes right now has to be manually hooked up when using generated C# classes.

This means that even if you set up multiple control schemes in your .inputactions asset, the generated C# class will essentially ignore the data and just enable bindings from all control schemes and grab all available devices at the same time.

It is possible to hook up control schemes properly (there's nothing that PlayerInput does that you can't do yourself) but doing so requires some more extensive scripting. One way is to use InputUser yourself (like PlayerInput does) to get support for device pairing and action management including control scheme support.

Or, at a more basic level, you can set "bindingMask" to constrain bindings to a certain scheme and use "devices" to restrict the set of devices used at any one point.

Beyond 1.0, we hope to improve the code-generation path and get it both more integrated with PlayerInput/InputUser as well as equally featured standing on its own.

 

Awesome! Good to know, I mostly used the code generation just because didn't want to have to manually bind each function in my PlayerController to the Unity Events in the PlayerInput component, and I haven't messed with the "Invoke C Sharp Events" option on PlayerInput, so I'm not sure how that works. That said it's definitely an improvement over the previous input setup, and looking much better than the initial preview release, so I'm happy to see it's still evolving! Thanks for answering my question!