does the new unity input system have special ability

I have recently gotten to know the new unity input system.

however it is confusing to me.

does it really have a new feature compared to the old input system ?

 

Yes, the new system is much nicer than the old.

For starters it allows you to write event based input code rather than polling based code. This means that instead of having your own objects running an Update() every single frame just so they can keep asking the input system if anything has happened, they can instead get the input system to call a specific method to let them know when something happens.

It also allows remapping or rebinding of controls, so if your players want to use different layouts to your defaults you can let them do that. The old system technically allowed this, but it required some nasty hacks.

What are you finding confusing?

 

Well, the new input system is no longer built in the editor and is said to be more effective. The angry volatile says more.

 

in new input system the process of initial setups are timely and the number of codes which I need to use for detecting key interactions is too much

but

in the old input system:
I only needed to open : project settings > input manager
and then declare my key

and then in code by using only one line code I can detect key pressings

 

The new input system is actually an input system. The previous one was just window dressing.

Creating controls and maps in the editor is straightforward, and there are so many more capabilities that it's hard to know where to start. Probably the most fundamental thing is that it's easy to put together keyboard and xbox controller maps very quickly. But that's only the beginning.

However, the API is inelegant, and as soon as you have to deal with code, it's not anywhere near as simple as the input manager. There are a lot of layers in the API that can be quite confusing to understand and use, especially if you try to delve into rebinding and stuff like that.

 

sorry I didnt quite get it
are you saying that the new input system is good or not ?

 

Good for who and what?

I'm saying it has a lot more features and capability, but is far more complex to code with.

 

Sometimes people just want somebody to tell them what to do.

Here, let me try:

Is it good? I wouldn't say so. It's bad. But it's not as bad as the other choice, which is very bad. In that respect, it's good. But then again, game making in general is kind of bad, because it requires all the choices between good and bad, and that makes one tired.

It's all bad, give up.

 

I like it. Some cool features are things such as input remapping that is super simple with the new input system. You can also record input, save it into a file/serialize to string, and replay that input whenever you want.

 

It's actually not bad at all, you have to get used to it, like for everything new in the world.

I've just begun learning how to use it so it feels awfully complicated at first, then, the more you toy with it, the more you find out how things work.

And coding seems actually less complicated, since you use integrated events: OnMove(), OnFire() and, if I'm not wrong, you can create as many of those events as you want. But someone with more experience is needed on this.

 

If there's a limit, I haven't hit it.

 

You're basically spot on. I was one of the early adopters and everything felt complex to me until I realized how you were supposed to be using it and suddenly all of that complexity fell away. I'm going to partially blame this on the documentation which while not as bad as other new systems is still pretty awful at explaining things.

Incidentally if you just want to be lazy about it and don't care about any of the advanced functionality you can use it like you would the previous system. It's a great way to prototype code without having to rely on the old system.

This:

Code (csharp):

1. if (Input.GetKeyDown("space"))

Becomes:

Code (csharp):

1. if (Keyboard.current.space.wasPressedThisFrame)

 

I've checked the input system after your post, and in my opinion, this is awful.

Making every key a property is a rather bad design, as is assuming how many keys a device has.

There's too much reliance on magical string parameters that should've been encoded as objects instead. At least manual mentions passing deadzones "processors" which are strings supplied into attributes.

It is nice that you can detect when devices are plugged in or removed, but for example in DirectInput you could query directly number of buttons and/or axes the device has, and access them through an index, while APIS like SDL use allow access to scancodes for a reason. Meanwhile unity forces semantic meaning on you. And

 

What I showed is just one way to use the new input system. If I had to guess it exists for the purposes of easy upgrading of existing projects and for rapidly prototyping new ones. I know when I'm rapidly prototyping the last thing I want to do is spend an hour setting up input. That can happen once I've decided to stick with a project.

 

Like @DoctorShinobi says you can record input and that's super SUPER important when you do auto testing during the end of your production cycle (don't wait like I did til the eleventh hour to implement those)
The API is atrocious especially the modifiers but if you stay away from those it's manageable with @Ryiah's form.
Now what I haven't seen in this thread is mention of bugs. This thing is riddled with them, they could be timing bugs because they are slippery.
It was such a pain to deal with that the next game I won't fall for the pretty UI and try out InControl or Rewired instead. Both are actually supported and battled tested.

 

I'm just not sure why not do input SDL way or similar.

Meaning you get api to access button/axis/ball/pad by index, and you get an api to get meaning behind of index, if any.
SDL also works with "event based" input, which allows you to create a typewriter input, and I think it was also capable to handle IMEs as well.

The approach is compact, doesn't pollute namespaces with quadrillion properties, and can be used to support anything, without setting a configuration for it first.

 

I thought I made it clear that this isn't the sole way to use the system. The classes (ie Keyboard, Mouse, etc) aside from being able to easily obtain IDs for the devices exist for this purpose. If you want to use the system in a more advanced way you do not use those classes.

Instead you create an asset using a custom editor that stores the bindings for the controls, you assign the asset to the PlayerInput, and then you attach the events in PlayerInput to the code that you want to be activated when the events fire.

 

Alright, maybe I need to take a better look at it. However a design with keyboard keys being declared as properties would still bug me to no end.

 

But why? You aren't obligated to use them and they cost you nothing. A few kilobyte disk space.

BTW, Unity also has the KeyCode enum as well. Just an FYI.

 

Because that's a design I'd instantly kill if it surfaced in my code.

You have hundreds of copy-pasted lines like this:

Code (csharp):

1.  
2. public KeyControl backquoteKey { get => allKeys[Key.Backquote]; }
3. public KeyControl backslashKey { get => allKeys[Key.Backslash]; }
4.  
5.  

plus it pollutes top level class field list with identifiers.

Try going here:
https://docs.unity3d.com/Packages/c...1.0/api/UnityEngine.InputSystem.Keyboard.html
And scroll to the method list.

--edit--

If someone REALLY needed something like that, a decent idea would be to wrap it into "Buttons" accessor class just so it doesn't pollute top level of class.

 

I much prefer the new input system. I went from

Code (CSharp):

1. Void Update(){
2.   if(Input.GetButtonDown("Fire1")){
3.      FireDown();
4.   } else if(Input.GetButtonUp("Fire1")){
5.      FireUp();
6.   }
7.  
8.   if(Input.GetButtonDown("Fire1PS4")){
9.      FireDown();
10.   } else if(Input.GetButtonUp("Fire1PS4")){
11.      FireUp();
12.   }
13.  
14.   if(Input.GetButtonDown("Fire1XBOX")){
15.      FireDown();
16.   } else if(Input.GetButtonUp("Fire1XBOX")){
17.      FireUp();
18.   }
19.  
20.   if(Input.GetButtonDown("Fire1SWITCH")){
21.      FireDown();
22.   } else if(Input.GetButtonUp("Fire1SWITCH")){
23.      FireUp();
24.   }
25. }

To a simple

Code (CSharp):

1. Void Awake (){
2. controls = new Controls;
3. controls.Player.Fire.Performed += ctx => Fire();
4. }
5. Void OnEnable(){
6.   controls.Enable();
7. }
8. Void OnDisable(){
9.   controls.Disable();
10. }

And it's all in a simple and easy to use interface. I couldn't actually imagine going back and using the old input system.

EDIT
I forgot to add, you can even use it like this

Code (CSharp):

1. Input.Action.started += OnAction
2. Input.Action.Performed += OnAction
3. Input.Action.Canceled += OnAction

And have everything wrapped up nicely in your code under a single function. You can then use the context to determine what to do in the OnAction function.

It's honestly really fun to use!

 

One thing that does bug me is that someone changing a setting in the input manager can stop the project from building. That's because it's used to auto-generate a bunch of code.

I'm not sure that this is a rational annoyance, though. Either way there is going to be an error, and generally I prefer compile time errors over run time errors, as compile time ones are far easier to spot.

Unless InControl has fundamentally changed, I would entirely recommend Rewired over it. When I used it InControl was just a wrapper over Unity's old built-in input system. Rewired is a native input implementation for each of its supported platforms and what I've used of it was solid, so it definitely gets my thumbs up.

 

By any chance were you trying to use the approach shown in the fire action example?

https://docs.unity3d.com/Packages/c.../HowDoI.html#create-a-simple-fire-type-action

Because that was one of the initial approaches I took to implementing input with the new system only to discover that it had problems that I was unable to track down. When I switch to the approach described in the Quick Start Guide those problems went away.

https://docs.unity3d.com/Packages/c...ting-input-indirectly-through-an-input-action

InControl was rewritten a few years back to no longer use the original system built into Unity.

 

Wait, all the keys were declared as properties before, when the input system was integrated to the editor, no longer with the new system.

 

Is this the official documentation or am I mistaken somewhere?

https://docs.unity3d.com/Packages/c...tyEngine.InputSystem.Keyboard.html#properties

Scroll through the properties. Also see Riyah's example.

 

By the way, I recently stumbled across the old Roll a Ball project; I didn't know it had been entirely remade and it appears that the new version uses, and teaches how to use the new input system, and there are live sessions.

So, there is a huge probability that whatever people think of it, the new input system will become the default input system.

 

When something is being redesigned the goal should be a lot higher than "not worse than the old one".

That said, assuming the bugs are being ironed out I don't personally see any real issues with the new system.

 

I would have thought part of the reason were to make life easier for beginners but I just looked at that tutorial you referenced and I noticed that they use the new input system in the way both of us have described and that I would consider to be a more advanced approach.

 

It's not the question, these properties have to be stored somewhere one way or another and there is not much room to do that; "better" is just the light at the end of the tunnel.

 

They really don't. They just return a member from an array via an index which is already separately named as a part of an enum. They're just a redundant method of accessing data. Again, though, I personally don't have a problem with that. I assume they're there for the sake of consistency with other parts of the system, and I love consistency.

Separately, I do find it a little... amusing how the documentation first goes to lengths to explain that the letter used to refer to a key (in both the property names and the enum names) does not necessarily represent the letter physically drawn on the key, and then starts describing keys based on that. The S key is between the A key and the D key, it tells me. From there, either I've already got a QWERTY keyboard in front of me and can see that for myself, or I'm using some other type of keyboard and have to get out a piece of paper and start working through a brain teaser to figure it out.

I suspect it would be far easier to work with if it simply said something like "Physical keys are referred to by their label on a standard QWERTY keyboard. Here is a diagram of the QWERTY layout."

Edit: Or if they want to do it without pictures for accessibility, then "The S key is the second key on the second row of letters."

 

The documentation... there would be a lot to say about package documentation. Some are really well written and others... oh well.

 

In C# properties actually have cost, because of reflection information (and the forwarding code they generate). One of the amusing situations I encountered when I first started using C# was that if you declare an enum with a couple of thousands members, you'll receive a fairly beefy dll after compilation that pretty much only stores names of every enum constants. Meanwhile in C++ the cost of the same enum would be zero.

Like @angrypenguin said, those properties don't need to bee stored, as they're redundant. The only thing they do is forwarding calls to an internal array.

 

Except this ultimately fails at accessibility. What about non-QWERTY keyboards? What about split keyboards? What about stuff like the Kinesis Advantage line, which you'll find a lot in accessibility spaces?



This isn't an accessibility feature, this is magic numbers.

 

This one seems to be technically qwerty. That is unless it has some secondary features like chords etc.

Spoiler

https://en.wikipedia.org/wiki/Velotype#/media/File:Veyboard.jpg


https://en.wikipedia.org/wiki/Chorded_keyboard

 

To quote one of my favorite hardware reviewers, "it's the most comfortable mechanical keyboard we've tested".

Spoiler: LTT - Kinesis Advantage 2 Review

 

The problem comes down to description. The second row of letters now refers to, potentially, three entirely different things:

1. the second row of letters on the left side
2. the second row of letters on the right side
3. the second keyboard inset

This puts forth dramatically more ambiguity and doesn't properly account for changes in key layouts. In general, if you're going for accessibility, you stick to displaying glyphs and operate under the assumption that accessibility devices on the other end will be in play or the user is used to using their own input devices. If you are targeting accessibility beyond that you're generally approaching working directly with specific accessibility concerns that you'd be addressing far more specifically.

 

The accessibility I was talking about was specifically removing the requirement for an image. As for broader ambiguity, in my previous example I'd specifically referred to QWERTY, and didn't want to bloat both examples more to make them truly unambiguous. Next time I write a forum post I'll get a professional copy editor involved before I submit it.

The existing descriptions I was remarking on also don't work in the situations you pointed out, despite the increased mental load to follow them.

 

Humans are typically expected to be able to infer not quite precise information to some degree.

Though I agree that "second row of letters" is not the best idea, as there are layouts with letters on the first row.

Spoiler

 

About the default available inputs, I wonder why they didn't add a Jump action. Moving around, firing and jumping was the minimum before, why did they leave Jump behind in the new system?

 

As a developer who hasn't put a tremendous amount of time into any engine, I really enjoyed the idea of the input system. But I keep running into weird issues. As an example, I was toying around with making a mobile Solitaire game. I wanted to implement standardized actions for mouse control and touchscreen. The mouse controls were working fine, but when I tested it with Unity Remote on my phone, touch was not. I spent more time than I'd care to admit trying to figure out what I was doing wrong, but it turns out that the new input system doesn't really work with Unity Remote. And there has been an ongoing thread about it since like 2018, with the Unity response seeming to be that they didn't know how much developers relied on Unity Remote.

I then tried to test it out on 2021's device simulator using my mouse and, even with the Input debugger option "simulate touch screen" enabled, I was not receiving the touch position. I ended up just switching to LeanTouch, though I wouldn't be surprised if I was just missing something obvious.

 

I ended up returning this thread while working with the input system mostly to look at Ryiah example that I was certain was there.

The new system isn't that bad, in the end, and more pleasant to work with than I expected.

Spoiler

I suppose I might have tendency to perceive new changes in negative light.

 

I quite like it. Except when I'm trying to do something mildly advanced like using "K" for one action and "CTRL-K" for another. It's currently not supported unless you do it yourself in one action handler. But then, this whole action thing defeats its purpose.
Also, you can't get all the binding display strings out of the system in any way (for localization purposes). Only what bindings are already exist. So you need to do that planning manually. And I'm not even dreaming about a button in the Input System which says "We see you're using our Localization package, let us dump all the localizable elements in a table for you".

So there are quirks, but still lightyears better than the old one, so happy.

 

Can't you bind actions for Ctrl and K and then make Ctrl act as modifier?
The thing is, when it comes to keyboard, the last game I remember that seriously took the Ctrl+Key bindings was Deus Ex 1. Most of the other titles treat the keyboard as a giant gamepad.

Regarding keyboard handling, one thing I wonder about is typewriter input. But apparently there's onTextInput.

 

Moved to Input forum.

 

Yeah, that was my

about. Make one action, bind it to "K", write a branch in the action handler with and without the modifier key.