Hello.
Do you have plans to support the Steam Controller? Where it would be in this design?
Howdy!
This looks very nice indeed! One thought though. As a coder I really prefer keeping as much logic as possible in code files, and try to avoid mucking about in the editor if I can. I’d like to hear if you have any designs planned for creating and maintaning input maps from code. If you are drawing a blank, I have a suggestion for a way to do this;)
The idea is to allow coders to declare input maps through c# interfaces and attibutes like this:
[InputMap(“CharacterControls”)]
public interface ICharacterControls
{
[DefaultMapping(Gamepad.GamepadControl.LeftStick)]
Vector2InputControl movementDir { get; }
[DefaultMapping(Gamepad.GamepadControl.Action1)]
ButtonInputControl jump { get; }
}
This interface would be detected in the editor, and if an input map was named “CharacterControls”, the map would always be padded with these controls. This would allow designers to make changes t the coder declared inputs, while the coder could then either use the auto-created CharacterControls.cs OR the coder-maintained ICharacterControls interface.
We’re not planning to have such a parallel method of defining action maps. It will however be possible to create ActionMap assets from code.
I’m also very much interested in this. Also is there any definitive timeframe on when this would be interrogated to Unity? i.e What version it would be in?
We can’t give you definitive time frames or versions where the shipped system will be in because we don’t know for certain ourselves. There are still too many unknown factors. If you have a deadline, we suggest you don’t use the new input system unless you can make do with what it currently offers.
You’ll be able to do this from the stand-alone runtime or only within the Unity Editor domain?
Thanks, I’m not really working to a deadline so I’m not fussed about that.
A more technical thing though how would the new input system handle different controller makes? Would there be a calibration tool for developers to use for it or will it be a kind of popular controllers etc are mapped?
The input system has a concept of device profiles. Each brand/type of controller can have a device profile mapping its arbitrary input into a standardized format such as the standard Gamepad class. Sometimes the same device type even need different device profiles for different OS’es because of driver differences.
Currently in the prototype we have device profiles for Xbox 360 controller on Mac and Windows (which means the mapping is the same on both). More device profiles can and will be added. We’ll try to cover the more popular ones, but users or input device makers can also make their own profiles which can be added.
Also see: https://sites.google.com/a/unity3d.com/unity-input-advisory-board/faq
I really like the new input system. I dived in the code too, it is well designed and neatly coded. It is pretty extendible too. And with the source code available, I managed to hack some missing features I needed, so we could use it in production.
One part that needs to be more extendable is the way action maps get the input from the device states. As far as I can remember, there can be no rewriter injected. The system would be crazy extendible, if you could feed the action map input directly. This is exactly what I am doing, and I managed to integrate TouchScript with this method. The two work pretty well with each other. I override the values of the actions. I know this is not a particularly nice hack, but it would be great, if such a third party framework could be integrated without hacking around with the code of the new input system.
Long story short, you cannot have enough extendability in such a system, I think.
Happy to hear your feedback! Agreed it would be good if we manage to get input sources in ActionMaps be extensible with rewriters etc.
I’d be curious to see your TouchScript integration.
How can I share the TouchScript integration with you?
Please note, that although my solution works, it was not intended for reuse or sharing, I just made it work with minimal effort so I can proceed with our project. And although I spent hours to understand how the new input system works, it would have needed much more time to make a proper extension point in your system.
I’d love to see the script as well
Hi,
I’ve been experimenting with this system for about a day now, and while it seems very useful so far I was just wondering if we can access gamepad rumble functionality using this system/if it’s planned for the future? I figured that I should ask here first so if it’s the wrong place I apologise.
Have a look at the FAQ. 
https://sites.google.com/a/unity3d.com/unity-input-advisory-board/faq
Awesome, thanks!
Will this new input system still use rawInput? Or will we have an option for directInput / xInput (on supported platforms)?
Any chance we can get Multi-touch support in editor?
Just makes life easier when testing things instead needing to build on mobile.
Maybe this wrong place to mention it?
2 Likes
I’m curious about this too… I’ve had to use TouchScript for handling all multi-touch features in Unity because it was too laborious to deal with otherwise…
Right, it’s not related to the new input system.
Multi-touch support in the editor is on Editor Team’s internal roadmap, but as I understand it, not at a terrible high priority compared to many other things that also have to be done. Please use other forums for discussion of this though.
1 Like
Hi,
The new input system seem really nice.
I read the FAQ and saw this:
Please make it possible to access all raw input data as a buffer. Getting a method call every input can be too expensive, just add all in a rotating buffer and make it accessible from everywhere.
This way you can always query Nth input values(up to the buffer size) at no expense, it’s how I handle all my interaction between the audio dsp thread and Unity thread and works wonderfully.
Another thing, is FixedUpdate being rewritten? So far it was a fake fixedupdate and querying the input in there made no sense, since it was all stacked before the update method so you would get consecutive calls.