Input System Update

IndexOutOfRangeException happening in the input system code or in the callback. If the former, could you file a ticket with the Unity bug reporter? The system itself should definitely not throw that.

 

Back from 2018.

Is this still an option, and if it is, how far has the development gone?
Thanks

 

After a couple iterations, it's now called InputActionTrace but the mentioned functionality is there.

Code (CSharp):

1. // Setup.
2. var trace = new InputActionTrace();
3. trace.SubscribeToAll();
4.  
5. // In update.
6. foreach (var actionEvent in trace)
7.     /* ... */;
8. trace.Clear();
9.  

Once recorded and when the system isn't mutated, the trace *should* be thread-safe but big caveat is that this isn't actively being tested so can't claim this is *actually* the case.

 

What is the actual development state of the new Input System? Are there any developers working on it? What are they working on?

What about the event system firing uselessly? Anything on that?

 

One of the developers posted just before you. The system is currently in its last preview version before the official 1.0 release. Most non-edge-case scenarios should be accounted for. Fine tuning and DOTS compatibility are actively been worked on.

You can watch a recent webinar here.

 

Do you have a TrackedDeviceRaycaster on the Canvas GameObject? With the raycaster in place and input coming in from tracked devices on InputSystemUIInputModule, you should be seeing UI callbacks fire same as with the mouse.

 

I'm about to start playing with that very section. Was just reading that documentation, and this is minor, but I have a suggestion on extensibility for the future. I think regarding the Pointer Behavior, it would be cool to select which device types are treated as separate pointers, and which are unified. Again, not a big deal, it looks like that won't be difficult manually, but just a thought since we've gone to the point (ha ) of having presets.

 

Thanks for the reply - I do have the TrackedDeviceRaycaster on the canvas gameobject that is world space with just a simple ui button. I'm using new input UI module, the tracked devices are working as well as using the new input tracked posers on my xr rig. The tracking seems to be working fine. Is there anything I'm missing here?

I'm gonna mess around with it a bit more today...

 

Hi,

I really struggle about implementing the new Input System using Dots. What’s the actual recommended way of doing it ? Also can someone provide me examples of such implementation please ?

Thank you in advance

 

I have implemented very simple system that currently reads only axial input (arrow keys from keyboard). Here is an example:

Code (CSharp):

1. public class InputHandlerSystem : SystemBase
2. {
3.     private Input m_Input;
4.     private Input.RacerActions m_racerActions;
5.  
6.     protected override void OnCreate()
7.     {
8.         m_Input = new Input();
9.         m_Input.Enable();
10.  
11.         m_racerActions = m_Input.Racer;
12.     }
13.  
14.     protected override void OnUpdate()
15.     {
16.         InputSystem.Update();
17.         float steeringInput = m_racerActions.Move.ReadValue<float>();
18.         Entities.ForEach((ref AxialInput axialInput) =>
19.         {
20.             axialInput.Horizontal = steeringInput;
21.         }).Run();
22.     }
23. }

Input class is automatically generated class based on InputAction map. You can do it by selecting "Generate C# class" like so:


More on this here: https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/manual/QuickStartGuide.html
I chose C# events as Behaviour

 

Thank you very much, it works perfectly with Entities. But I’m trying to use Entities2D that don’t have the SystemBase class. Any advice about achieving it ?

 

Hm...I have no idea what is different about Entities2D, but can you try one of the legacy systems, like ComponentSystem?

 

Did you have any luck? I've been attempting to use the new Posed Trackers (New Input System) and it seems there is a persistent issue for me : the tracking only happens with the headset off. With it on, nothing..just frozen camera.

This might be a bug? For reference, the original legacy tracked posers work just fine. I can't think of what is wrong - it should just be plug and play...

 

Ah, can't really comment, sorry if I was misleading, but by that "section," I meant the URL you posted. The pointer behavior is relevant to creating multiple gamepad cursors per player, which is what I'm working on. I am not working with any tracked input, specifically. I don't have experience in what you're trying to do, but maybe see if the input is showing up in the input debugger when it's not in your game?

 

Hmmm... @Rene-Damm, is there something weird going on with the new Input System when using breakpoints in Visual Studio?

I have a breakpoint set in some code called when an input's "triggered" is true. When Visual Studio is attached, as soon as that breakpoint is hit triggered seems to be staying true until I disconnect from Unity. Is handling the breakpoint somehow messing with how the Input System determines whether an input is still triggered? Eg: maybe the key up event isn't being received until afterwards, or something?

Edit: Actually, the same thing happens with "Error Pause" in the built-in Console window. If pressing a key causes an error and the console pauses the game as a result, "triggered" will return true immediately when you un-pause your game. Or at least it is in this project.

 

Yeah, think that could be useful. Or at least more obvious and explicit. In my ideal picture, it'd go beyond just Pointer Behavior and extend to how pointers are defined. ATM this is rather implicit. There's several pointer-related actions and they can form a single pointer or multiple pointers but it's not very obvious. I think I'd prefer to have a way where you can add however many pointers you want and for each one define the inputs that should go into the pointer and also define how the pointer should behave. Well, let's see.

Definitely sounds like a bug. Could you file a ticket with the Unity bug reporter?

Hmm, that sounds very peculiar. Could you file a ticket with Unity bug reporter? Think we should have a go at reproducing this on our end and see what's up.

 

Hey everyone,

1.0 has been pushed to the production server and is on its way to being a verified package on trunk.

With finally having reached that milestone, this thread has probably served its purpose (and served it well, I think). So let's close this one.

Once 2020.1 is final, we intend to also move this forum section out of the Betas&Experimental corner of the forums.

Does this mean that all problems have been fixed?

No. We will keep addressing issues and improving stability and reliability. Just had to make a cut somewhere, get it out, keep moving.

Where do I report issues?

The best way to report issues is through the Unity bug reporter. This gives us the best spread of information and makes sure your reports are landing in the most well-established problem reporting funnel for Unity. GitHub issues will get turned off AnyDayNow.

For asking questions, this forum will generally remain the best way to reach us.

What are the future plans?

There's three things on our table:

1. Keep working through FogBugz tickets.
2. Start working down some of the accumulated TODOs. Likely going to start with making some incremental improvements to actions. Otherwise gestures (and generally improved touch support) and DOTS loom large.
3. Incrementally improve docs/samples/tutorials. Our thinking currently is to first focus on a series of *simple* tutorials that go through the most common use cases.

Are you moving on to Unity 2020.x?

No. Our baseline is Unity 2019. ATM we still support 2019.1. We intend to move this up to 2019.4 as soon as the LTS release is out. With the 1.x line of the input system, we are committed to supporting 2019 as our baseline (while, of course, also keeping us running in the latest release of Unity).