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

Current status: See this thread:
** Input System Update **

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:

  • Learn about the design of the new system
  • Try out the new input system prototype for yourself
  • 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!

11 Likes

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

1 Like

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

2 Likes

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?

3 Likes

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… :slight_smile:

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.

1 Like

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. GitHub - 360Controller/360Controller: TattieBogle Xbox 360 Driver (with improvements) )?

Thank you!!

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

1 Like

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 :stuck_out_tongue:

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.)

1 Like

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.

1 Like

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.

1 Like