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

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?

 

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.

 

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.

 

We need the separate function calls in order to be able to let various devices and action maps choose to use a given event or not, and in case it's used, it should not be available to subsequent handlers. This is a core part in the design of ensuring that the same input doesn't accidentally affect multiple things at once (like controlling the character and a menu at the same time for example). I'll leave René to discuss the performance aspects - he's currently on vacation though.

FixedUpdate has to be called consecutively due to how a game loop works. We can't call FixedUpdate evenly spaced in real time, in the middle of some frame rendering. But we will feed each FixedUpdate only with the events with timestampts going up to the time that the FixedUpdate corresponds to. This way they will work as if they were evenly spaced from an input point of view, even though they're not.

 

Is this actually getting built correctly from low level so we can get real OS RAW input on mouse atleast?

 

I've yet to try this new input system out, I probably would have if it was actually getting updates that started to show it was worth implementing over the current input system..... but I've never seen a single update since this thread started...

Its been over 3months already what is the progress of it now?

 

Yes a update and next beta would be nice?

 

How stable is the API code?

+1 update the code.

 

It appears the update to 5.4 breaks at least some part of the prototype.

I now get the following error from Unity when starting a scene.

Code (CSharp):

1. get_isPlayingOrWillChangePlaymode is not allowed to be called from a ScriptableObject constructor (or instance field initializer), call it in OnEnable instead. Called from ScriptableObject 'ActionMap'.
2. See "Script Serialization" page in the Unity Manual for further details.
3. UnityEngine.InputNew.ActionMap:.cctor()

It hasn't seemed to have affected input as far as I can tell (it appears to be working) but is a bit....scary to know something is probably broken somewhere.

 

Data-driven mappings? Awesome.
Data-driven state? Awesomer.
Intellisense support and *no strings*? Vewwy awesome!

 

Hi all,

I can understand the desire for an update on the status of the Input System!

The status is that we're working hard on it. There's still a lot of work to be done, especially given we're a small two-person team.

One thing I should make clear is that the final system will not be directly a continuation of the prototype. As you know, the final system will have a brand new backend, as opposed to the prototype which is built on top of the current (old) input system. Furthermore, we're still doing a lot of development and refactoring. All this means that

1. The final system will not be fully compatible with the prototype, but will be very similar in overall design.
2. It's not viable for us to provide continuous updates to the prototype since we're internally working on the proper release version, and doing updates of the prototype version would take resources away from that.

Some of the features we're working on integrating support for at the moment are:

• Haptics / rumble support. This is a major design addition when taking into account how it affects ActionMaps, and that the haptics/output capabilities of different devices are very different.
• More flexibility in controls and control bindings. We heard you - you need to define modifier keys, key sequences, response curves etc. These features in themselves are not the important part in the work we're doing now, but rather ensuring the bindings and controls framework is designed such that it's easy to implement all these things and more, both for us and in user extensions. We're also handling some other considerations for how the controls work while we're at it.

There's many other things than this too, but those are two of the big ones.

I want to thank you all for testing the new input system so much and providing detailed feedback. This has been a great validation for us that we're on the right track and should go ahead full power with the proper release version of this, taking all your notes and suggestions into account as well.

This is not to say that we won't be needing any more input from you. Once the proper version of the input system is in a sufficiently usable state, we'll enter into a new period of close feedback cycles with all of you. But bear with us while we're doing the work to get to that point. Thanks for your patience!

 

Phew! I was afraid it wouldn't replace the existing system and get it's own place in the editor, rather than being an extension to the current system. Thanks for reassuring me that that's not the case, because this new system is awesome and the old system should go to h***

 

Is there a version of this for 5.4 to play about with? (Obviously not for a production release) Also what kind of feedback are you looking for with it?

 

Sounds good. I would like if a input layout was made such that a keyboard & mouse with simulated SW X-Box/PlayStation/Android Game Controller functionality, X-Box Controller, Play Station Controller, & Android Game Controller, and equivalent of those as a SW touch controller where auto-detected and the controller template shown to the player with a toggle switch a game start.

I downloaded and went through about 20 screens of the app explaining how to control and play a mobile game from Major League Baseball (Their Line Drive application) that was way over the top and so specific to their game those game controls were. Too much work so I uninstalled in about screen 20 of their game controller instructions.

 

Well, it seems it's undergoing big redesign and not ready for beta testers. I will use the existing package as beta and see if that simplifies my task.

 

Thank you! Standalone keyboard player input is hard. We basically need the entire input system to be able to be bound with and without modifier keys for any action.

However, the biggest struggle that I'm running into right now is with localization of PC/Standalone input on international keyboards. I really want to make try to see if Unity can provide me with the localized keyboard character/name for the key press (in a cross-platform way) and allow me to bind layouts based on keyboard position. So that in the UI we can show the player via tutorial hey the OEMQUESTION keyboard command is a "/" character in the US an a "!" on a French keyboard. We want to support better localization, but it is hard and not cross-platform. We want to inform the user "Press {0} to open Journal" regardless of which keyboard localization they're using. Or if we're making a first person shooter that is defaulted to WADS controls are bound to to ZQSD by default. We need this support not only in the launcher but be accessible in-game player APIs so we can present the binder in a more branded/skinned way.

 

+1 to Ferazel's comment:
* Allow binding to keycode and scancode (have inventory bound to "I", movement bound to WASD-positions)
* Get localized key name from keycode and scancode (scancode as well because we need to display the letter of the WASD-keys on non-QWERTY layouts; localized name is necessarily in system language)
* Allow recognizing binding conflicts between scancode and keycode (there is preconfigured binding both to scancodes and keycodes; key binding dialog needs a way to recognize conflicts with both types of binding if user re-binds a command)

Necessary for lots of games to do key binding right, on Standalone platforms, and if possible at least on XboxOne and PS4 as well.

 

Oh, come on!!!!
That's the first thing that came to my mind when I read about the new Input System.
Having to ask people to download a driver is not cool, I was hoping the game would include a driver.
You can do it!

 

So, if I'm correct in thinking having a game include a driver would actually be down to the developer of the game itself and not the unity team. Especially since there are probably distribution licenses associated with the drivers in where they can only be downloaded from x site and not included for distribution...

 

It's my impression driver installation is the responsibility of

1. Hardware manufacturers
   
2. The OS
3. The user

Having games begin to install hardware drivers on your system seems like it'll open a can of worms. It's possible I'm missing something though. If you have examples of games or game engines that do install hardware drivers, please start a new thread dedicated to discussing this and let us know about it there. Thanks!

 

This might be discussed, so ignore if I read over it but:
Hardware specific drivers are a no-go of course, but addressing the platforms' hardware abstraction layer like a direct input to support rumble vibration on a gamepad should be pretty standard on any game engine.

 

This is all great!, What about real RAW input for Mouse on PC atleast? It's a MUST plx!

 

4. Digital Distribution Platform (even Setups from a disc) e.g. Steam, Origin, UFail, Bethesda.net.

 

What about native touch/mouse gesturing support? *runs away*

 

What about multitouch actions support on devices with touch?
like for example: pinch to zoom, 2 fingers to rotate object, ... etc.

 

Input is a very large area. The new input system effort was started primarily to solve a lot of fundamental problems with input from controllers that are not easy to work around in scripting, but it will cover all input devices.

It won't include a gesture system though; at least not in the beginning. We have to reduce scope somehow or we'd never be able to ship. There are many solutions available for handling gestures for Unity that work quite well, so it's not as critical as some of the current controller-related shortcomings. Thus, our priority for now is to make sure the input system handles touch well enough to easily integrate gesture controller on top of it, but not to include such gesture controllers out of the box initially.

 

Hi @runevision
I found the following comment in the code:

Code (CSharp):

1. // TODO: Fix error.
2. // get_isPlayingOrWillChangePlaymode is not allowed to be called from a MonoBehaviour constructor,
3. // call it in Awake or Start instead. Called from script 'ActionMap' on game object 'MenuActions'.
4. // See "Script Serialization" page in the Unity Manual for further details.

Do you already have a fix for this?

That error is quickly followed by an ArgumentNull Exception that happens because a key for a dictionary lookup is null.
That doesn't allow me to get any input because of one of these errors.

 

This looks very interesting, and may solve a lot of the problems I've had with Input. Full disclosure, I've watched the videos, but haven't tried it yet.

One thing I need, and I'm not clear on, is whether it will allow for specific controller assignments. In other words, I have a driving game and I only want the steering wheel controller to work for it. I don't want them to be able to play with any gamepad. When I set up the ActionMap, can I declare not that the input comes from a GamePad, but that it specifically (and only) comes from a specific controller?

 

Short answer: We don't have a fix right now.

What we have here is a version of the input system that's completely refactored compared to the prototype that was released, and we're working on getting that wrapped up. The problem you mention is fixed in that version, but it will be a little while yet before it's ready. When it is, it also won't be backwards compatible due to extensive changes.

I'm not quite sure while this error happens for you and is preventing the system from working entirely; it might be related to subtle changes in newer Unity versions. We're working hard on getting the new system ready; in the mean time, sorry for the inconvenience.

 

Do you mean a specific controller connected to the computer, or a specific type of controller?

You can always look through all connected devices and pick the one you want (using your own code to recognize the controller e.g. by name or similar), and then assign that controller to a player.

If you mean a specific type of controller (e.g. a steering wheel) and you want it to work out of the box with an ActionMap (without the player needing to hook up the controls) then you'll need a Device Class that corresponds with that type of controller. That might be a generic SteeringWheelDevice or a more specific LogitechBlaBlaModelSteeringWheelDevice. We intent to ship with certain standardized devices out of the box such as Gamepad and also SteeringWheel down the line, but it will also be open source and extensible so anyone can contribute device types and device profiles.

 

Are you guys planning on supporting the steam controller and it's 'Strange' hardware setup?

 

The Steam controller is a challenge we have waiting for us for when we have time to tackle it. Our aim is to support it but we can't say in exactly what way or to which extend.

 

I imagined that would be the case. It seems your designs would be compatible with their requirements though.
I mean their controller is so "simple" that valve requires has an api to support it.

Good luck guys, great work so far!

 

Looking forward to it
Thank you a lot!

 

Since it's been a while since the latest status update, here's one again.

The status here is still valid overall:

Some of things we're currently working on:

• Test coverage.
  
• Native VR support
• Standardized controls (a conceptual evolution of our concept of standardized devices)
• Output (haptics, rumble) (Yep this bullet point is still here since it got postponed by other things before.)

One of the things we already finished now we have our new back-end is support for reliably querying input in either Update or FixedUpdate.

We don't have any official timelines to share, but I expect that by around summer time we'll have a public experimental preview - yes in experimental state again, but this time of the proper implemented feature and not a prototype based on the old input system. Then we'll iterate and expand platform and device reach from there.

Thanks again for your patience.

 

I may have miss read this somewhere or been out the loop for enough time. Please no hate. using Unity ver. 4.6.1"""

Will we be able to allow our users to remap keys using the new input system, at run time {in the game as an options menu} (not as a part of the launcher), or will we still be forced to use 3rd party/own extensions/assets for that functionality?

__Basically manipulate what key is mapped to what at run time, via script__

If the whole/part of the objective of this "upgrade/update" is what i just asked. Again, Please no hate.

Some Clarity is much Appriciated.

 

Yes.

We may not have polished sample UI for this in initial versions, but the API to do it is definitely there. You can then extract the customized bindings in a string that you can save on disk, in the cloud, or using whatever save mechanism you choose.

 

Thanks for the epically fast reply Strength to your fingers, Developer "".

 

a whole year Unity.. to end up at just another experimental again.. I mean you said it, it is dissapointing that nothing about the input system is going to be a proper release even if beta, even if it leaves out some stuff that is experimental and only given updates as these experimental releases currently are. ie every so often updated alongside the codebase of the beta releases. Surely enough of the core new input system is finalized enough to be something us end users can start making use of in projects and moving over onto along with the beta releases.. yknow for us insane bleeding edge users who just like to build projects on the latest builds

 

Is there any chance you can focus 100% on getting only the API out first, and then once the API is final, add the editor part?

 

That is indeed our focus, but it's impossible to design a great API without ever having written any code that uses that API in its intended way. So there's no way around creating some kind of limited editor part too in order to ensure all the needed API actually exists.

 

Hey @runevision

maybe it was already answered and I think I might have read it somewhere, but just for the record:
will we be able to get the actual timestamp when we use the new InputSystem in either ways(events, polling etc.) and ideally also the state of that input (up, down, pressed etc.) ?

 

I'm interested in this new input system but how would it handle runtime rebindings? Also, I would like to get certain "Axis"-only inputs as buttons e.g. Scroll Up/Down