Input System Update

I've gotten it to compile with the normal 2018.1 build. About to start using it more than just in a toy scenario.

You'll need to clone the repo listed above and checkout the develop branch.

Inside the Unity project structure the project will have a Packages directory as usual. Inside you'll find the manifest.json file and a com.unity.inputsystem directory.

Copy the com.unity.inputsystem directory and all of it's contents into your own project's Packages directory.

Then add the following package reference to your dependencies section:
"com.unity.inputsystem": "0.0.1"

Optionally, if you wish to add to the testables section, just add:
"com.unity.inputsystem" (no version string or additional key).

 

The Hub looks like a lot like a reactive, late-to-the-party attempt to copy the Unreal Engine Loader, not a positive, proactive endeavour.

 

That's a very off-topic comment, but I found that it worked just fine for multiple Editor installations. My short time testing the Unreal Engine Loader however, was a really terrible experience (although their Enterprise version is slightly less annoying).

 

Wait, did you mean 2018.2?

Excellent run-through on the instructions BTW.

Minor note: version recently changed from "0.0.1" to "0.0.1-preview".

 

I got it to compile, but so far it reports the # of devices as 0 and doesn't seem to be processing any events.

I used both actions and polling shortcuts for both gamepad and keyboard. I did debug the bootstrap process so it looks like the InputManager and InputSystems are loading up and defining everything correctly. Oddly enough it could detect when I reconnected my old XBOX 360 pad.

I've ordered an XBOX One controller and PS4 controller for my PC testing purposes just in case, but remapping some stuff to Keyboard keys didn't seem to affect anything, the Input Debugger always reports 0 devices no matter what I do. I haven't tested out of editor yet.

2018.2b1 - input system version "0.0.1", .NET 4.X compilation mode.

This is on Win10 x64, so I'll see if it's working on my mac when I get home from work. I'll also check if the version change does anything.

Other issues I noticed that you may be aware of:

A lot of compiler errors when I switch to .NET Standard 2.0 compile option, like over 40.

InputActionAsset code generation breaks when I try specify a directory (everything else seems to work). It breaks so bad it screws up the editor for the InputActionAsset until I either resave the json externally and switch back to Unity, or quit / reload the Unity editor entirely.

 

Ah doh, my bad, I forgot to add one step to your instructions:

In the player settings of your project, go to "Active Input Handling*" in the "Configuration" section and set it to either "Both" or "Input System (Preview)" (note that the latter will disable the legacy system and will render many APIs in UnityEngine.Input non-functional). Note that you will have to restart the editor for this setting to take effect.

Without this, the native backends will remain disabled and won't do anything. This is why you're not getting any data and not seeing any devices.

It's on the TODO list to add an automatic editor hook in the C# system that detects whether you have the package enabled but the native backends disabled and asks whether you want to enable the system.

 

Thanks! Ticket filed. Will look into it.

 

Thanks, this is only annoying to me because I like to have ScriptableObjects live in a "Data" directory, and scripts live somewhere beneath a "Code" directory.

The following structure, for the curious:

Project/Module Folder
* Code (breaks down into sub-assembly defs based on feature isolation)
* Sources (source models and animations, externally created textures, externally defined data)
* Data (ScriptableObjects, configs, data generated in editor)
* Prefabs
* Scenes
* root assemblydef / package information

Another thing with the code generation, it's not clear it defaults to the project root (I assumed it would default at the Assets directory) IFF you specify a directory path. It's also not clear leaving it blank generates in the same folder. Maybe a tool-tip could help? I know documentation isn't the top priority vs getting it stable, so don't jump on that on my account.

 

I think your assumption is spot on. It should really be relative to Assets/. Made a note.

 

I guess I don't know how to do this, because with 2018.2.0b1 I get this when I press Play on the Demo scene:



(I did enable the Input System Preview in the Player settings.)

EDIT: Also, I looked briefly in the SimpleController V4 file and got really worried by this...

Code (CSharp):

1. controls.gameplay.move.performed += ctx => m_Move = ctx.GetValue<Vector2>();
2. controls.gameplay.look.performed += ctx => m_Look = ctx.GetValue<Vector2>();
3.  
4. etc. etc. brackets, brackets, the horror... need some syntactic sugar...

That does not look simple for a beginner at all, so I hope whatever that is, it's just a placeholder/optional.

This, which was part of an older video, looked very simple and nice:



I hope you're lowering the treshold of learning for beginners, not not raising it. For people who want to do complicated stuff, there's always Unreal Engine.

 

Try altering the manifest version to "0.0.1-preview", I synced before the latest changes. I also copied the package into my own project and didn't run the demos.

The old input-api-ish polling stuff (from the example you liked) is still in. I think its one of the earlier versions of SimpleController.

The problem with current unity input is the floor is low for beginners, and the ceiling is the exact same height as the floor. So if you're making a fighting or action game you have to resort to a 3rd party tool or have crazy input bindings, per platform, and user-driven bindings are functionally impossible. The old framework is also inconsistent, and for a long time was strewn about platform specific APIs.

The lines you're concerned about are for advanced users who need event driven input.

Sorry if I come off as defensive, us advanced users have been complaining bitterly for years. A lower floor and a higher ceiling is necessary to satisfy both.

 

@recursive is right that it's just a different version of SimpleController. Take a look at the SimpleController_v1.cs script for the version you were looking for. ////EDIT: thinking about it, these should all been named differently rather than calling them all SimpleController.

However, at the same time, I fully agree the callback-based InputAction API isn't the simplest one. Callbacks have their advantages but they also come with a certain complexity (when is it invoked? when is that in relation to my own code? how do I make sure it gets cleaned up properly? etc). We're looking into having alternate APIs or replacing the callback-based API completely.

Keeping the same accessibility is definitely a concern of ours. IMO for some APIs we're already there, but for others we're definitely not (this page here shows one part of that picture).

Hah, well put

 

@Rene-Damm - I'm up for anything that can get us the flexibility of callbacks without the hassle of their GC overhead.

 

Thank you for both of your tips. I did not know where do put that dependency line, as I've never even opened (nor knew where to look for) the manifest.json file, and also, doubly confusing is that I downloaded that file from the github repository, so why wasn't that line already included?

So, now that I try the input debugger, I see the Devices number increase by one when I turn on my controller, but I don't know where to see that any input gets generated. But perhaps there's something more wrong, because my console gets spammed with these lines:

Code (CSharp):

1. Cannot find device for input event: id=6940 type=STAT device=12 size=88 time=251.066847927588
2. UnityEngine.Experimental.Input.LowLevel.<>c__AnonStorey0:<>m__0(NativeInputUpdateType, Int32, IntPtr)
3. UnityEngineInternal.Input.NativeInputSystem:NotifyUpdate(NativeInputUpdateType, Int32, IntPtr) (at C:/buildslave/unity/build/Modules/Input/Private/Input.cs:90)

 

In the project in the repo, I don't think it's as needed, since it's the "source" for the package.

For the new package manager framework, a lot of stuff is still in a state of flux, and the only solution for a lot of the ECS / Input System / etc new packages is to edit your package manifest file (manifest.json) manually, since things like the Input System have the package definition files but aren't yet on Unity's main staging server. I'm pretty certain if you could just point to a github repo or arbitrary url (a feature they said they eventually want to add) it would be a lot easier.

I think the big issue for a lot of the growing pains with this version of Unity is it's all in the middle of several major system refactors/replacements, which explains the issues with:

* Hub team not really having a solution for specific tagged builds, which would've eliminated the issues with the Input System build confusion.
* ECS build being a specific beta version number, same as with previous.
* ECS framework and related packages not originally being exposed to the package manager UI
* The package manager UI itself undergoing several revisions in a short span, as many people couldn't find the thing due to Library folder and configuration issues.

I think everything is a good direction, but it's a lot happening at once.

 

@Rene-Damm -

Some more issues:
* DoubleTap doesn't implement the modifier interface, despite showing up in the list.
* I cannot yet edit modifier data in the editor like I can in json (for instance, no way to set duration on HoldModifier).
* I was trying to use 2 chained taps in lieu of DoubleTap, but Tap breaks on a gamepad stick (not sure if I'm not using it correctly or related to inability to set data on a modifier via the editor), I get this exception:

InvalidOperationException: Cannot go from 'Started' to 'Started'; must be 'Waiting' (action: Normal Gameplay/Run, modifier: UnityEngine.Experimental.Input.Modifiers.TapModifier)
UnityEngine.Experimental.Input.InputAction.ThrowIfPhaseTransitionIsInvalid (UnityEngine.Experimental.Input.InputAction+Phase currentPhase, UnityEngine.Experimental.Input.InputAction+Phase newPhase, System.Int32 bindingIndex, System.Int32 modifierIndex)...etc

* Having a Tap modifier on more than one gamepad face button (any two separate actions mapped to different face buttons will work, problem could be a lot deeper and maybe related to the above?) cause invalid range exceptions with the ReadOnlyArray<> for the modifier list. I can replicate with an input set that just has ANY two distinct actions mapped to ANY single face button, both with 1 modifer. The first button that happens to get mapped will work (it may be using the other button's modifiers index however) and the other will throw the following:

IndexOutOfRangeException: Index was outside the bounds of the array.
UnityEngine.Experimental.Input.Utilities.ReadWriteArray`1[TValue].get_Item (System.Int32 index) (at Packages/com.unity.inputsystem/InputSystem/Utilities/ReadWriteArray.cs:65)
UnityEngine.Experimental.Input.InputAction.NotifyControlValueChanged (UnityEngine.Experimental.Input.InputControl control, System.Int32 bindingIndex, System.Double time)...etc.

EDIT: There's definitely something screwy with the modifer application logic, even outside of an InputActionSet.

In my example below, I setup the following script:

Code (CSharp):

1. public sealed class InputBinder : MonoBehaviour
2.     {
3.         //[SerializeField] TiTestInputsWrapper InputsWrapper;
4.  
5.         [SerializeField] InputAction _walk;
6.         [SerializeField] InputAction _run;
7.         [SerializeField] InputAction _jump;
8.         [SerializeField] InputAction _regularAttack;
9.  
10.         private void OnEnable()
11.         {
12.             _walk.performed += LogWalk;
13.             _run.performed += LogRun;
14.  
15.             _jump.performed += LogJump;
16.             _regularAttack.performed += LogRegularAttack;
17.  
18.             _walk.Enable();
19.             _run.Enable();
20.             _jump.Enable();
21.             _regularAttack.Enable();
22.         }
23.  
24.         private void OnDisable()
25.         {
26.             _walk.Disable();
27.             _run.Disable();
28.             _jump.Disable();
29.             _regularAttack.Disable();
30.  
31.             _walk.performed -= LogWalk;
32.             _run.performed -= LogRun;
33.  
34.             _jump.performed -= LogJump;
35.             _regularAttack.performed -= LogRegularAttack;
36.          
37.         }
38.  
39.         void LogWalk(InputAction.CallbackContext ctx)
40.         {
41.             Debug.Log($"Walk: {ctx.GetValue<Vector2>()}", this);
42.         }
43.  
44.         void LogRun(InputAction.CallbackContext ctx)
45.         {
46.             Debug.Log($"Run: {ctx.GetValue<Vector2>()}", this);
47.         }
48.  
49.         void LogJump(InputAction.CallbackContext ctx)
50.         {
51.             Debug.Log($"Jump: {ctx.duration}", this);
52.         }
53.  
54.         void LogRegularAttack(InputAction.CallbackContext ctx)
55.         {
56.             Debug.Log($"Attack: {ctx.duration}", this);
57.         }
58.     }

I then setup the following for my actions:

Walk has
* Gamepad leftstick
* Gamepad dpad

Run is is ignored (no setup).

Jump has
* Gamepad buttonSouth PressModifier

RegularAttack has
* Gampad buttonWest TapModifier

.. movement seems to work normally, BUT:
The jump action press causes Walk's onperformed to be called, with a value of (0.0, 0.0).
The RegularAttack action triggers both, it's own tap occurs when the tap condition is met, but it also causes Walk's onperformed to get called the frame (like an unmodified action fire), again with a value of (0.0, 0.0).

This doesn't happen when both of the buttons were set to TapModifier, nor does it occur when I have no modifiers on Jump.

 

Even more Issues:

The button tapping issues don't occur with this setup (so far), but the left stick tapping issues do still occur.

If I were to create a double-tap and hold to run ability (similar to the mainline Kirby games, I'm building a Kirby/Smash-like game here), is that still possible with DoubleTap modifier not implemented yet? Or maybe I'm misunderstanding how the binding chains work.

EDIT:
I also found out if you unplug a 360 pad, then plug in a never-before-registered XINPUT device (in this case a new XBOX ONE stock controller), it will think it reconnected and throw an exception loop that continues across the domain reload. I had to kill the editor to stop it.
I couldn't repro it afterwards, but I have a PS4 controller + USB adapter coming tomorrow, so I'll see if I can repeat it.

 

In the input debugger, double-click on the device to open a window dedicated to the device. When you wiggle a stick on your controller or press a button, do you see events being recorded in the bottom section of the window?

What kind of controller is it? And Mac or Windows?

Yeah, there is indeed. I think Unity is in one of its most fundamental transitions to date.

Yeah, actions overall are pretty incomplete (and ATM also somewhat buggy due to some regressions). DoubleTap has a registration but no implementation. Will deactivate it for now.

Yup, we're in the process of giving the UI a major overhaul. As part of that, stuff like this will become functional in the UI.

TapModifier as is wouldn't make sense on a stick but there's no mechanism in place ATM that tells you what can be used with what. Either way, it shouldn't just throw exceptions. Will take a look.

Looking into it. https://github.com/Unity-Technologies/InputSystem/issues/79.

Thanks. Will take a look.

Chaining is only half implemented ATM and not yet working. Same for composite bindings.

Can you elaborate a bit? Do you want to double-tap and hold on the second tap? And that sequence should trigger a run whereas just pressing the button would trigger a normal walk?

With chaining and double-tap having finished implementations, that should work. ATM it's not yet doable.

What did the exception say? If you can repro, could you file a ticket on GitHub with the exception details?

 

I'll try to repro that exception, all of the above was tested on my work PC using the repo commit from Thursday / Friday.

I've tested the latest repo commit on my mac while on break at work, and I got this issue:

System.IndexOutOfRangeException: Index was outside the bounds of the array.
at (wrapper stelemref) System.Object.virt_stelemref_class_small_idepth(intptr,object)
at UnityEngine.Experimental.Input.Utilities.ArrayHelpers.AppendWithCapacity[TValue] (TValue[]& array, System.Int32& count, TValue value, System.Int32 capacityIncrement) [0x00047] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/Utilities/ArrayHelpers.cs:113
at UnityEngine.Experimental.Input.Gamepad.OnAdded () [0x00001] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/Devices/Gamepad.cs:231
at UnityEngine.Experimental.Input.InputDevice.NotifyAdded () [0x00001] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/Devices/InputDevice.cs:346
at UnityEngine.Experimental.Input.InputManager.AddDevice (UnityEngine.Experimental.Input.InputDevice device) [0x000ed] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputManager.cs:715
at UnityEngine.Experimental.Input.InputManager.RecreateDevicesUsingLayout (UnityEngine.Experimental.Input.Utilities.InternedString layout, System.Boolean isKnownToBeDeviceLayout) [0x000cc] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputManager.cs:330
at UnityEngine.Experimental.Input.InputManager.PerformLayoutPostRegistration (UnityEngine.Experimental.Input.Utilities.InternedString name, System.String baseLayout, System.Nullable`1[T] deviceMatcher, System.Boolean isReplacement, System.Boolean isKnownToBeDeviceLayout) [0x00034] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputManager.cs:247
at UnityEngine.Experimental.Input.InputManager.RegisterControlLayout (System.String json, System.String name, System.String namespace, System.Nullable`1[T] matcher) [0x000bf] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputManager.cs:197
at UnityEngine.Experimental.Input.InputSystem.RegisterControlLayout (System.String json, System.String name, System.Nullable`1[T] matches) [0x00001] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs:122
at UnityEngine.Experimental.Input.Plugins.XInput.XInputSupport.Initialize () [0x0003d] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/Plugins/XInput/XInputSupport.cs:89
at UnityEngine.Experimental.Input.InputSystem.PerformDefaultPluginInitialization () [0x00001] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs:1025
at UnityEngine.Experimental.Input.InputSystem.InitializeInEditor () [0x00048] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs:957
at UnityEngine.Experimental.Input.InputSystem..cctor () [0x00001] in /Users/thomaskey/dev/Ti/TiGame/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs:920
UnityEditor.EditorAssembliesrocessInitializeOnLoadAttributes()

This is with a 360 Pad, doesn't matter if it's plugged in before play or during. When I reverted to the previous package drop from Thursday / Friday, it works, but with the previously listed issues. I'll retest on my PC when I get home.

I'll start putting these issues into the repo if you'd prefer them there, and reserve the forum for questions on usage / direction if you'd prefer.

I'm getting a dualshock so I'll start testing bluetooth on my mac, my PC currently doesn't have a bluetooth adapter.

 

As for the chaining and binding stuff, I'm building a action/fighting game type input -> token -> combo analyzer, so I can make due until all the modifiers/chains/composites are working.

 

Was a bug in the domain reload logic. Should be fixed here.

 

One other thing I noticed alongside that issue I forgot to mention, the test framework in the package would have unsafe code errors, despite the assembly definition having the correct flag. Is this related to the other change you made regarding tests or do I need to enable unsafe code on my assemblies that reference the input package? I'm not running the test ATM so I just scrapped the folder and was able to get it to compile again.

I can send a more detailed error report after work if it happens again.

 

I cannot repro it even after uninstalling the drivers and rolling back to Friday's build. Might have just been a weird USB fluke.

 

It's a Xbox Elite gamepad from Microsoft using the official Wireless dongle on Windows 10. It shows up as an XInputController.

Also, without restarting Unity since I posted last (although putting the computer in sleep mode), I pressed Play again, and this time no error messages. But when I double clicked on the XInputController to get that window you mentioned (super unintuitive, btw), the values I see area really flaky. Pressing a shoulder button just flickers the 0 to 1 sometimes, and the analogue input values I don't get at all. Also the console in that window begins listing values att odd times.

For the debugger tree, it would be nice, after the name of the device, to get the name of the currently pressed input and its value next to it (and perhaps a proper button to pop open that window for the entire device)?

I'm beginning to think your earlier suggestion to go with this new input system on a new project at this point was to lure in new beta testers? Anyway, I'll continue to test it as progress is slow on other parts of the game.

 

Thanks eobet, I'll give it a try and see if I can repro.

Heh wait wait, I suggested to *not* use it for a new project at this point Thing is I wouldn't call where we are right now with the input stuff a beta yet (2018.2 is in beta, but the input system package isn't). We're still lacking a number of features and there's several things that are incomplete. So stabilization right now is taking a backseat to completing the system.

So to be clear, this stuff isn't ready for prime time yet. It's in development and will subject anyone using it at this point to instability and a certain level of grief. The upside for anyone jumping in at this point, other than getting a feel for what's coming, is that you can have an impact on development -- both on what gets fixed first and on how stuff works. And if what's there ATM is already useful to you, then even better and your findings and input is greatly appreciated of course

As already happened a few times in this project, I think my clarity in communication with respect to this has been lacking. Sorry about that.

 

Don't feel too bad. At least now it looks like there's a goal on the horizon, and we can actively contribute to helping getting it finished.

I've waited for this since 2014, I can wait a little bit longer.

 

I re-read your original reply to me again and oops, you're correct! I'm not a native English speaker, so I misunderstood the target of that particular sentence.

Either way, I don't mind continuing testing this.

 

Yo

for all those playing with the new input system and trying to keep pace with the repo updates, here's a handy script. You'll have to edit myPackageDir to replace UNITYGAME with your project directory folder name at the bare minimum. Tested and works on Windows with git bash (mingw64). I'll double check it on my mac later.

Code (bash):

1. #!/bin/bash
2. # Updates your game with the latest input system packages
3. # (until the package goes up on the staging)
4.  
5. # ASSUMPTIONS:
6. # This script assumes it sits in a directory ABOVE your Unity Game project folder
7. #    For Example, I structure my projects like this: REPO/UNITYGAME to simplify
8. #    having to build any dependency plugins and/or to separate source assets/project docs.
9. # In the same parent directory as REPO, you have cloned the InputSystem project from github
10. #    and haven't modified it's structure in any way
11. # MYREPOSDIR/REPO <- Where this script lives
12. # MYREPOSDIR/REPO/UNITYGAME <- Where all of the unity folders and files live
13. # MYREPOSDIR/InputSystem <- Where the InputSystem Repo was cloned to
14.  
15. myPackageDir="UNITYGAME/Packages"
16. inputPackageDir="../InputSystem/Packages"
17. ipsPackageName="com.unity.inputsystem"
18.  
19. # try to remove previous package
20. removeTarget="$myPackageDir/$ipsPackageName"
21. if [ -d $removeTarget ]; then
22.     echo "Deleting old Input System files! $removeTarget"
23.     rm $removeTarget -rf
24. fi
25.  
26. # copy in fresh package
27. copyTarget="$inputPackageDir/$ipsPackageName"
28. if [ -d $copyTarget ]; then
29.     echo "Importing updated Input System Files! $copyTarget"
30.     cp $copyTarget $myPackageDir -r
31. fi
32.  
33. # Something causes the tests to fail compilation, as if the "unsafe" flag wasn't set
34. # (at least on 2018.2b1)
35. # despite the test assembly definition clearly being set as "unsafe"
36. # This may be a general issue with the package system.
37. # This can be removed once that's no longer an issue
38. testTarget="$myPackageDir/$ipsPackageName/Tests"
39. if [ -d $testTarget ]; then
40.     echo "Deleting test files due to issues! $testTarget"
41.     rm $testTarget -rf
42. fi
43.  
44. # remove the meta to avoid an editoro warning
45. testTargetMeta="$testTarget.meta"
46. if [ -f $testTargetMeta ]; then
47.     echo "Deleting test meta! $testTargetMeta"
48.     rm $testTargetMeta
49. fi
50.  
51. echo "Complete!"

 

@Rene-Damm - Quick question, let me know if it's "not there yet", is there a way to get the index of the gamepad associated with a player yet (or is that not a stable identifier)? I know you said at one point your goal was to show how to setup a multiplayer demo.

Edit: Specifically, I'm talking about getting it from an action context.

 

In general (let me get that out of the way before focusing on actions), only on platforms or APIs that have some form of player identification. XInputControllers have userIndexes. PS4 and Xbox controllers have user IDs. Stuff like that.

At the device-level, that's all there is. There is no player-to-device mapping built directly into the input system.

Things here still need fleshing and sorting out. With the current APIs, it should be doable but at the very least, looks and feels pedestrian. Sort of like this:

Code (CSharp):

1.  
2. var gamepad1 = Gamepad.all[0];
3. var gamepad2 = Gamepad.all[1];
4.  
5. var player1Actions = myGameControls; // Let's assume this has general gamepad bindings.
6. var player2Actions = myGameControls.Clone();
7.  
8. player1Actions.ApplyOverridesUsingMatchingControls(gamepad1); // Any gamepad binding becomes specific to gamepad1.
9. player2Actions.ApplyOverridesUsingMatchingControls(gamepad2); // Same for gamepad2.
10.  
11. var player1 = new MyPlayerObject { playerIndex = 1, device = gamepad1, actions = player1Actions };
12. var player2 = new MyPlayerObject { playerIndex = 2, device = gamepad2, actions = player2Actions };
13.  
14. player1Actions.fire.performed += player1.Fire;
15. player2Actions.fire.performed += player2.Fire;
16.  
17. player1Actions.Enable();
18. player2Actions.Enable();
19.  

The core of the action stuff puts player and device management on you. IMO once the core stuff has stabilized, it's worth taking a look at opportunities to build some stuff on top that wraps things up more nicely.

 

Code (CSharp):

1. Input.GetKeyUp(KeyCode.LeftShift)

This line doesn't work with the new input system? I'm on 2018.2.0b2 now and haven't changed anything since last time I posted here. The Input Debug window spits out some numbers when I open the Keyboard entry and press left shift, but my Debug.Log for that line never gets triggered.

There are no error messages or warnings in the console.

 

No, If you set the mode to the new input system only, the old APIs won't do anything (there is a mixed mode). Here's how to get the left shift up state with the new Keyboard class:

Code (CSharp):

1. var keyboard = Keyboard.current;
2.  
3. // Option A:
4. var leftShift = keyboard[Key.LeftShift]; // get the KeyControl object
5. var isLeftShiftUp = leftShift.wasJustReleased;
6.  
7. // Option B:
8. var isLeftShiftUp = keyboard.leftShiftKey.wasJustReleased; // just access the keycontrol object

 

Thank you! Excuse my ignorance, but is that javascript? I thought Unity dropped support for that. What type of object is Keyboard? I can't get VistualStudio to highlight it for me.

EDIT: I see now that Rene-Damm also posted code using "var" only... is that some new .NET 4.x thing?

EDIT 2: What namespace does the latest develop branch download of the input system use? It's not ISX anymore it seems...

 

Nope, it's just C#.

1. It's been in C# for a while (since 4 or 5 I think?). It's less like the javascript var and more like the C++ auto, however. No dynamic typing, just the compiler understanding the type of something that's already there. I don't think it's a .NET thing at all, just a C# feature.

2. UnityEngine.Experimental.Input is the current namespace for the main stuff. There are a few other namespaces for specific areas of the code, but the highest-level APIs are in there. You can find all the source code in the com.unity.inputsystem package directory you currently have to copy over manually.

 

Please excuse my ignorance.

Are you putting this line in Update()?

 

Yes, this is the part of the API that maps closest to the old one, Update() (or a preupdate function) would be the most logical place to put it.

 

Thank you for your help!

I just tried to enable "both" as it is called in the Player settings, and then I got an error. So I switched back to new only, and the error unfortunately now persists. I'm on 2018.2.0b3 now...

Code (CSharp):

1. Exception: Cannot find public field 9921875 in AxisControl (referenced by parameter)
2. UnityEngine.Experimental.Input.InputDeviceBuilder.SetParameters (System.Object onObject, UnityEngine.Experimental.Input.Utilities.ReadOnlyArray`1[TValue] parameters) (at Packages/com.unity.inputsystem/InputSystem/Controls/InputDeviceBuilder.cs:799)
3. UnityEngine.Experimental.Input.InputDeviceBuilder.AddChildControl (UnityEngine.Experimental.Input.InputControlLayout layout, UnityEngine.Experimental.Input.Utilities.InternedString variant, UnityEngine.Experimental.Input.InputControl parent, System.Nullable`1[T] existingChildren, System.Boolean& haveChildrenUsingStateFromOtherControls, UnityEngine.Experimental.Input.InputControlLayout+ControlItem& controlItem, System.Int32& childIndex, System.String nameOverride) (at Packages/com.unity.inputsystem/InputSystem/Controls/InputDeviceBuilder.cs:613)
4. UnityEngine.Experimental.Input.InputDeviceBuilder.AddChildControls (UnityEngine.Experimental.Input.InputControlLayout layout, UnityEngine.Experimental.Input.Utilities.InternedString variant, UnityEngine.Experimental.Input.InputControl parent, System.Nullable`1[T] existingChildren, System.Boolean& haveChildrenUsingStateFromOtherControls) (at Packages/com.unity.inputsystem/InputSystem/Controls/InputDeviceBuilder.cs:453)
5. UnityEngine.Experimental.Input.InputDeviceBuilder.InstantiateLayout (UnityEngine.Experimental.Input.InputControlLayout layout, UnityEngine.Experimental.Input.Utilities.InternedString variant, UnityEngine.Experimental.Input.Utilities.InternedString name, UnityEngine.Experimental.Input.InputControl parent, UnityEngine.Experimental.Input.InputControl existingControl) (at Packages/com.unity.inputsystem/InputSystem/Controls/InputDeviceBuilder.cs:333)
6. UnityEngine.Experimental.Input.InputDeviceBuilder.InstantiateLayout (UnityEngine.Experimental.Input.Utilities.InternedString layout, UnityEngine.Experimental.Input.Utilities.InternedString variant, UnityEngine.Experimental.Input.Utilities.InternedString name, UnityEngine.Experimental.Input.InputControl parent, UnityEngine.Experimental.Input.InputControl existingControl) (at Packages/com.unity.inputsystem/InputSystem/Controls/InputDeviceBuilder.cs:216)
7. UnityEngine.Experimental.Input.InputDeviceBuilder.SetupWithDescription (UnityEngine.Experimental.Input.Utilities.InternedString layout, UnityEngine.Experimental.Input.InputDeviceDescription deviceDescription, UnityEngine.Experimental.Input.Utilities.InternedString variant) (at Packages/com.unity.inputsystem/InputSystem/Controls/InputDeviceBuilder.cs:66)
8. UnityEngine.Experimental.Input.InputManager.AddDevice (System.String layout, System.Int32 deviceId, UnityEngine.Experimental.Input.InputDeviceDescription description, System.Boolean isNative) (at Packages/com.unity.inputsystem/InputSystem/InputManager.cs:611)
9. UnityEngine.Experimental.Input.InputManager.AddDevice (UnityEngine.Experimental.Input.InputDeviceDescription description, System.Boolean throwIfNoLayoutFound, System.Int32 deviceId, System.Boolean isNative) (at Packages/com.unity.inputsystem/InputSystem/InputManager.cs:732)
10. UnityEngine.Experimental.Input.InputManager.ReportAvailableDevice (UnityEngine.Experimental.Input.InputDeviceDescription description, System.Int32 deviceId, System.Boolean isNative) (at Packages/com.unity.inputsystem/InputSystem/InputManager.cs:890)
11. UnityEngine.Experimental.Input.InputManager.OnDeviceDiscovered (System.Int32 deviceId, System.String deviceDescriptor) (at Packages/com.unity.inputsystem/InputSystem/InputManager.cs:1461)
12. UnityEngineInternal.Input.NativeInputSystem.NotifyDeviceDiscovered (System.Int32 deviceId, System.String deviceDescriptor) (at C:/buildslave/unity/build/Modules/Input/Private/Input.cs:98)
13.  

EDIT: And I downloaded the development branch yesterday.

 

Thank you!

btw, it's been very informative, reading along with you and your quests through this new system. Thank you for trying and writing, trying and writing, trying and writing. And to @Rene-Damm, thank you for your truthful, immediate responses, insight, forthrightness and input. Oops. Pun!

 

That looks like a bug. My guess is it's the HID code picking up some weird device and making a mess of it. I'll take a look at making the exception trace there better. It should catch the exception and re-throw with added details about what the device is and what layout it tried to use with it. The current error trace really doesn't give much to work with.

Does the problem go away if you comment out

Code (CSharp):

1.             #if UNITY_EDITOR || UNITY_STANDALONE || UNITY_UWP
2.             HIDSupport.Initialize();
3.             #endif
4.  

in InputSystem.cs?

Also, does the system become completely unusable because of this or do other devices continue to function as expected?

 

Yes, the error goes away when I comment out that line, and my Xbox Elite gamepad still produces really screwy values in the Input Debug window afterwards.

Ok, so if you got your hands on a Xbox Elite gamepad the last time, here's another piece of hardware you should get:

https://www.3dconnexion.com/spacemouse_compact/en/

I have that installed, but not connected. Yet I think they still run keyboard emulation in the background, etc. Many complain about their absolute crap drivers on their forums, but here's the kicker: They're the Wacom of the CAD world. Just like Wacom used to be with graphics tablets, they still enjoy an absolute monopoly when it comes to 3D navigation in 3D modeling software, so you can't make them do anything, only work around them.

Not sure if that is the issue, but boy have I had issues with them before.

(Also, still trying to figure out what class of gameobject Keyboard.current returns.... even though I've included "using UnityEngine.Experimental.Input;" Visual Studio Community 2015 refuses to give me any code completion for it.)

EDIT: While I’m at it, we also previously briefly touched on the various new ways of accessing input, so why isn’t the new input system backwards compatible? That could be just another way of accessing input, right?

 

Is it just in the input debug window or does the gamepad also behave unexpectedly with the demo scene?

We have one in the office and will probably take a look at hooking it up once we're further down the road. IIRC from last time we looked at it, it's pretty simple to pick up its HID data and mainly requires setting up a control layout for it.

You may have to update Visual Studio Tools for Unity. VSTU needed a bit to catch up to the changes brought about by the introduction of .asmdef files and older versions of VSTU still assume a fixed assembly layout. This is probably why it isn't showing you any completion.

There's a number of things in the old system we want to get rid of. Stuff that is either badly designed (like GetJoystickNames) or not quite adequate anymore.

It would be possible to implement an "emulation" of the old system with a compatible API but using the new system under the hood, but it would significantly and noticeably change behavior. So everything would compile fine but then not run the same way.

We will probably take a look at potentially keeping backwards-compatibility in this emulation sometime further down the road when we are actually starting to think about how to get rid of the old system but ATM the new system has a good way to go before that becomes something to spend cycles on. For now, our chief aim is to give anyone wanting a better input API in Unity an option that is free of the constraints of the old system.

 

It was apparently just the debug window outside of the demo scene. In other words, it seems you need to setup the controls in script in the scene first to get proper debug output.

Well, using it in the editor would be fantastic, but just having Unity being able to completely ignore it and not interrupt other normal gameplay would be equally good (some existing Unity games picks up on it when it is connected).

I'll look into that, thanks!

Right, and having both input systems active at the same time, as recursive mentioned, is a perfectly fine solution, and that's what I'm using now since you provided me with the temp fix to get rid of the error message I got before.

 

Ok, I'm going to reveal just how much of a newbie I am: Why do I have to invert x in order to get the real world direction for a raycast?

Code (CSharp):

1.     void Update () {
2.  
3.         // hotswap support when placed here I guess
4.         var gamepad = Gamepad.current;
5.         if (gamepad == null)
6.             return;
7.        
8.         var leftStick = gamepad.leftStick.ReadValue();
9.         var rightStick = gamepad.rightStick.ReadValue();
10.  
11.         if (leftStick.magnitude > deadZone)
12.             moveHandTarget(leftStick);
13.        
14.     }
15.  
16.     void moveHandTarget(Vector2 inputVector)
17.     {
18.         RaycastHit2D hit = Physics2D.Raycast(handTarget.transform.position, inputVector, 1.0f);
19.  
20.         // no idea why I need to invert x here to get the rays to draw in the correct direction
21.         Vector3 rayVector = new Vector3(-inputVector.x, inputVector.y);
22.        
23.         if (hit.collider != null)
24.         {
25.             Debug.DrawRay(handTarget.transform.position, rayVector, Color.green);
26.         }
27.         else
28.         {
29.             Debug.DrawRay(handTarget.transform.position, rayVector, Color.red);
30.             Debug.LogError("Couldn't find edge of handArea.");
31.         }
32.     }

 

@eobet
Well for starters, they're in completely different spaces.

The 2D system and the 3D system don't necessarily overlap, it depends on the direction the camera is facing. If you setup your camera so that it's facing Z+ (forward) with it's X+ (right) matching world X+ (right), and it's Y+ (up) matching world Y+ (up), that may be more correct.

If you setup your project earlier and didn't use one of the new templates, and didn't mess with the default camera transform values, the camera is configured for a 3D game and doesn't map directly to the 2D space used by Physics2D or most of the 2D stuff without moving and rotating it.

See if that helps.

Debug.DrawRay works entirely in World space, so if you pass it rays they'll always need to be converted if they're relative to some other space (such as 2D space or a character's transform space). You can convert to from world space and back to an object's transform space via functions like TransformVector, TransformPoint, TransformDirection, and their reverse counterparts: InverseTransformVector, InverseTransformPoint, InverseTransformDirection.

You can also convert a direction between arbitrary rotations with Quaternions. If you have a valid Quaternion, you can multiply it by a vector to rotate that vector.

 

Crap, I was hoping nobody had time to reply so I could sneakily delete that post, because the answer was staring me in the face the entire time:



Makes me wonder if I accidentally rotated the camera 180 degrees in both Blender and Unity, though, because to me, it's not logical that +X is to the left...

Thanks for the tip about world space, though, because I'm going to run into that when I moved these objects from my test scene to the real scene.

Anyway, sorry for what turned out to be an off topic digression.

 

You may have to rotate some things around from blender. That may have been improved or have some kind of import setting, not sure, but I think it's rotation basis is not the same as Unity's.

 

Ok, so maybe that above code wasn't completely useless to paste anyway, because remember the garbage numbers I said I initially got from the Xbox Elite Gamepad via the Input Debugger?

Well, turns out the above code works fine and dandy... until you start to click around in the Unity Editor while its running. Then suddenly, the garbage numbers are back, and it shows in the DrawRay results as well.

In other words, the gamepad works great, until I click on any other gameobject in the hierarchy, or for example change a value in the inspector. Then it basically freezes.

 

Ah think I may see why you're getting different values from what you expect. It's probably the switch between edit mode and play mode. It's a bit of a confusing thing that I hope we can improve on.

Do things work as you expect if you enable "Lock Input to Game" in the input debugger?

To explain, the old input system worked *only* in the player. The way it was implemented in the editor was that if the game view has focus, the game receives input and if the game view isn't focused, it's not. Or well, it actually ended up getting some input (IIRC gamepad was among them) but not others (mouse, touch, keyboard, maybe others).

The new system works both in edit and in play mode. Meaning, you can write game code using it but you can also have editor code in EditorWindows that uses it (e.g. to pick up pen input). In either mode, you can use whatever input devices are available.

So the system has to decide which world to serve. The way it does that by default is the same as in the old system. I.e. if the game view is focused, the game gets input. If any other EditorWindow is focused, the editor gets input.

However, this can be mighty annoying when testing your game. The "Lock Input to Game" switch in the debugger (which unfortunately is partially broken ATM due to a recent change) tells the system to ignore edit mode altogether and route any input to the player. Overall, I think we need a better or at least more discoverable solution than a button in the debugger.

 

That made everything work smoothly, finally, thank you!

But dear god, that must surely be the default setting? Because when I say garbage numbers, I mean, truly, truly, unusable input, like the gamepad mostly freezing in one direction, and then doing just small jitters back and forth regardless of what you do, until you stop the game and start it again.

But when the above bug is fixed (because surely that behavior isn't normal), In theory, what you say sounds great, because that means that someone could actually script support for the 3D Connexion SpaceNavigator in the scene view without Unity having to officially support it?

(Btw, I checked now, their bloody Keyboard & Mouse emulation remains active regardless of if you have the thing connected or not, but the Input Debugger didn't react when I plugged it in, which actually is great for now.)

 

Clicking in the game view to give it focus should do the trick.

Yup, that's the goal. //EDIT: Though just to add that, other than what the input system itself does, there's some hooks missing on the editor side to allow the scene view to be extended that way.