Legacy Input Manager VS. New Input System Package

I've been trying to research both input systems Unity has made (the legacy input manager and the new input system package) and decide which one I should use in my game. Some info about my game; it's going to be a four player split-screen multiplayer game that I'd like to release on Steam (and the Nintendo Switch, if at all possible), and I've already written a script that reads input values from the legacy input manager (via GetAxis and GetKey) and then invokes Unity Events with said values (though I haven't implemented a way to remap/save remapped controls yet). But from what I've seen, the new input system looks like it's more intuitive and has more features (hence why I'm considering switching over).

These are my main concerns/questions when it comes to switching/not switching

1. Like I said above, I've already written a system that works great for reading input based around the legacy input manager, and I'm not quite sure what would be the best way to re-write it to work with the new input system. I've seen some stuff about ReadValue<T> and ReadUnprocessedValue<T>, but I'm not sure about the best way to get a reference to a control to do that.
2. How would you make sure that every player's character moves separately? Is that handled automatically? Would I have to use their "PlayerInput" component to do that? I haven't really been able to find out anything about that in the manual.
3. One of the assets I'm using (Naninovel), says that the minimum supported version of the new input system package is 1.1, which isn't verified with my version of Unity (2020.3.19f1). Is it a big deal to use a version of a package that isn't listed as verified?
4. If I don't switch over, I'd need to figure out a good way to let the players remap their controls (I don't think that I'd have any problem figuring out how to save it once I figured out how to do the remapping). Would I need to make 112 input axes in the input manager? (28 input axes to choose from in the drop-down in the input manager X four joysticks/players) Also, I've noticed that there are some axes that respond to the same things on the controller that I've been testing with, and there are others that don't seem to respond to anything, and so I'm not sure if I should exclude those axes from any input checks, or if it would respond differently depending on the controller/platform. For example, my setup is an Xbox controller on Windows, and the 3rd axis responds with a negative value when I press the LT on my controller, while the 9th axis responds with the same number only positive, but if someone had, say, a Playstation controller on a Mac, would the 3rd axis still respond with the inverted value of the 9th axis when they press their controller's equivalent of the left trigger? Or could it correspond to, say, up/down on their D-Pad? The whole thing of just assigning inputs to things like "axis 15" or "axis 5" instead of something more like "right stick left/right" makes me a little worried about that sort of thing.
5. I've seen something under the limitations section of the manual for the new input system that says "PlayerInput split-screen support does not work with Cinemachine virtual cameras". I'm using Cinemachine virtual cameras in a split-screen setup, so will the new input system not work with that?
6. If I don't switch over, is there any way to make the controllers vibrate/rumble with the old input manager?
7. Do both the legacy input manager and the new input system package work with Steam and the Nintendo Switch? Does one work better with the aforementioned platforms than the other, or are they both about the same when it comes to compatibility?
8. With either system, what would be the best way to show controls on-screen? Something like "Press B to jump" when using a controller and "Press spacebar to jump" when using the keyboard.

In short, is it worth it to switch over to the new input system package even though I've already got a (sort of complete) system built on the legacy one?

 

Does anyone have any advice about this? @Rene-Damm? @Schubkraft?

 

IMO, if you have something already up and running and it works and does the job, no need to switch.

Not necessarily. PlayerInput is a high-level wrapper around stuff but it does nothing that you can't do otherwise and it comes with its own problems. But to get started, usually the quickest way. Each instance of PlayerInput is its own separate player with isolated controls and separately paired devices.

No. Strongly recommend 1.3 over 1.1 regardless of verified status.

Strongly recommend not trying to make custom remapping thing work with the current

UnityEngine.Input

API. World of pain.

Recommend holding off. Sounds like you're already pretty far in and have something working.

Roadmap-wise, our intention and focus is to do away with the dilemma here and remove the dichotomy of new and old input entirely.

 

Thanks for the response and advice, @Rene-Damm. It was very helpful. I do still have a few other questions though:

Is the legacy input manager compatible with Steam and the Nintendo Switch?

Is it possible to make controllers vibrate when using the legacy input manager? If so, how would I do that?

Is the legacy input manager consistent across platform-controller setups (at least across the platforms/controllers that Steam supports)? I notice that there are some input axes that don't seem to do anything, which makes me wonder if different controllers/platforms register input differently with the legacy input manager (and therefore could have unexpected/undesired behavior when someone goes to play my game with a setup that I haven't tested).

Also,

Does that mean that you're planning on getting rid of the legacy input manager? Would that affect my project?

 

Compatible with Steam depends on what you mean by that. There's no support for the Steam Controller API but it works when run from Steam just like any other game does that has no specific Steam support.

Switch support is available for licensee holders. There's no support for Switch controllers on desktop.

No support for that except on consoles.

No, there's no consistent mapping between controllers and/or between platforms.

We're planning to support the legacy API through the input system. So, you'd be able to just continue using

GetAxis

etc. but you'd get consistent mappings, rebindings, virtual input, and such at the same time.

 

So the legacy input manager isn't consistent even between different kinds of computers? Is it just the axes that are inconsistent, or are the KeyCodes also like that? Are the keyboard-related KeyCodes consistent at least? What about if someone isn't using a Qwerty keyboard?

Is the new input system package consistent? Is it compatible with all the Steam-compatible platforms and the Nintendo Switch? Can you make controllers vibrate with the new input system package? Would there be any issues with using both the legacy input manager and the new input system package at the same time?

Do you have an ETA for that? What version(s) of Unity/the input system package do you think it would apply to?

Thanks for the help, @Rene-Damm.

 

To the extent of different kinds of devices and platforms and combinations thereof, yes.

KeyCode mapping is locale-dependent and thus sensitive to the current keyboard layout.

QWERTY will move around according to the current keyboard layout. Some time ago a setting was introduced to enable physical keyboard layout mapping.

To the extent this refers to gamepad mappings and key mappings on keyboards, yes.

Yes.

It's supported.

Too early for an ETA. We are actively working on it though.

Version 2.