Input System checked!

After 7 years waiting, more then 2000 feedback votes, its good that something happen, but this 1man 1month work you expose is barely enough or simple if someone check public roadmap such important thing "In-progress, timelines long or uncertain”.
Although you said, Unity will,I feel so much reluctance about changes, need to be done in C++ side,
especially EXPOSING LOW LEVEL TO C# API, make input system developer as myself to solution to marshall OS C++ in C#.
For example to achieve capture of device connect and disconnect, you already, at least on high level, have covered in proposed API.
(btw you can simulate with Input.GetJoystickNames() until you don’t have 2 devices with same name)
Two main points.
1)As Customer I need to remap and/or set InputManager.asset settings like sensitivity or gravity, and SAVE!.
As far I can see proposed API can runtime remap but can’t save it. What you have in mind? PlayerPrefs?
2)As Developer I want to connect device, create profile and map to actions by MOVING, CLICKING(long,double…)or combine
Have current system have plans to support COMBOS and EDITOR MODE device mapping?, instead of huge 10 screens popup to map keyboard key.

I like ActionMapInput
generator so you have intellisense in code, but it is boilerplate if you expect to use

Code (CSharp):

1. if(ActionMapInput.isHeld) //do something

, ActionMapInput.isHeldUnityEvent
so I can in editor subscribe handler to do something. EDITOR SUBSCRIPTION TO ACTIONS BASED ON UNITY EVENTS!
Device profiles defently shouldn’t be HARDCODED but ASSETS with just data not creating device instances (new GamePad()) use PID

It would be good as to have

Code (CSharp):

1. public class AnimationCurveControl : InputControl

, which no matter actual input is discreet or analog will calculate some value according to curve.

You need to track also connected device “PORT”, so if user change the device port not need to reassign.
I hope the below code won’t be HardCoded so for example I won’t include (mouse in mobile dev target)

Code (CSharp):

1. go.AddComponent<JoystickInputToEvents>();
2. go.AddComponent<MouseInputToEvents>();
3. go.AddComponent<KeyboardInputToEvents>();
4. go.AddComponent<TouchInputToEvents>();
5. go.AddComponent<ExecuteAllEvents>();

I would be able to support any device ur C++ won’t support, but just adding go.AddComponent<WiiInputToEvents>(); and the rest would work.
Put the code on GITHUB we can track changes and progress.

 

We will probably have both an automatic solution that might be based on player-prefs or other things, depending on platform, and a manual way to deserialize and serialize where you can do what you want with the serialized string.

Editor mode device mapping (e.g. "press key to use") is planned, yes! It depends on a new backend so is not in the prototype.
As for combos, I don't yet know if we'll support them directly in ActionMaps. ActionMaps have their biggest advantage when there are different mapping in different control schemes, so unless you have in mind that the same action would be triggered by one combo on one input device and another combo (not just different keys, but an actual different sequence) on another input device, it might be better to handle combos at a higher abstraction layer than the ActionMaps.

That said, we are thinking about finding a way to make it possible to extend ActionMaps with custom "combined actions" that can evaluate with custom code. If we manage that, combo recognizers could be implemented that way.

We do plan to have the option to add listeners to action events. Not yet clear if it will be based on UnityEvent or not.

We've gone back and forth between device profiles being assets or scripts, and eventually landed on scripts. You can create your own ones too though, so it's not any more hardcoded than that.

We'll keep it in mind in relation with the custom combined inputs mentioned above.

There won't be this kind of code in the final system at all; we only have that because device registration isn't implemented in the prototype. For a custom device you'll be able to just register it.

We're not making a public repo right now since we're still doing some major refactoring, but eventually it will be on open source (probably on BitBucket) like the UI system and other open source extensions.

 

I agree about COMBOS done same way like you join MoveX and MoveY into Move.
I don't agree about HardCodding profiles. If backend gives u PID not index number you will know which profile to load.
I vote for UnityEvents as they are user friendly and automatize work thru editor.
Hope u understand me about adding custom devices. So I've custom DLL for custom device and I wan't to be able to integrate to InputSystem with just adding Mono component. something like go.AddComponent<WiiInputToEvents>()
adding additional source of InputEvents.

I like offering custom serialization.