[Official] Input System Improvements

@Rene

yours solution will be framerate independent? and will replace or share features in editor? (now we have redundant - Input and Event class - first for play mode second for editor which sometime is a bit annoying)

EDIT:

oh and have you any plans for technical blog focused on new input solution?

 

In principle, yes. However, there's a number of aspects to this.

The state-based input API (like Input.GetKey) by nature remains coupled to the time increments in which events are processed. For Update() and LateUpdate() nothing changes here. However, for FixedUpdate() the state is now tied to the real logical game time increments meaning you're no longer coupled to framerate here but rather to actual game time (like you'd expect).

For event-based input, you have access to the stream of accumulated events and are thus decoupled from time-dependencies.

However, that's still based on the assumption that the underlying platform actually serves us all input as events. If not, we still need to poll which again couples us to the interval in which we poll which, if done from the main loop, couples us to framerate again. We haven't yet come to the point where we should spend some time on this but when we do, my thought/hope is that wherever we need to do it we can move the polling to a thread that we can run with more or less controlled frequency.

EDIT: Just for clarity... even the input we poll, we turn into events. There is nothing going into input state that isn't derived from the event queue.

ATM there's no plans for external changes to IMGUI related to input.

That's a good idea. We should definitely do that once things have firmed up a little (i.e. soon).

@charmandermon
We're definitely looking at the various packages pointed out in this thread (as well as some other APIs) for gathering ideas and inspiration.

 

Decent UI framework, and now this?
You guys are going to spoil me. Thank you very much.

Quick question, If I hook up to the event stream, I would have to do control mapping myself correct? So I would have to make a script that maps from space bar to jump. This is not a big deal at all, I just want to understand the design a little better.

 

You have both options. The idea is that you get to see the event stream before the input system processes it into state changes. At this point, you can rewrite the stream at will. If you remove all events, there will be no state changes for the input system to record so in effect you are bypassing the system and yes, in that case you will have to handle any mapping yourself.

However, if you simply listen in on the stream or just modify some parts of it, the events you are letting pass through still reach the input system and thus affect the low-level state and the high-level mappings. Meaning, you can still use Input.GetKey and such even though you are also processing events.

 

Thanks, that clarifies a lot, and I can definitely work with that.

Another question: Unity is single threaded, so how do you handle events? are they delivered on the UI thread? If so, how does it work? do you accumulate events in some queue, and then when the UI thread is free, you dispatch the events?

Can I push events myself? so for example, if I have this weird controller for which unity does not have a driver, I could write a driver myself and push events.

 

Yes, at the API level everything happens on the main thread. The scripting API for new input functionality is still very much in flux but there will likely be a C# event that will get triggered in the update loop before we do any input processing. The events will be collected internally and possibly asynchronously.

Yes. While this too is in a bit of flux ATM, the current design lets you synthesize arbitrary input devices from script which will then coexist at the same level that the existing devices like keyboard, mouse, touch, etc. do.

As you have full control over the event stream, injecting arbitrary events is possible. In fact, you can rewrite the entire stream however you want including injecting events for arbitrary devices (i.e. not just for those you have created).

 

Yes, we can do that. Stay tuned. May be a while before it appears only because there's other systems we want to cover first.

 

Hey everybody. Thanks for the load of feedback. Looks like the amount of feedback is settling down, so here is a summary of everything I see. If I'm missing something, please let me know. I'll work with Rene to go through everything and be sure we looked at it, but this list doesn't mean we'll implement all of it; we just want to be sure we captured the feedback correctly.

No particular order...

• Multiple controllers
• Per-player controls
• Ability to bind (multiple) controls to an Input event
• Input binding as a separate layer on top of raw input device access
• Don't limit the number of keys/axis that can be assigned to an action
• Do allow the same key to be assigned to multiple actions
• Make sure all inputs can be recognized for an action
• Input simulation (cause input events)
• Input events instead of polling
• Consume input event to prevent propagation
• Ability to configure input, controls, axis at runtime
• Pickup all keys like right shift, etc.
• Framerate-independent input
• Ability to ignore keys or controls
• Complete script API for everything
• Vibration support
• Better built-in touchscreen gestures like twist, pinch, swipes, doubletaps
• Input settings can configure everything
• Ability to sample input for choosing key(s)/combo(s) in settings
• Input settings defaults to save keying the same values again and again
• Better support for common Gamepads
• Better KeyCode naming for Gamepads
• Virtual controllers so inputs can be mapped into a single controller for use in code
• Detect when different controllers are plugged in at runtime
• Notification events for everything so no polling needed
• Ability to associate meta-data with controls that can be accessed at runtime
• Hide device unavailability so invalid queries return neutral values
• Make sure FixedUpdate doesn't lag behind Update
• Low-level access to input history with exact timing
• Double click, and double click timing, support
• Configurable repeat rate on controls
• Deadzone filters and configuration

 

There is very little about this post that doesn't show just how poor of a state Unity's input system is in. I mean, the other things would be nice, but the stuff highlighted are things that should have been done years ago. Literally years ago. Unity 2.x years ago.

 

Yep, we're on it.

 

and we can use it when?

 

When it's ready of course We will consider the feedback and discuss, come up with a roadmap and share that (and additional comments are welcome). But it's not possible to give dates, sorry. We will be able to give progress updates.

 

of course, I didn't actually mean when it was going to be released, I was asking if its going to make it into 4.x? or even 5.0?
and I guess that list of features you've given is enough, and I would take a look at this thread if i were you

 

Thanks for the thread link, we'll make sure we look at that too.

It won't make it into 4.x series because it's a complete rewrite from the ground up and may effect existing stuff and have a lot of side effects. So it's a 5.x thing.

 

no problem,
oh god, I was so hoping for a 5.0 re-write, but whatever, as long as we get all the features of 5.0, we should be able to wait for 5.1 or 5.2,

 

I know. Better late than never is all I can say

 

Pixar's Multitouch Gestures as Regular Expressions ( http://graphics.pixar.com/library/ProtonChi/paper.pdf )

A native implementation of this would be lovely

 

Not sure if anyone asked for this yet, but we need the ability to map more than 20 buttons per joystick device.

Almost all the serious pro joysticks have more than 20 buttons, especially ones like the popular Saitek models eg: http://www.saitek.com/uk/prod/x52pro.html

More than 20 buttons may sound like a lot, but if you take a look at that joystick example you see there's not that many buttons really. Yet it still requires 32 or more button ids. Keep in mind that the button count adds up fast due to all the hats needing a button mapping per position (4 or 8 positions!) and there are also physical buttons with multiple positions that are each a software-mapped button themselves.

Without support for more than 20 buttons, Unity CANNOT be used with these pro joysticks. The customer will not accept that some of their device's buttons are simply unmappable by the game. This is causing me major problems when trying to produce a serious space sim that will allow support for these pro joysticks.

Thanks!

T

 

Agreed. Our goal is a system that has no inherent hardcoded limits (well, none that practically matter) on the particular makeup of a device. If there's 400 buttons and 40 different axis controls on your input device, there's not really any good reason not to give you access to all those through the API.

 

And unplugged!
We need GUIDs to come with these events (i.e. some unique per device ID) so that we can properly handle how to reconnect a player to his/her character

 

Wow Unity3D's Input system is getting pulled out of the dark-ages (JK)

I took my time to read this pretty carefully after having worked my own input mapper for a year now I surely understand why "all" complain about the current solution in unity and I'm looking very forward to this but I do find it sad that the feature was first requested 5 years ago and first now you decides to add it... I hope with unity 5 We'll see even more dark magic than already shown in the trailer(s) I do especially look forward to see the new multi-threaded system and how well/faster it runs

 

BTW, you lose the use of the gamepad/joystick when you switch to another application. This is normal for the mouse or keyboard, but for others? !!

 

any progress update?

 

ATM wrapping up 5.0 is slowing down work on any post-5.0 features but it is still progressing. I expect things to get back to full speed after 5.0 has shipped. We're into the third iteration now and based on outside feedback and internal reviews, there's been quite some changes through the iterations. The biggest change is that we're moving much more functionality away from native into managed and open source land.

 

Maybe I just missed it but will there be support for HOTAS (Hands on throttle and Stick) controls with Unity3d 5.0?

Will end users be able to re map their key bindings?

 

Not for 5.0 AFAIK

 

Ok thanks for the info

 

When adding support for re-binding actions ingame there needs to be a function to retrieve a localized string of what key was just pressed. If a user with a german keyboard binds shift+ü it has to show shift+ü in the rebind menu, not shift+semicolon.

 

Yup. The current approach is to have both the translated and untranslated key code in the event. So, say you are seeing a key down event on the physical "W" key with a French keyboard layout active; you'd be getting the virtual key code for the W key in the untranslated field and the virtual key code for Z in the translated one. Maybe there's also going to be a manual translation function. Not sure yet.

In the higher level binding system you'd probably get a switch on a mapping to say whether you want translation on the binding or not. Something like that. But that's all conjecture ATM.

//EDIT: Ah, and of course, the key code -> string translation also has to be able to cope with this like you say.

 

@Rene Damm

Can we have a update status ( Brain storming, proto, dev,Q&A,beta) ?

I have problem with resetInputAxes which reset all Input. It's horrible :'(

I'm happy for the creation of new system.

 

Not much has changed yet since the last update three weeks ago. Or well, what changed is that things are even more focused on getting 5.0 out the door. Before that ship has... ehm... shipped, I don't expect major news for the input system unfortunately. It's happening but 5.0 is currently overshadowing all other work.

So, do you I understand correctly that the problem is that the API resets all inputs instead of allowing you to reset individual inputs?

 

I had hope thks for answer ^^

Yes totally. I want reset axe "Horizontal" and "vertical" but not mousebutton

 

Ok cool. Thanks for the feedback. Makes sense. On the list now.

 

I would like to see support for HOTAS (Hands on throttle and stick) controls as well as better flight stick controls.

I know I said this before but - With Space Sims such as wings of saint nazaire (Unity3D), Star Citizen (Cryengine) and others making a comeback it would be beneficial to have this in.

 

I just wish that my Wacom Bamboo tablet worked with the terrain editor.

 

The first goal is to expose from the platform support we already have all the information that is there. That includes all the button and axes found on a device. Also, stuff like vibration controls. That should go a long way towards dealing better with complex joysticks and, in general, devices that mix a lot of individual controls.

Beyond that we'll have to see. I'd like to take a look at better supporting driving wheels and flight controls, but first all the core stuff needs to be solid.

Being a huge Surface 3 fan and seeing how pen input is actually becoming much more mainstream these days, I really want this as another first class input source in the low-level system. Complete with pressure, tilt, and everything. It's on the list.

Pressure-sensitivity in the terrain editor is somewhat its own thing. I've put it on the feature request list for the terrain guys (we finally have a dedicated terrain team, yay!).

 

ABOUT TIME.

 

I've been writing the input for a small side project over the past couple of days, and have actually come up with something to add to my list:

Platform- and controller-specific default input bindings. Depending on the controller(s) being used, drivers and OS support, you'll often need different bindings for the same thing. Letting the user re-bind stuff is only a partial solution, we also need to be able to set sensible defaults for each hardware setup we support.

I'm using cInput, where bindings are set in code. This isn't as nice as Unity's built-in approach, but it does have a neat side effect that I can check what platform and controller type the bindings are for and hook them up appropriately.

Being able to do that in a GUI and with a native input system would be sweet.

 

Which FlightStick/HOTAS controls specifically? I am interested in what you are using. There is CH and Saitek and GoFlight and other more expensive types.

 

something i really really really want:

2 mice, 2 keyboards .. 1 PC .. so i can make splitscreen "couch coop" PC games..
i bet its a multimillion $ concept..

i guess i dont know how many people are like this but, me and my buddies wish all PC games had that option... having to carry our PCs to our friends, and having to mess with setup and "can you see my computer" when LANing and stuff is a super pain... (we've learnt to Hate steam, since we're rural and had dialup until 2007, and not 8mb/s until 2012? .. the mandatory updates are intolerable.. ive avoided steam until like 2 months ago)
I guess alot of people prefer online multiplayer?? but i dont.. i wanna laugh with my friends in the same room..

i know its probably not that popular, but it should be ...only reason its not is greed...
like, theres some xbox games that could totally be splitscreen, but nooo they make you have 2 xbox, 2 games... its just silly and obvious greed..

 

Those type split screen of co-operation games are nice. Have you looked at X-arcade's Tankstick controller from X-gaming? Since Tankstick emulates a keyboard you can use the two joysticks and all of the buttons directly in a game without too much effort. You did not mention the style of game that you were interested in but I just thought you might be interested in such a controller.

http://shop.xgaming.com/collections...usb-included?gclid=CPa0kcXHtsICFcdj7AodFl8AVA

 

well its not about what controller to buy... its about, being able to cater to the customers of the game I'd make.. the customers shouldnt be expected to buy that controller(and i shouldnt create expecting such)... BUT.. i assume most people that are PC gamers, most possibly could have 2 keyboards and 2 mice.. (most PCs come with a pair, and then PC gamers buy a better or "cooler" keyboard/mouse) or friends would have them.. i personally have like 4 keyboards and like 8 mice? .. from over the years.

I think its possible to make Unity work with 2 keyboard, 2 mice, 1 PC .. ive looked around and found many different possible ways to make it work... but i havent gotten to the point in my projects that iam to worry about that exactly... (kind of a last finishing touches kinda thing)

but itd be Great! if it just worked "out of the box" for Unity.

 

Really? Interesting... I always thought that it was an OS-level limitation, in that keyboard/mouse input is aggregated before the engine gets to read it. It's been yonks since I wrote that stuff, though, so I could be wrong.

 

I am sure you can get Unity to work that way if you do not mind writing low level code and device drivers to handle it.

Multiple mice is something that can be made to work. Mame supports multiple mice so you can play Atari's coin-op Marble Madness with two people. Microsoft has a SDK to support 25 mice (requires a later version of Microsoft .Net) if you take a look at this url for more information.

http://www.microsoft.com/multipoint/mouse-sdk/

As long you do not mind writing your own device drivers and pulling apart USB messages directly it can be done. How much time do you want to spend on that is the question.

It would be interesting for you to get a thread started on how many people would be interested in games that support two keyboards and two mice.

 

It have been sometime I posted last here but here's a few things I would love to see added that have come to mind...

1: Ability to customize input at runtime, this is maybe one of the biggest features missing, and last I checked (it's a while ago tho) this wasn't possible.
2: Ability to have "control Keys" (Shift, Alt, Ctrl etc.) that can be combined with other input key to create "keybinding" input (eg Shift + 1, Ctrl + 1).
3: The current system where you can check on a string seem very appropriate and I would like to see this kept in the system.
4: would love to have every field or almost every field in the input system accessible from code.
5: Joystick support... I know you already have this but... yeah... it's basically useless versus most other implementations.
6: Fps independent (as already mentioned).
7: Event based inputs would be great too rather than needing to pick them up my self from the event class, a very simply thing that comes to mind is a method like this: "OnKeyboardButtonUp(Event e, EventArgs args)" and the same for pressed, down, and mouse etc. possibly the best way would be to have it as a component, and hook it to a set of input rules, or input hardware.
8: Support for binding hardware to a set of rules, I feel like this would be great for controllers and multiplayer/splitscreen game so that you can define that "joystick 1" executes a curtain function or trigger an event, but rather than setting this up for 2 joysticks it should be possibly to just say this is the rules for this joypad, and bind 2 joypads to the same set of rues, but execute different functions/events

 

Have you looked at Rewired - Advanced Input System for Unity? It is available in the asset store and they do have an eval version available also.

https://www.assetstore.unity3d.com/en/#!/content/21676

The reason I liked Rewired it handles every individual button on my CH product flight simulation FighterStick. For FighterStick all have individual names of the buttons and axis are available in the profile. It also supports RawInput and DirectInput which is good since some HOTAS setups use one or the other.

 

Already written my own open source implementation of an input mapper which have some of the functionality mentioned above Works great and is pretty fast so far, only need to find time to implement a better multi input funtionality , It is possibly far from better than most "high-end" solutions out there but it do the job... Also, I'm not looking to buy anything either, it was only what I felt would be great for a new input system

 

There is a input method hard coded into unity OnMouseButton which triggers whenever we click the left mouse button, but that one goes based on where the mouse pointer is on screen, how about one for a default screen vector from center of screen out (with a distance we can specify otherwise it is infinite)? Also a much better lock and hide mouse pointer feature for both the editor and compiled game?

 

My main issue was having a system that works with Unity 4.x today and not waiting for Unity 5.x. Also I am not as dedicated as you to write my own input system. That is interesting that you made yours open source. Is there a reason why you made it open source rather than keep it proprietary? It would seem to be useful for a competitive advantage.