I think now's a perfect opportunity to leave a copy of a comment I posted on one of Brackeys' New Input system videos several months ago (note that this implementation is built around the "Generate C# class" option and interfacing with your input directly in code like what Jason did in his previous New Input system video when it was still in preview):
I'm sure there are at least a few users watching this wondering how to go about setting up multiple unique controllers for co-op/local multiplayer, and keeping any given input asset instance from receiving input data from EVERY SINGLE active device. Having struggled to figure this out myself months ago, especially since I also wanted to make it work with the auto-generated C# class feature as well to take advantage of all the safety features C# provides when working with it, I thought I'd share the solution I came up with, which uses a lesser-talked about feature of the New Input System called Input Users (note that in my example, "InputReference" is the name of the input action asset and by extension the C# class):
using UnityEngine.InputSystem;
using
public class Player
{
public readonly InputReference Input;
private InputUser User { get; }
public Player(params InputDevice[] devices)
{
Input = new InputReference();
User =
for (int i = 0; i < devices.Length; i++)
InputUser.PerformPairingWithDevice(devices[i], User, i == 0 ? :
}
public void Decommission()
{
}
}
With this class, I could create a unique Player object for each active player. Notice in the constructor that in addition to the input action asset instance, an InputUser is also created, with which the input asset instance is then paired. Once that's done, each input device passed in to the constructor (the params keyword allows for any number of devices, letting me pass in, say, either a single controller, or a keyboard and mouse as a pair), is also paired to the InputUser. Now, the input asset instance will only receive events from those specific devices_, which lets me register for a specific player's move/jump/whatever as opposed to _every player's move/jump/whatever and then needing to figure out which device it originated from.
Note there's also a decommissioning method, to clear the user and pairings out if you need to deactivate a player. This will ensure device pairings, input user entries, and other behind-the-scenes things get cleaned up when you no longer need them.
MasterofGalaxies
I tried using it, but I kept running into issues that I couldn't figure out. I got frustrated after like 4 days of trying to resolve a simple issue. Granted I'm newer to unity development, but it felt like the old input system was much friendlier and easier to use for a new developer.
lanceroygames
The "new” input system is definitely a great improvement. Porting games to consoles with different controllers is great. Just add inputs to the actions and it should work as the code is just interested in the actions. I was involved in adding hand tracking to a VR-game recently where we created a virtual controller that translated gestures to button and sticks, then mapped that in the input system along with the ordinary control inputs.
xmobilisx
The new input system looks great. Would love a video going more in-depth on the other features.
leondepaauw
Thank you very much, saw a few other tutorials before and this was very straight forward to me. Been so used to the old input system but the new one seems very powerful to customize and use for multiple inputs
BNTO
Would be really cool to see your take on a Input Manager class using the New Input System, something that handles inputs for the entire game.
alif-fgd
Thank you for this video!
Brackeys had a video on this, but it's from 4 years ago and the system seems to have worked a bit differently back then.
BenightedAlizar
Thanks for this! Would love to see a vid on a deeper dive of the new input system!
ffs
Amazing, Thanks for showing how simple it is!
MrNewRevolutionary
Definitely curious about the player input manager system you mentioned!
djiuetr
Thank you for explaining this in a detailed and simplifying way. I'm developing a 2d narrative stealth adventure which has a lot of different inputs in a lot of scripts and managers, not just player movement and the documentation and other tutorials were totally over my level of development skills. This helped me a lot, due to the fact that my inputs are fairly simple but I just wanted to have an universal gamepad button layout. Cheers!
gbezjak
The problem I have with the new input system is that it turns three lines of code into a 1 line + 5 setup steps in unity. It seems to be ideal for some use cases but I don't see how that workflow makes the overall development experience better. Maybe it makes way more sense if you need the new features.
tetryds
i tried to switch a couple of weeks ago but was a mess in my head, i mix all the different methods, if u can explain in a really easy way i will be grateful :)
leo
I'll have to take your word for it, investing in some assets from black friday sale.
ZoepX
I switched to the new input system a couple of years ago and I really love having all the input actions and bindings in one place. Also if you want to support keyboard and gamepad controls, it is incredibly useful as you can also define a deadzones for the gamepad sticks and don't have to do this every time per code.
Having the actions defined in a single place also allows for easier rebinding and displaying of the bindings. There is a tool for the new input system I made on the asset store, called Input Icons for TMPro which allows you to easily display your action bindings in textmesh pro texts. It is quite handy as it automatically updates the displayed icons when you switch devices.
tobiasfroihofer
One annoying problem I ran into on the new Input System is gated controls, what I mean by that is, for example, ctrl+S. If you have a control which uses S for something, and you have one which uses CTRL+S, if you press CTRL+S it doens't block the S control from working, so basically two actions happen at the same time.
You can code it yourself by locking the controls off using IF statements to make sure the S only control doesnt fire if CTRL is being held, but the new system should do this itself.
mintydog
Thanks for a great and succinct walkthrough of this. Quick and to the point and helped me get cut over to the new input system, which is way better for a number of reasons IMO. Much appreciated!
zenmikey
Thanks! It's the trigger I needed to take a closer look :) Seems to be useful!
niederbayer
100% interested in the player input manager system. would like to see as much as I can on the input system. it seems very powerful but there is only so much content on its alternate use cases.
clarkmeyer
I like the new input system, makes mobileinput a lot easier. A video on coop and splitscreen would be nice.
