The new input system. ???

So I thought I'd give this a go.

Confused? Yes I am.

I've just about got the hang of the input setup screen where you assign keys, but I can't get any input from a controller working at all, I can with the old system, although that's a pain as well.

I've downloaded a load of "Simple" samples, simple my arse! Why make these samples do so much? I just want a VERY simple sample that shows getting an input. Also the samples I've downloaded all seem to use LowLevel, none of the tubes I've found use LowLevel.

Could we please, please have the most simple of simplest examples of getting an input from a controller? I don't want graphs, I don't want flashy boxes, I don't want moment, just please put a value in a variable!!

Rant over.

I must admit I'm pretty new to unity and c#.

Does anyone have a sample as simple as this I could have a look at? Please!!

Many thanks.

 

i had similar problems and am using old system, but in truth i have not tried new system properly. There is someone called 'brackeys' who may be able to help with tutorial.

 

The following code assumes you've created and attached an input action asset to the script in the Inspector, and that the asset has an action map named "Gameplay" and that it has the actions "Movement" and "Fire".

Line 25's

ReadValue<Vector2>()

is essentially the same as

GetAxis("Horizontal")

and

GetAxis("Vertical")

.

Code (csharp):

1. using UnityEngine;
2. using UnityEngine.InputSystem;
3.  
4. public class Player : MonoBehaviour
5. {
6.     public InputActionAsset playerControls;
7.  
8.     private InputAction movement;
9.     private InputAction fire;
10.  
11.     private void Awake()
12.     {
13.         var gameplayActionMap = playerControls.FindActionMap("Gameplay");
14.  
15.         movement = gameplayActionMap.FindAction("Movement");
16.         movement.performed += OnMovementChanged;
17.         movement.canceled += OnMovementChanged;
18.         movement.Enable();
19.  
20.         fire = gameplayActionMap.GetAction("Fire");
21.         fire.performed += OnFireChanged;
22.         fire.Enable();
23.     }
24.  
25.     private void OnMovementChanged(InputAction.CallbackContext context)
26.     {
27.         var direction = context.ReadValue<Vector2>();
28.  
29.         // Code that moves the player based on the direction
30.     }
31.  
32.     private void OnFireChanged(InputAction.CallbackContext context)
33.     {
34.         // Code that fires a projectile
35.     }
36. }

 

Who thought this was a good idea?

 

To be fair there is a far easier way to access the control state if you don't care about features like rebinding controls.

Code (csharp):

1. if (Keyboard.current.space.wasPerformedThisFrame)
2. {
3.     // FIRE
4. }

Code (csharp):

1. if (Gamepad.current.aButton.wasPerformedThisFrame)
2. {
3.     // FIRE
4. }

 

is the asset package 'rewired' any better? does anyone know.

 

I personally found rewired to be more difficult than the new input system.

 

am i wrong in thinking there is nothing wrong with old system, or am i getting myself into trouble down the line?

 

There are no benefits to learning the old system at this point in time. Everything that you were able to do with it can be done with the new input system, and unlike the new input system the old one has no advanced functionality for when you need more it. Want rebinding on the old system? You'll have to build your own rebinding framework on top of it.

 

I've been using it since 5.6 and was able to do everything I wanted, but I only do windows and linux, dunno about consoles.

 

They made a property for every key? This is nuts.

Actually this seems to be awful through and through. Looking at Gamepad configuration:
https://docs.unity3d.com/Packages/c...ngine.InputSystem.LowLevel.GamepadButton.html

Someone thought that gamepad has fixed number of buttons.

 

Ready for some more? There are at least four major ways of accessing input data. My first post showed the most complex method. Unity themselves show one of the intermediate methods in a blog post (first link) with the second intermediate method being the option for the input action asset to generate a C# class (second link).

https://blogs.unity3d.com/2019/10/14/introducing-the-new-input-system/
https://docs.unity3d.com/Packages/c....html#auto-generating-script-code-for-actions

Remember the basic approach I posted earlier?

Code (csharp):

1. Keyboard.current.space.wasPressedThisFrame

Here's a variant using an enum.

Code (csharp):

1. Keyboard.current[Key.Space].wasPressedThisFrame

Here's a variant using a string.

Code (csharp):

1. ((KeyControl)Keyboard.current["space"]).wasPressedThisFrame

 

It's not that you won't be able to access the rest of them, they just created helpers for the common ones.

 

My opinion so far:

"So we decided to address that and took inspiration from simplicity of japanese writing system."

I didn't dive in very far, but on surface this seems to be horrible and worse than EventSystem for GUI.

Few scenarios off the top of my head:

* Let's say the user is using korean keyboard and I want to detect keypress of "ㅂ". Now what?
* The user is utilizing unbranded usb clone of Sega Genesis gamepad. Which button is which?
* My gamepad has 4 analog sticks and 28 buttons. How do I access them?

I understand the need for low level API and polling, and abstraction for input device makes sense. But, I don't dig the layer at the very top with limited enums.

 

You can download the free Rewired trial version and get a good overview of how Rewired works first hand without spending any money.

https://guavaman.com/projects/rewired/trial.html

One of the features I like about Rewired is the huge number of controllers that are supported. The most important part of the number of controllers supported is that the developer has hands on experience with 98% of the controllers. That makes it so much easier when you ask a support question and get a informed response on the controller.

https://guavaman.com/projects/rewired/docs/SupportedControllers.html

The best thing you can do is evaluate both solutions and see what works best for you.

 

You can do all of that with the new input system for free. No trial - just free.

"unsupported" controllers will still be accessible by axis and buttons, just a bit more hassle.

 

"A bit more hassle" is a bit of an understatement, because you eventually will likely need to purchase those controllers (especially ones that aren't xinput derived, especially if you're not only targeting Steam with its internal controller compatibility helpers) to test them in the first place. You can not rely on the idea (nor should you bank on the possibility at all) that you can collect this data from the userbase. There is a monetary and technical cost that comes with having to manually add controller support outside of the most baseline.

 

So... what do you all expect them to do with "unsupported" controllers? Clearly the more they can support the better, but they probably can't get 100% coverage and still need to do something for the rest.

Assuming that functionality is present to allow runtime custom mappings then isn't that the solution? Ask the user to map what buttons they want for each action?

I like Rewired too, and only moved away from it while cutting down on 3rd party dependencies. I had a pretty big project ported over to use the new Input System instead in less than a work day, having never looked at it before. So far my main gripe is with the documentation. The system is straightforward enough to use, but figuring out which bits are relevant to you is a bit of a pain the first time through, because they provide multiple ways to do things and no clear "approach X is best for cases where Y".

 

Honestly? There's not a lot of them to worry about.



Xbox 360 and One support is just Xinput. PS4 is handled through the Steam controller system on that front and the most common drivers for it and PS3 both effectively work as Xinput emulators. That's 92% immediately covered even if you're not targeting Steam as a platform. 2.15%ish of the "other" is the Steam Controller, which is already effectively user mapped.

We can rule out, generally, Rockband instruments and "everything else."

The only real concern here is the 2.15%ish using "PC gamepads," which is a broad scale compatibility nightmare because it includes any manner of HID gamepad setups, often with very little standardization and, at last check, are often not at all easy to detect with the new input system.

Also important to note is that this graph (from 2018) is not exclusive ownership. Many people in the edge case categories likely also own other controllers, as the amount of gamepad using accounts (at time of article) was "over 30,000,000," but there's 27,200,000 using 360 pads.

That said, the big thing about Rewired is that it'll get you that extra compatibility for essentially free (you still have to buy it and use the automapper), while the new input system is putting that onus on the developer in a more direct way. Rewired also has the benefit of a lot of fantastic documentation alongside its active development. Even with the new input system being free, there are other costs to consider and I firmly believe that Rewired handles those very well.

 

I'd also be concerned about people with custom designed "accessibility" controllers. I've only seen a couple in the wild, and both happened to be based on Xbox gamepads, but I don't know how commonly that's the case. If relevant that's the kind of thing where an engine vendor handling things centrally can give a direct, positive impact to often overlooked minority groups.

 

Accessibility controllers are basically one of those things where there are a couple of standards out there, but if you want to support them in any capacity, you're going to have to do in-house testing already because there's a lot of considerations to be made, as even the Microsoft one has expansion capability that may require special consideration. For instance, some people use a breathing tube for button inputs, but they may also use them for axis inputs.

When you get into accessibility controllers, you're getting into something where you have to go through a lot.

 

Surely that's handled on their end and we just receive it as input from an arbitrary button or axis though?

 

Same way you do in the old system. If we're talking Korean keyboard layout as you find it on Windows, there is no [THAT CHARACTER] key (forum is being very peculiar; won't let me include the actual character...). The key is Q like on the English keyboard. The ㅂ character is IME text input. So that input comes through only in text input.

To get input from that key, you'd bind to Q. To get it as text input, you'd go to Keyboard.onTextInput.

You could bind to the key that generates the ㅂ character using ("<Keyboard>/#{ㅂ}") but there is no key in that layout that does that, so the binding wouldn't actually catch anything.

By the nature of the beast, we can only guarantee that mapping for gamepads that we specifically support or where the underlying API we use guarantees that mapping for us. Unlike in the old system, we do make that guarantee, though, for devices we surface as Gamepads.

At this point, the set of explicitly supported gamepads and joysticks is still rather restricted. It'll grow over time. Though I suspect that it'll remain true that the best solution for having a fallback to cover arbitrary HID gamepad/joystick/whatever is still user rebinds.

The enums in the example are for key codes. On a PC keyboard, there is a more or less fixed set of those keys. The enum acts as a fast identifier for these standard keys which are identified by location (i.e. Key.A is the identifier for the *physical* key in-between Caps Lock and the S key regardless of which keyboard layout is employed). Keyboard devices, however, are not restricted to having keys only from this set. If you have a keyboard with 1024 keys, you can create a device for it.

If it's not explicitly supported, the buttons and axes will be surfaced as generic controls as described in the HID descriptor of the device. You'll have button1 (comes out as "trigger"), button2, etc. and axes like rx, ry, etc. x and y will be turned into a stick. Hatswitches will be represented as dpads.

Code (CSharp):

1. // Look them up by name.
2. joystick["button2"]
3. joystick["rx"]
4.  
5. // Grab all buttons.
6. joystick.allControls.OfType<ButtonControl>()
7.  
8. // Or only at toplevel.
9. joystick.children.OfType<ButtonControl>()
10.  
11. // Bind to them from an action
12. new InputAction(binding: "<HID::MyDevice>/rx"); // Or "<Joystick>/rx" or just "*/rx"
13.  

Some way to go here. Became more painfully obvious as we went. The system very much grew bottom up and with an eye towards along the way not railroading users into a "one option or no option" kind of deal. But we (me specifically) were pretty late in realizing that at the very toplevel, we need a single, clearly illuminated, no fuzz path. Which, at the very least, led to plenty confusion around what can and what cannot be done easily and how (and also to some things that *should* be easy but aren't yet).

Anyway, we're chipping away at it. But it is clear to us that we're still some way from the "pick it up and it's pretty obvious" level we want to be at.

 

Thanks for the in-depth reply, greatly appreciated and I am sure appreciated by everyone else in the thread

 

I’m not really sure what all the ire is about. So far the new Input System seems far and away superior to the old system, and more straight-forward than Rewired.

The documentation is pretty poor, but if you’ve been using Unity for more than half a minute, you should expect nothing more (documentation is a constant gripe of mine, but also writing and maintaining documentation sucks).

Given the ease of using actions and binding/rebinding keys to those actions, given virtually any input device, anything can be bound to anything by the end user without much though (so long as you create a UI for user bindings, which you should).

 

i wish I had known this before I spent the past three days setting up a character controller, and then while following a lighting tutorial discovered build settings.. smdh

 

Re-wired is amazing, I hate unity's new system. HATE HATE HATE it... re-wired simplifies everything!

Re-wired is so well documented and EASY to use... no screwing with cumbersome syntax, no strange errors, nothing you can't lookup in the manual or ask about. I learned this new input system months ago, tired it again a month later...jury rigged it to work, changed ONE thing and boom, game broken. Changed it back.... game STILL broken. WHAT? This is unacceptable in Unity in 2021. Re-Wired uses the same system, the same way, period. Easy Syntax, looks like unity's old system. Easy to work with, no confusing events... don't need a metric ton of inspector work to get it going, you plug and play.

 

To be fair, you don't need a metric ton of Inspector work to get Unity's new one going, either. Unfortunately the documentation is... lacking... so it's hard for someone new to it to clearly identify the different approaches to using it.

I am guessing that you changed something in your input asset?

 

Hmm. @VRKid , I bet you changed your input to be handled by the new system, didn't like it, and tried to change back, but then it gives you errors. Happened to me. It's because your project still has the new input system package imported. You have to go into your package manager and remove it. I may have had to delete the package folder from the project folder also. I remember having to do that for a couple packages I removed. This may or may not have been one of them.

Also, if you are building a UI for the end user to remap the bindings themselves, which I have done before in the old input system, then what part does the new system even handle for you? I was confused that they even came out with a new system until I saw the bit about supporting custom devices. That makes sense. As far as input remapping goes, it wasn't that hard before. Hell, building the UI took longer than programming it. I just made a Settings class and it stored a keycode for each action. If the action might need an axis input, I even gave the user the option of using an axis from a gamepad or the mouse movement or to use a positive and negative key/button pair. All this, in the old system, with very little effort.

So my summary is, I only plan on supporting gamepads and keyboard/mouse setups, and they are all very well handled by the old system, which already has decent documentation and resources available. Its simpler, easy, and (in the case of gamepads, keyboards, and mice) seems to already support all the functionality the new system is advertising. To top that off, just switching back from the new system is an extra pain.
* I regret installing the package for the new input system and will be sticking with the old. *

To the Unity Team: All that said, I do seriously appreciate the time and effort spent in an attempt to make a better end result for everyone. The level of complexity itself shows dedication, and the product is already the best in the market because of such attention. (Yes, I know that is an opinion, and you don't have to remind me that Unreal is a great thing. I've used it) My only real question is, why not unify and expand the old system?
Unifying XR and standard inputs was put forth as a reason for the new system, but that seems more a matter of syntax than algorithm. Surely you can find a syntax that works for all, as you may have already done. Then the matter of expansion seems like it would be pretty easy to make a generic abstract class that simply accepts input to a list of values, which any input device would inherit from (including custom cases) and retrofit the input device classes to inherit from, with minimal changes. These base classes could then be inherited from for custom versions of a specific type of device, like a controller with 4 joysticks and 28 buttons.

I know it's a lot. I think too much. Hopefully it helps someone at some point though.

OH! One more thing. I was setting up what would essentially be input maps for different game modes in the old system and obviously don't want to store all the maps in memory while running, so set them up to be lazy loaded from a profileSettings file when the user switches game types or control schemes. This got me wondering how input maps are stored and loaded. If anyone, team or not really, could shed some light on this, it would be appreciated as well, but with a much shorter message hopefully!

 

Rewired is great. and is a mix of both. you have the same mechanics as the old inputs sytem in code but you get the inputs profile manager in the editor. Pluss it allready have prefabs and sample scenes with UI interfaces for in-game customization with autodetection.

 

What do you mean by this? If you mean the ability to use polling instead of events, so does the new system.

 

Actually i don't know the new system other than overview docs. I didn't mention the new system at all.
All i said was that Rewired is great since many asked about it for inputs management. So i share my experience.

 

I agree that Rewired is great. I used it for ages.

You did say it was a "mix of both", though. The old Input system and what?

 

I believe it means that since Rewired is using old unity input, you can mix it with code for old unity input.

 

A mix of the old inputs system coding but it uses manager profiles on top of the standard global manager build in Unity. But the strongest point of Rewired is the out of the box in-game UI interfaz for players to be able te re-map and save/load the profile. For me that made a huge diference.
I have nothing against the new input system don't worry
In fact, if Rewired were out of the picture then I probably would use the new input system. Since it allows multiple profiles.
The coding structure used is not important. Althou i know how hard is to change client's mindsets.

excuse my gammar.

 

Perhaps you should post your code in a proper new thread and get some help on it.

 

Hello, there is a problem with this. Look at the limitations: "

• The new input system cannot yet feed text input into uGUI and TextMesh Pro input field components. This means that text input ATM is still picked up directly and internally from the Unity native runtime."

https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/manual/KnownLimitations.html

If there isn't a chance to feed text into a TextMeshPro Input Field, how are we supposed to work with this?

 

That means that you can't disable the old one if you need typing in text fields. But that doesn't involve "learning" the old one, you can have both, and you don't need to use the old one for anything else that I'm aware of.