Search Unity

  1. Get all the Unite Berlin 2018 news on the blog.
    Dismiss Notice
  2. Unity 2018.2 has arrived! Read about it here.
    Dismiss Notice
  3. We're looking for your feedback on the platforms you use and how you use them. Let us know!
    Dismiss Notice
  4. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Learn more.
    Dismiss Notice
  6. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  7. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  8. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Input System Update

Discussion in 'New Input System' started by Rene-Damm, Dec 12, 2017.

  1. jjejj87

    jjejj87

    Joined:
    Feb 2, 2013
    Posts:
    189
    I am writing this list here because this is not a suggestion or a feature request, but a "must" for an input system.

    1. Ability to set mouse position
    2. Minimum input delay and if delay of some sort is inevitable, make it so that the delay itself is consistant.
    3. Allow UI object drag to be matched to the cursor (I don't mind the actual method as long as there is a way to drag UI without that elastic band effect)
    4. Allow runtime configuration of keys and all
    5. Ability to set cursor graphics bigger than 16x16 (or was 32 x 32?) while hardware accelerated. This alone could solve number 3.
     
    goncalo-vasconcelos and Player7 like this.
  2. Brad-Newman

    Brad-Newman

    Joined:
    Feb 7, 2013
    Posts:
    67
    Awesome to see this starting to take shape! Is this currently working with Rift Touch and Vive?
     
  3. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    The XR team is working on hooking up XR support for a release concurrent with the other platform backends. Having the new input system support all headsets and VR controllers already covered by Unity is high up the list.
     
    HeadClot88 and Brad-Newman like this.
  4. wuzibu

    wuzibu

    Joined:
    Dec 15, 2014
    Posts:
    10
    Yes a how-to: lets say 2 controllers parallel active and navigating over 2 different grids in 2 different canvas.

    To make multiple inputs possible I followed this blog-entry and was finally able to achieve that. The only thing left was adjusting it to my systems and avoid that one player could accidently move/interarct in another active UI. (due to auto navigation)
    http://blog.pastelstudios.com/2015/...ultiple-event-systems-single-scene-unity-5-1/

    but it seems that someone already solved the current issue in 2017.3 by himself in this recent post https://forum.unity.com/threads/solved-multiple-eventsystem.512695/

    But I'd still could imagine that a lot of people might run into this.

    Thanks for the good work you did already and for the response, though!
     
    Last edited: Jan 28, 2018
  5. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Is something like this what you have in mind?

    The Cursor API will likely stay unchanged for the initial release but even beyond, I have doubts this one will prove doable. Hardware accelerated cursors are subject to restrictions that are outside of our control (that 32x32 size restriction isn't Unity's but rather goes back to the OS/GPU). We can try to mitigate the negative effects of using software cursors (stuff like minimize lag, make unaggregated mouse deltas available) but I think the wiggle room we have with the problem is limited.

    My guess is a good drag&drop feel will continue to largely depend on good framerate and low input latency.

    Interesting. We haven't yet started writing the input module to integrate the UI system with the new input system but when we do (coming up fast on the list), I promise we will take a look at this.

    Thanks @wuzibu :)
     
    Ethan_VisualVocal, wuzibu and orb like this.
  6. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    658
    Can't agree more! There is no game or application that I know of that "solves" this problem anyway.
    Either you make the best of the 32² space (world of warcraft just takes the item/skill icon and adds a little triangle to the top left), or you have to just have to deal with the delay (for example when you are dragging windows).

    The only thing I know is DWM.exe on windows which does some black magic to make window-dragging seem super-responsive. But maybe that's just some trick...

    Also, latency issues are very much reduced when you have: an actual build (not editor) + exclusive fullscreen (not "windowed-fullscreen"). The editor in play mode has some pretty large lag, but that is to be expected and not a real problem at all. Same thing for audio delay by the way in the editor I have a measurable 300ms lag, in a standalone build I get the optimal <50ms just like other games and applications.
     
  7. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    383
  8. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    We're looking into getting a package up on staging soonish but unfortunately it won't be compatible with 2018.1 as the native changes haven't landed yet (the preview build we did was still based on a custom branch). But... we're getting close :)
     
    JakubSmaga likes this.
  9. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    309
    Will the native changes land somewhere in the 2018.1 beta cycle or are they more likely to be in the 2018.2 beta cycle?
     
  10. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Heh, given our past failings (see first post in thread), you can probably tell I'm squirming in my chair a little :) What I can definitely say is that they won't be in 2018.1. We're working hard on landing after that.
     
    dCalle likes this.
  11. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    309
    That's fine. I'd rather y'all take the time and get over the hurdle than rush it. The other 2018.1 features have kinda taken my active interest at the moment, so you're safe for now as far as I'm concerned. ;)
     
    dCalle, Vanamerax and Rene-Damm like this.
  12. orb

    orb

    Joined:
    Nov 24, 2010
    Posts:
    2,796
    2018.1 proper could be a month to 6 weeks away, so 2018.2 beta isn't a long wait now. If the input system is ready for testing I'd say that's a better target for testing :)
     
  13. StefDevs

    StefDevs

    Joined:
    Jan 20, 2014
    Posts:
    4

    I was just now very close to either trying out SlimDX or starting to writing by own native input, but I'm very relieved to read this post. I probably will still do my own eventually but I'm very glad you guys have supported this kind of flexibility.

    EDIT: I should probably note what I'm referring to, which is the ability handle the input stream manually and process a history of input (with time stamps) as opposed to only having access to aggregate state.

    If someone could provide an example of how to "tap into the event stream directly" I would be quite grateful.
     
    Last edited: Feb 9, 2018
  14. BlisterFingers

    BlisterFingers

    Joined:
    Sep 2, 2015
    Posts:
    11
    So still no idea when this will drop? I have a sneaky suspicion it will be 0.1 seconds after I cave in and spend my already over-stretched budget on InControl or Rewire.
     
  15. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    309
    If you decide to break, Rewired is fantastic. Unfortunately it doesn't play well with .NET 4.6 support at the moment.
     
    guavaman likes this.
  16. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    3,163
    I've done everything I can to make things work including quite a few obtuse workarounds for bugs. Unity has fixed a number of the major bugs in .NET 4.6 preventing it from working properly, but they've just regressed and broke it again in the 2018 beta.

    Edit: The issue has been fixed in 2018.b6 on Windows.
    OSX issues related to non-functioning dllimport operations have not been re-tested.
     
    Last edited: Feb 13, 2018
    Shawn_Flanagan likes this.
  17. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    ATM the API works like this:

    Code (CSharp):
    1. InputSystem.onEvent +=
    2.     eventPtr =>
    3.     {
    4.         // eventPtr is a wrapper that internally refers to unmanaged memory containing the event
    5.     };
    6.  
    The plan is to have more than just a callback-based API. We want the ability to gather and process events at a point that is determined by the caller. Something we want to have for actions as well.

    The above API has the advantage of sitting right in the system's event processing loop. You can mark the event as handled, for example, and the system will skip it automatically.

    While the eager dev in me wants to shout "WAIT FOR US" or something like that, the more rational part in me would say, if this is something you need solved NOW, don't wait for us. InControl and Rewired are proven and battle-tested solutions. Even if we hit the next Unity release full force with the new stuff, fact is we're still sitting on something that will have to undergo a phase of stabilization and maturation. Of course also largely depends on the timeframe you're operating in. If you need to ship within the next six months, I'd say the new input system isn't a good bet to make.
     
    sand_lantern likes this.
  18. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    383
    Hello @Rene-Damm

    [Question 1]

    Right now I'm working on keybinding for my game and as you might know, there's some bugs when trying to get mouse input when using Event.current & inputString.

    Is ISX going to fix that?

    [Question 2]

    Since ISX is going to be provided via Package Manager, do you know if ISX is going to be split into Touch package, Keyboard & Mouse package, Controller (X1/PS4) package or is it going to be just 1 package? let's say that a person which creates a mobile game only imports Touch package into the project to save up application memory/editor build time/performance. Have you been thinking about this concept?

    Thanks.
     
    Last edited: Mar 4, 2018
  19. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    In terms of fixing existing input paths for IMGUI and the old input manager, no. But in terms of providing a working solution within the new APIs, that's definitely the goal.

    What are the problems here? TBH I'm not aware of the problems here with Event.current & inputString. Could you elaborate a bit?

    The plan is to ship as one package for now. If we split it up, thoughts so far have been more along the lines of splitting off the action part from the devices&controls&event layer.

    But yup, we've been thinking about that concept. The system is already split into several different DLLs with a platform-independent core and then a number of plugins that add support for specific devices.

    This stuff is still pretty early in its inception but what I'm envisioning is being able to determine exactly what device support goes into a build. I think this will become even more important when we get to the point where devices are no longer just code but also come with assets (images&models) that might be included in builds.

    As an example, there is a plugin for XInput controller support here. This should automatically be disabled on all platforms where it is irrelevant. For the code, it'd be easy to just tie that to the build settings of the .asmdef files. But once we have data like controller and control images in there as well, we need more than that.
     
    Last edited: Feb 14, 2018
  20. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    383
    [inputString]

    Currently, I'm using:

    Code (CSharp):
    1. KeyCode pressed = (KeyCode)Enum.Parse(typeof(KeyCode), Input.inputString, true);
    2. print(pressed);
    Inside my Coroutine.

    Which works for normal keys like W, A, S, D. But when it comes to Mouse, Space key, Return key, UpArrow key, DownArrow key it just throws an error:



    Another problem is that when the users press 2 keys at the same time it also throws an error:



    You can try it yourself, just make an empty Update() method and put this inside:

    Code (CSharp):
    1. (KeyCode)Enum.Parse(typeof(KeyCode), Input.inputString, true)
    -To see the 2 keys bug.

    Code (CSharp):
    -To see that it doesn't see special keys.

    Links:
    https://answers.unity.com/questions/1121835/inputinputstring-returns-empty-on-special-keys.html

    [Event.current]

    It doesn't work outside of OnGUI()

    Links:
    https://stackoverflow.com/questions...nt-is-null-reference-only-s-current-available

    https://forum.unity.com/threads/event-current-is-null.168343/

    Update: Fixed it by using
    Code (CSharp):
    1. foreach (KeyCode key in Enum.GetValues(typeof(KeyCode)))
     
    Last edited: Mar 2, 2018
  21. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    3,164
    To get what keycode is pressed in the current system, the only really viable solution is to iterate all of the enum values and check them one by one.
     
  22. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,051
    Event.current is part of the IMGUI system, btw. It's never going to work outside of OnGUI.
     
  23. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    I think that can't be expected to work. Key presses and text input aren't tightly coupled like that. Key presses may result in no text input at all, or may result in text input only after multiple key presses, and multiple key presses in quick succession will accumulate in inputString (the 2 key problem you've run into).

    While the APIs are different, you'll have the same problem in the new system. Key presses and text input are two separate input paths. To print all key presses, you can hook into the event stream and filter for state events on the keyboard. Unfortunately, finding which key has been pressed has no nice API yet (the event contains a snapshot of the entire keyboard state) so ATM it requires iterating over all keys.
     
    JakubSmaga likes this.
  24. N3uRo

    N3uRo

    Joined:
    Dec 10, 2011
    Posts:
    480
    I want to suggest one thing. For new features and APIs I see that Unity now is following some high adopted code formatting conventions like properties starting with uppercase.

    https://github.com/Unity-Technologi...ssets/UnityARInterface/Scripts/ARInterface.cs

    https://github.com/Unity-Technologi...ipeline/HDRP/Decal/DecalProjectorComponent.cs

    But I see that Input team it's not:

    https://github.com/Unity-Technologies/InputSystem/blob/master/Assets/InputSystem/InputManager.cs

    Can you follow them like your coworkers? Can you speak internally (all teams) so you all do it the same way? It's really confusing.
     
    dadude123 likes this.
  25. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,051
    The new API naming convention is not for all new features - only specific ones, for now.
     
  26. N3uRo

    N3uRo

    Joined:
    Dec 10, 2011
    Posts:
    480
    But I don't understand why you can't make that switch for ALL new features, it's the right moment to do it. Later it will be difficult without using API updater and it will be more work for you.
     
    ZiadJ likes this.
  27. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Don't worry, this is covered :) The switch in our conventions is something that's only just happening in Unity. We have some code already following the new (Microsoft) conventions but most is still following our old ones (like the input system does). Just yesterday our scripting team passed me a document with over 2100 change requests mostly to update the naming. New code going forward will follow the new conventions.

    So yeah, this is the effect of us developing more out in the open. In olden times, you wouldn't have seen this intermediate step of evolution in the input system code.
     
  28. N3uRo

    N3uRo

    Joined:
    Dec 10, 2011
    Posts:
    480
    Ok, thanks.

    I'm glad that you are adopting that conventions.

    In the future it should be easier to accept pull requests on Unity github repositories.
     
  29. toxtronyx

    toxtronyx

    Joined:
    Aug 21, 2014
    Posts:
    114
    Hi there. Great news indeed. One thing I don't see covered so far (maybe overlooked it) is the number of supported axis/buttons. The current system fails with several input devices like Logitech G29 for example because of the to few supported buttons/axis. Is this going too be changed aswell?
     
  30. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Yup, there's no limit built into the system. A device just adds whatever controls it needs.

    Controls are not indexed with a global "master enum" like KeyCode in the old system.
     
    recursive likes this.
  31. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    3,164
    Wait, are you discarding the great readability of KeyCode.Joystick7Button8?

    What a shame! Whatever will we do?

    ;)
     
  32. XaloX

    XaloX

    Joined:
    Mar 4, 2016
    Posts:
    127
    Hello!

    I am making a multiplayer arena fps with Forge!

    I came across this awesome discovery looking at inputs regarding getting up to 4 players onto split-screen for Multiplayer. I saw the concept video!! Looks like it could be possible!! :)

    I figured out I would player input it and handle the scripts, and add spawning/server disconnection in the extra input, does that sound like a reasonable possible idea to do with the new input system?

    At its current state is it ready enough to pull of my idea (paragraph above this one)?

    Thank you!!
    Xalo
     
  33. toxtronyx

    toxtronyx

    Joined:
    Aug 21, 2014
    Posts:
    114
    AWESOME!
     
  34. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Technically, it should work even in the preview version but we haven't gotten around to building a proper demo and giving it proper testing so my expectation is that in practice, it's broken ATM. However, for release we'll be making sure local multiplayer usage is working properly. The setup is likely going to require more code than a single player setup (at least in v1 of the system, you will likely have to manage player<->device association yourself) but the foundational APIs should be in place.
     
  35. XaloX

    XaloX

    Joined:
    Mar 4, 2016
    Posts:
    127
    Is there a eta on when this will be done?

    Thank you!!! :D
     
  36. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    We're not yet "officially" committing to an initial release (still labeled "preview") in 2018.2 but that is what we're working towards. There's uncertainty around what level of platform support we'll have and uncertainty about what functionality we will manage to finish. Also, there's uncertainty around what other systems in Unity that currently depend on the old input system we will have support for.

    In short, still a lot of unknowns but things are progressing well.
     
  37. XaloX

    XaloX

    Joined:
    Mar 4, 2016
    Posts:
    127
  38. RealMTG

    RealMTG

    Joined:
    Jul 27, 2013
    Posts:
    200
    I just need to ask this. By looking at the commits it seems only one person is doing this; Rene-Damm. Is this the case? Are you the only one working on this? If so, why? Can't Unity afford to give you a coworker in this?
     
  39. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    1,608
    Please make local multiplayer a breeze
     
    mimicryArt likes this.
  40. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Heh I can see how it looks that way :) Especially from the commit history in a repo where I've made myself be the only person with direct write access :) (PRs are going in but they are less visible than the noise I make)

    Right now, aside from me, there are 5 programmers involved to varying degrees on various platforms. There's people working on QA and UX. There's a UI programmer scheduled to join. And there's a PM (hey Victoria) without whom this ship would probably be dead in the water just about now.

    It's not a one-man effort even though my face is the one that keeps popping up in every corner.
     
    recursive likes this.
  41. RealMTG

    RealMTG

    Joined:
    Jul 27, 2013
    Posts:
    200
    Ah, that's nice! Seemed kinda weird if there would only be one person working on this. But good to know that there are multiple talented people behind this! :)
     
    Rene-Damm likes this.
  42. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    The initial release will probably only manage "doable" rather than "breeze" but "breeze" is the eventual goal :)
     
    Lars-Steenhoff and XaloX like this.
  43. imphenzia

    imphenzia

    Joined:
    Jun 28, 2011
    Posts:
    397
    Nice to see that you are working on this! I am making an asset to simplify some of the more "mundane" tasks of making a game and time came for me to address input, local multiplayer, and control mapping. I started to design my system to abstract actual controls from player input and then I came a cross this preview feature =) I see above (and in the roadmap) that an actual launch date/Unity version is uncertain.

    Would it be reasonable to expect that the core fundamentals of the preview will remain or may it change significantly? I am trying to decide whether to release my system and/or support the preview.
     
  44. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    At this point the expectation is that the devices, controls, and event stuff will remain mostly unchanged. There will be some volatility in the API (and eventually a move out of UnityEngine.Experimental.Input) and some added capabilities here and there but overall, this part of the system should remain relatively stable and dependable.

    The action part of the system will likely see quite a bit of change still. Even the data format on disk for input action assets may still change. The UI will certainly change quite a bit. The API is likely to see several shifts.

    In other words, directly dealing with devices will expose you to limited change. Using actions to abstract you away from going to devices directly will expose you to considerably more change.

    Hope that helps a bit in the decision.
     
  45. Alan47

    Alan47

    Joined:
    Mar 5, 2011
    Posts:
    109
    I'm so glad that this is finally happening. For years on end I had two complaints about Unity: the input and the terrain system. I'm happy to see that one of them is being worked on and will hopefully be fixed soon.

    Does your solution also include concepts for allowing the player to re-map controls at runtime? Or is this still something the game developers have to do themselves on top of the input system? (disclaimer: I didn't download the preview, sorry if this is already answered there)
     
  46. orb

    orb

    Joined:
    Nov 24, 2010
    Posts:
    2,796
    PolyBrush is kinda, sorta a solution for the terrain problem :)

    It's always confusing when you've got several builds with the same numbers. How many current beta builds are there of Unity now? Will the latest one just work with all the experimental things you have now, including the input system? Is the one in the hub actually the latest, and how do I tell from inside the editor which of the two b12s I have, for example?
     
  47. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Terrain is being worked on too :)

    Yup, bindings are fully accessible/changeable/overridable at runtime. The entire action stuff can be made up / changed on the fly. We still have some way to go with the rebinding APIs so that it becomes very easy to implement a binding UI and get reliable rebinds from the right type of controls and without noise interference. But we're getting there. The basics are already in place.

    Yeah, sorry about that. Should have changed the version number on the preview before building it but frankly didn't think of that. Fortunately, this is going to not be an issue going forward as you'll be able to just use normal Unity beta builds instead of having to download separate input system preview builds.
     
  48. orb

    orb

    Joined:
    Nov 24, 2010
    Posts:
    2,796
    So can we hope for b13 the week after the holidays? :)
     
  49. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    316
    Heh no, the 2018.1 line won't get the native stuff.
     
  50. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    968
    Wh What what.. what do you know :cool: