Feedback: why I didn't end up using the new input system

Leaving this feedback for the Unity team in the hope that it's helpful. I am working on a new project that must support keyboard, mouse, and controllers and I decided to spend the day integrating the new input system. This was about a week ago... After almost getting things to work I ended abandoning the new system and using Rewired. To give some more context, the game has three modes: exploration, combat, and menus. I want mappings for each mode and the ability to move between mappings using a stack-like system.

The Good
The user interface to define mappings, actions.
The fact that things are stored as scriptable objects in the hierarchy.
Action maps
It was fast and easy to define actions, maps.

The Bad
Documentation is not very helpful -- I'm still not sure about all the event types or the distinction between things like "performed" and "triggered".
Event-only, except for triggered. For combat, I needed to check whether a button was held down. The only way to do so was to register for events and track state myself. I am using NodeCanvas, though, and that's not so easy to do in their system. The equivalent of "GetButton" and "GetButtonUp" are sorely missing.

The Ugly
Actions in maps seem to get corrupted when changing active maps. I found my "start combat" action would end up in a bad state after exiting combat and require two presses to restart combat. I couldn't find a way to reset the action.

Hopefully this is helpful. I look forward to trying out the new system sometime in the future.

 

Yep, overall I like the new system and its flexibiliy, but the docs are really lacking.

 

Thank you for the feedback. Appreciated.

Yes, our documentation needs work.

It's on the plan for after 1.0.

Code (CSharp):

1. // GetButton("fire")
2. playerInput.actions["fire"].IsPressed();
3.  
4. // GetButtonDown("fire")
5. // Put "press" interaction with "Press Only" on "fire"
6. playerInput.actions["fire"].triggered;
7.  
8. // GetButtonUp("fire")
9. // Put "press" interaction with "Release Only" on "fire"
10. playerInput.actions["fire"].triggered;
11.  

That said, certainly room to make things simpler / more obvious (especially WRT to requiring an interaction).

Looking into that ATM.

 

Should be fixed by PR. Expected to roll out in 1.0.0-preview.6.

////EDIT: Actually, the bug you were seeing is probably this one. Fix in landing pattern.

 

its still awful.

 

Very awful. For two hours I've tried to find a way to bind the space bar, but all that comes up in the bind paths is "Usages". No Game Pad, no keyboard, nothing.



To have this as the suggested input for Unity 2020.3 is bananas. Has anyone actually used this successfully?

 

Yes. It looks like this for me:

It is not installed by default on 2020LTS. So I don't understand what you're talking about.

Make sure your InputSystem setting in the Project Settings looks like this:


Which means there isn't anything in the "Supported Devices" field.

 

After multiple hours of fighting with the new InputSystem (not to mention the time fighting with VSCode because it didn't recognize UnityEngine.InputSystem) I simply gave up. My code used a lot of GetButton, Up and Down and I struggled to find an easy way to implement something like that. I couldn't easily assign the input assets in the editor. I couldn't understand when to use Update() and when to use On[Action](). I couldn't get how to make an input continuous. And the internet results were few and badly explained. I'm using the old one, thanks.

 

Use whatever works for you, but know, that they practically recreated the old Input manager-way, you just have to read the manual to know that:
https://docs.unity3d.com/Packages/com.unity.inputsystem@1.3/manual/Migration.html