Welcome! New input system resources and info (please read)

Current status: See this thread:
https://forum.unity.com/threads/input-system-update.508660/

The thread here is outdated and corresponds to the Input System development under the previous Input Team.

Old post below.

In Input Team we’re been working on designing and implementing a new input system. We’ve made good progress, and though there’s still a long way to go, we want to get you involved already now.

We’ve build a new foundation for working with input in a new way that we’re excited to show you, and we want to continue the development with your input on the existing and continued design.

Development process
The new input system will consist of two parts. The low-level part is integrated into the C++ core of Unity. The high-level part is implemented in managed (C#) code that will be open-source in the same way as e.g. the UI system.

Our development process for the new input system is to design and implement large parts of the high level system first. Initially this is based on top of the current input system that already exists in Unity. For now, we call this the input system prototype. Later, once the new low-level core is more mature, we’ll change the high-level part to be based on the new low-level system.

This means that the current high-level system (the prototype) lacks specific features that depend on the new low-level core, such as robust registration of connected and disconnected input devices while the game is running. However, many features of the design can already be used and tested, and this is particularly what we want early feedback on.

Working with you
Here’s how we’d like you to get involved:

1. Learn about the design of the new system
2. Try out the new input system prototype for yourself
3. Tell us about your experience

Learn about the design of the new system
Input that works well for a plethora of different use cases is a surprisingly tricky matter. We’ve prepared some resources for you to learn about how the new design attempts to address this.

First of all, we’ve created this video covering the design of action maps and player management. It’s a good introduction to the new design.

We’ve also prepared a site with more information about the design, including a Quick Start Guide.

Head to the Experimental New Input System site to learn more.

Try out the new input system prototype for yourself
We have a project folder which contains the input system prototype as well as a demo project which uses it. This can be used with regular Unity 5.3 without needing a special build.

Download it from the Experimental New Input System site.

The input system prototype can be tested with other projects by copying the folder Assets/input-prototype into the Assets folder of another project. (Please create a backup of your project first.)

Tell us about your experience
What do you think about the design? How does it work (or not) for your project? Anything that’s confusing or unclear? For now we’re interested in discussion around the design of the system. We don’t need bug reports quite yet at this stage in development.

For any questions or comments you have, go ahead and start a thread about it in this forum.

We’re looking forward to working with you!

 

This looks really awesome!
Will the new system finally support rumble on gamepads?

 

It will! This is planned to be added before the new input system ships. It's not supported in the prototype currently available.

 

What about integrating it into the UI? We have write our own integration to translate these input events to actions that UI system understands?

 

We don't have a UI integration yet. It's on our todo-list.

The way I imagine it will work is that the StandaloneInputModule on the EventSystem GameObject will be replaced with a replacement component where instead of specifying a text strings for each of the actions "Horizontal Axis", "Vertical Axis", "Submit", "Cancel" there will instead be object fields where you can drag actions from an ActionMap into. Would that make sense to you?

 

Yeah, that would make sense. Would allow us to change the button for an action and no need to reassign stuff all over the UI.

 

Hello, it sound great... i just download the zipped project, but i have this script error :

Assets/FirstPersonControls.cs(2,19): error CS0234: The type or namespace name `InputNew' does not exist in the namespace `UnityEngine'. Are you missing an assembly reference?

Maybe someone can help me ? thanks...

 

Can the experimental system be used in older Unity projects as well? (4.x) In that case I'd be able to test it on older, more complete games.

 

I can't say why that is happening. The namespace is defined right in the scripts in the project folder itself. Did you unzip the entire zip file and open the unzipped folder? Using Unity 5.3?

 

I haven't tested. The demos will most likely not work, but the prototype itself might.

If you have problems, please let us know so we can see if we can help. We're very interested in having the system tested in more complete games like you're talking about.

 

I'm hoping the new system will be lightweight on resources - the older Input system was surprisingly heavy at times, sapping a millisec on some devices.

 

I'm really excited to use this, as I've had to make quite a few work-arounds on mobile with UI, and the blocking feature might end this!

Also, when integrated into C++, will this work dynamically with projects that build to multiple plaforms?

(Also, try moving left and holding your mouse button while playing the FPS demo, it makes this really cool wave of cubes!)

 

@runevision
Does the current prototype work with the 5.4 beta?
Also, for Xbox 360 controller on OS X, is there a driver needed (e.g. https://github.com/360Controller/360Controller )?

Thank you!!

 

I've opened the prototype with 5.4.10b and it worked right away! (Windows though)

 

On the driver question : if your gamepad works with the current input system, then it will work with the prototype. As I understood it in fact, the "core stuff" is still the same and a new version of it is being worked on in parallel.

I can't talk for them, and my understanding of what a "driver" actually is, is limited.

But as far as I know, a standalone executable isn't just able to include code for xbox controllers to work straight up at runtime - I mean they need to get installed on the machine/os first.

and if that understanding is correct then we would be asking of the team to include in standalone desktop builds one time setup of drivers when necessary (at least), and that also means they'd have to manage and maintain them (hassle).

As great as this would be... I believe it's our job to include such driver installation in our app installers or asking for the user to install it themselves.

Well there are bigger priorities here anyway

 

Hi,

I can't seem to find how to programmatically control and set inputs value. In many cases, the code is cleaner when you have one source for inputs and then you can override input values.

Two good case are Remote controls and existing code base that do not match the project: When I created Rmote, I wanted something like what OsTv does now, and the developers obviously have already existing game with existing code, which makes integration not convenient and means changing code just because the Input can come from various sources, hardware or software ( via a connection between two different hardware like on OsTv).

- In General, people that will provide existing frameworks will also hit this issue, like we do right now with typical mouseorbit and similar scripts where we have to manually edit the script to change the inputs, and that breaks future potential updates of them edited scripts.

I hope we'll have the abilitiy to overwrite the ActionMapEditor to generate the ActionMapInput based classes in a different ways ( to add getters for example), or some generic way in a different part of the api outside the regular read only accessors.

Also, is there any reason to move away from the way you are dealing with UI Module code base? why not hosting it on a public rep for people to watch, clone and patch? And will it become a Unity Module actually?

Regards,

Jean

 

Are you hoping to do force feedback steering wheel support?

 

This is correct. I believe the driver is still needed; there is no difference there compared to the existing input system.

What is different is that the axes and buttons work the same way on OS X as on Windows, due to the device standardization feature. (This only works for Xbox 360 controllers so far but will eventually be expanded to cover a lot more.)

 

You can create a custom input device that gets its input from wherever you like. Then you can add a new control scheme to an ActionMap that maps the actions to this new device.

See for example how the VirtualJoystick device is implemented. Maybe you can even use that one directly.

Currently we have just a prototype, but eventually the new input system will be a module like the UI one.

 

Yes. There are still some unknowns in how it fits into the design in a clean way, but it's definitely something we have been thinking about and want to support.

 

The standardization is amazing. Thank you so much for that! Which driver are you guys testing with for the Xbox 360 controller on OS X?

 

Is there more than one?

We have tested 360Controller 0.14 (latest non-beta release) from the unofficial 360Controller repository.

 

I was wondering the same thing. I can't find one, but just wanted to make sure we were going in with the correct setup. Thank you sir!

 

Things get a little bananas if you try to use a mixture of wired 360 controllers and wireless Xbox One controllers connected via wireless adapter. Combination of wired 360 controller and same Xbox One controller connected with a usb cable worked fine.

 

Hi,

I see, it makes sense, I'll experiment,

Thanks

Jean

 

Will there be built in support/templates for common joysticks and gamepads?

Will the system allow for dynamic detection of input type, e.g. player uses keyboard then picks up gamepad or joystick?

Will the system have an easy way to allow the user to configure the inputs regardless of input device?

 

Yep, see the FAQ.

Yes, this is covered in the video and you can see it working for yourself in the provided demo project.

Yep, see the FAQ.

 

looks great, I haven't been able to actually test it yet though.

But some questions:

Does this new input system support all controllers out of the box?
For example will it replace packages like InControl or Rewired? Which levers the ease of setting up controllers.

I read on the FAQ:
Gamepad (support for Xbox 360 controller on Windows and Mac)

We don't yet have support for other gamepads, general joysticks, or other devices.

Just wondering as I use a PS 3 controller on mac. Thanks for elaborating.

Edit:
Suggestion:
A kind request to make key-combo's easier

 

The current prototype: No.
The eventual full system: It will support all controllers in some way if they identify themselves as regular input devices to the OS. Consistent mapping out of the box will work for devices where we have device profiles made for them. We intent to ship the system with device profiles made for most common controllers, but naturally we can't cover every controller out there. However, you will be able to supply your own device profiles as well.

 

Thanks for your elaboration. Looking forward!

Surely hope there is also room for key combo's

Good luck!

 

Will it support mobile devices?

 

It will!

 

Maybe noob question but how different will it be to a few of the assets on sale such as:
Easy Touch, Control Freak, In Control?

Has there every been contact with the authors of these assets for some collaboration work or ideas.
I do understand they may not wish to contribute due to basically people not need them in future if Unity release own.

 

Also what about TV devices, Apple TV, Samsung TV controllers?

 

We are not experts on every Asset Store extensions out there, but what I can say is that some people have said it looked comparable to InControl, and some have said it looked comparable to ReWired. I'm not at this point familiar with EasyTouch and ControlFreak. From a glance it looks like they cover some of the same needs but as for how the design is similar or different, I can't say.

We've had a bit of contact and feedback from Patrick Hogan who's behind InControl.

 

We are not yet at a stage where we know exactly what will be supported, but I added an entry to the FAQ about our aims.

 

Hey, any news on an update? It's been a while

 

We are currently working on various back-end changes and test coverage to improve robustness, quality and extensibility before moving further ahead with new additions. For this reason this may take a little while before we have something new to share.

 

Okay, cool.
I hope one of the back-end changes is the horrible things that happen to nested scriptable object assets (or anything else nested in a scriptable object asset) It's VERY noticeable in the action maps.

 

How many developers are on the input team? Are all of the input team members working on this full time or they being shared with other parts of Unity engine development?

 

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.