Feedback PlayerInput is bad

I love clean code: who doesn't? And it's why I love the InputSystem.

My favorite Component of the whole bunch is PlayerInput: you hook it up and you're ready to go. But I've made 2 threads about issues with it and now I've come across another one, so let me write down exactly all my gripes with this beautiful but flawed component.

1: InputValue vs InputAction.CallbackContext.
PlayerInput lets you pick its notification behaviour, between messages and events. What I do not understand is why the messages send an InputValue and the events a CallbackContext, as CallbackContext can do everything InputValue can and more (I use CallbackContext to get the device and add distinct behaviour for mouse vs joystick). It's also much easier on iteration to use a single type and not have to go back and refactor some methods to accomodate for a simple change in notification behaviour.

2: Notification Behaviour isn't flags.
This one says it all. Although I can understand on one hand why this would be bad design, on the other hand I think designers should have the option. And if flags create ambiguity between Send Messages and Broadcast Messages... then just remove Send Messages, if designers are looking for performance they should be using events or direct hook up anyway.

3: Multiple PlayerInputs is made impossible.
If it were up to me, I'd put a PlayerInput on my Player, my Car, my Minigames, my Breakdance Scene and my interactive credits. Like I said: the thought of hooking it up and going is amazing. Unfortunately I'm scared, because 2 PlayerInputs immediately tells the InputSystem that this is a multiplayer game and should do something with splitscreen if I'm not careful. It doesn't help that disabling PlayerInput throws index errors. I have a lot of trouble understanding how PlayerInput is meant to be used because of this, because I feel like both single player and multiplayer games should be able to support more than X amount of PlayerInputs but I'm quite unsure now.

Like this post if you agree and want @Rene-Damm to know what's up. Sorry Rene, I really enjoy everything else.

EDIT:
The index errors were my fault. When the PlayerInput was disabled I still read one of its values, which I couldn't do because it was disabled. I've appended that method with checking if the callbackContext.performed is true.

 

i just feel the inputsystem team is far too small and/or busy to articulate how it can do things. i'm quite low skilled but i've done some cool things with unity because of the clever things it does for me or makes easy for me to do. i cant say inputsystem is poor but i can say it doesn't present itself useful for me, perhaps its intended purpose is narrow and not inclusive of the genre of my game.

meanwhile i used another unity addon which does it all for me and just works *as expected* - this is important - most of the threads i see on this forum are how do i do something with inputsystem, like they just cant make it do what the old system or other systems can already do. the answer, if you get on, is normally convoluted and not easy to understand.

playerinput was a concern for me, i wanted events where a played pressed join on a controller which was automatically assigned to them, i wanted to subscribe to these events so my UI/lobby can act on them and now which player pressed it. inputsystem couldn't seem to do that, playerinput seems to needing adding on each gameobject i need it to work on and i couldn't see how to make it react to the right player nor could i seem to share the keyboard&mouse and first controller with player1.

i wanted to use playerinput and make my own script to work this way but it seems what i needed was hidden by protected variables in the module itself so that was a bust.

my takes on this were:
1) it wasted a LOT of my time - and i didnt get the result.
2) the other addon module that i used did all this and it was working in a matter of one evening.
3) i bet inputsystem can do all these things, but how? who to ask? where?

i would love to make use of it, but until we have better contact and improvements made on the feedback - i just have to get on with my stuff using other means.

lets hope @Rene-Damm and his team are mostly not posting here as they work on the issues because if they spend the time answering all the questions it raises we'll never see a new version.

 

I'm a beginner on Unity but not to game development, I've decided to give the Input System a try and learn it. I've read there are benefits over the default system, although I don't fully understand the limitations of the default system.

It's been an uphill battle learning this thing. I've seen some 5 different implementations of reading input, which is fine because it means flexibility to developers, but it's also really hard to find what exactly are the pros/cons of each implementation. The Input System manual doesn't clear that up, the official videos on Unity don't clear that up, tutorials from users online don't clear that up (probably because they can't figure it out either)

Learning how to use an implementation is not complicated, the impossible part has been learning WHY to use something, why it is build in such way. The only reason I've gone with the input system is to avoid limitations of the default system, but if I don't know what are the limitations of the approach I'm using, what's the point?

The one thing that's been holding me back from progressing on my current project and learning more about Unity has been struggling with the new input system. When I thought I had it figured a good way to use it, I find out it stops working when I edit scripts in play mode, which is deal breaker for me.

 

Unity's old input system is perfectly fine until you need it to be capable of more than just basic input. Once you start needing to support multiple controllers of multiple different types with support for rebinding actions it starts to fall apart and you start having to create more and more of your own code sitting on top of it to make it work.

 

curious if this well timed blog entry helps:

Learn the Input System with updated tutorials and our sample project, Warriors (unity3d.com)

it looks to be what i was looking for just as i abandoned it! but i'm a curious tinkerer.....

.....EDIT: it didn't really solve any of my issues. i looked through the warrior demo and where i'm looking for answers, assumptions are just made in their place.

 

Saved me the time of going through those myself, what you said is what I expected I'd find there.

 

Ok lets see how high is the level of "bad" by asking a simple question and try to solve it and see how easy and painless or how cumbersome and painful its is to solve with the new Input System.
Ok here comes the question:
How to build an Action in the Action map that is working like the old "Horizontal" and "Vertical" axis feed by the mouse movement data?

I try to solve and work on this problem since 1 day and still struggle, how fast are you guys ?

 

Sorry to say this but... less than 1 minute. All you need to do is right click an action, then press "Add 1D Axis Composite", that will set you up right (of course don't forget to assign buttons).

 

But the mouse? the mouse isnt a button , what values to select to make mouse axis X or Y feed the values of the 1D Axis Composite ?
letting the keypess A feed negative and the keypress D positive in a 1D Axis Composite is easy , I already knew how to do this , the question was how to let the mouse movement feed the positive /negative horizontal 1d and positive/negative vertical 1d axis .I hope this makes it more obvious what I was after

 

Ah I see, apologies. When you create an action, you get 3 options: Button, Value and Pass Through. Select either Value or Pass Through (they are the same except Value will only allow input from 1 binding at a time) and set the Control Type to Vector2. Now add a binding: just a regular ol' binding, no composite. Now you can select mouse controls that are specific to the Vector2 control type (works with gamepad sticks too). Select position and you're good to go!

Of course you still need to do stuff like camera.ScreenToWorld or what it's called, that's something the InputSystem can't, and shouldn't, handle for you, since that depends on your camera setup.

 

Ok cool, i have the feeling we are on the right track, sorry english isnt my native language , I obviously still missed to articulate my problem right.

I want that the axis is eighter -1 or +1 depending on if the mouse was moved left or right. I think this is it well in a nutshell
EDIT: Waking up this morning i came to the conclusion its even easier to explain, finally...:

How to rebuild var horizontal = Input.GetAxis("Mouse X"); in the new Input System ?
Thanks in advanche for any help.

EDIT2: OK!!!!!! I got it!!! its mad but it works:
Thats how I did it now using the Input Asset editor
1. Create an Action "HorizontalMouse"
2. In that Action set Action Type to Value and Control Type to Axis
3. Add a Processor "Clamp" and set min to -1 and max to 1 (IMPORTANT: put this on the ACTION, NOT on the binding that follows in 4.)
4. Create a binding for the Action and set its path to Delta/X [Mouse]
5. var a = inputActions.FindAction("HorizontalMouse").ReadValue<float>(); the result of a is now always -1 or 0 or 1

Its non-intuitive and stupid missleading because the 1D Composite let one indeed think it would be very likely the right thing but at least I could not make it work with 1D Composite , maybe its just because I am stupid and dont understood how 1D Composite really works, who knows...
At least its now clear how it can work, there are maybe other ways but one working way is enough for me, thanks for pushing me in the right direction Casey!

 

Great stuff! I understand the confusion, so let me clear something up for the next time you run into this issue: a 1D Composite uses 2 controls to give a float. In your case, you are using 1 control that is a float. I bumped my head into this the first time too, how do you think I knew how to help you?