Input System Update

Yup, that's the plan.

Could you elaborate a bit on that? I'm not aware of that particular bug I think.

The version that's currently on GitHub has seen a number of fixes and improvements and should be functional. A few more fixes are in the pipe. Also, there are still some significant bugs around saving stemming from the fact that the new editor isn't setting up asset handling correctly yet.

A more rigorous pass at documentation is slated to happen soon. Before that I'd like to give the action stuff another pass, though, as there's still a number of serious issues and holes that have the potential of shifting things around quite a bit still.

 

So I got here after trying to solve what I thought would be a small design issue. Three hours later, I'm looking into wholesale replacing the underlying input system for my little project.

Anyways, I've been able to glean bits from the previous posts (given that the forum search doesn't like the term UI) but I'd like to ask specifically how the new system would handle a local multiplayer input system like the one in the Worms series. What I'm going for is a turn based game with a logically arbitrary (but logistically about 6-8 max) number of players. Each player can be assigned to their own (arbitrary) gamepad, use the keyboard/mouse, or share any of the other players' controllers.

For instance. Player 1 is on an XBox Controller, Player 2 is on KB/Mouse, Player 3 is on his PlayStation controller because he decided rich, single player experiences were more important than getting the same console as his friends, and Player 4 is cheap so he's using Player 1's controller on his turn. Player 5, meanwhile, has his own XBox Controller.

Managing these inputs in the current system was relatively trivial, however, the current GUI system has no decipherable tool for isolating these inputs. Thus any player can control any menu at any time.

Will GUI isolation be in the scope of this undertaking, or is that a separate issue entirely?

 

Good question. We've started work on figuring out user management in the input system but haven't started work yet on UI support (we're still missing one native feature there; will get looked at next).

With respect to user handling in the input system itself, I think all your cases will be covered. With respect to UI, we need to take a closer look as part of hooking it up to the new input system. I don't have clarity yet what our limits are. All I can promise at this point is, we'll take a look

 

Aight. I think I'll try making a custom input manager in the meantime. Thanks for the reply!

 

@Rene-Damm - what's the status/direction for the action event buffering (IE InputActionManager and friends)? I know you've mentioned needing to take another look at them.

I mostly ask because I'm actually starting to make progress on my ECS bridge and after I deal with device -> player id association that's the last thing I'm looking to tackle before writing game-specific event processing.

 

@recursive It's currently being worked on. My expectation is that InputActionManager will go away entirely or at least change considerably. The API is pretty horrible IMO. Not sure yet where exactly this will go.

 

@Rene-Damm Hey. Where can I read more about ApplyBindingOverride? I do not understand how to do rebind management

Code (CSharp):

1. public class MyInput : MonoBehaviour
2. {
3.     public InputAction movement;
4.     public InputAction action;
5.  
6.     public Vector2 inputVector;
7.  
8.     void Awake()
9.     {
10.         movement = new InputAction(binding: "<gamepad>/leftStick");
11.         movement.AppendCompositeBinding("Dpad")
12.             .With("Up", "<keyboard>/w")
13.             .With("Down", "<keyboard>/s")
14.             .With("Left", "<keyboard>/a")
15.             .With("Right", "<keyboard>/d");
16.  
17.         action = new InputAction(binding: "<gamepad>/buttonSouth", interactions: "press");
18.  
19.         movement.performed += Movement_performed;
20.         action.performed += Action_performed;
21.     }
22.  
23.     private void Action_performed(InputAction.CallbackContext context)
24.     {
25.         movement.Disable();
26.         movement.ApplyBindingOverride(newBinding: "<gamepad>/rightStick");
27.         Debug.Log("Press");
28.         movement.Enable();
29.     }
30.  
31.     void Movement_performed(InputAction.CallbackContext context)
32.     {
33.         inputVector = context.ReadValue<Vector2>();
34.     }
35.  
36.     void OnEnable()
37.     {
38.         movement.Enable();
39.         action.Enable();
40.     }
41.  
42.     void OnDisable()
43.     {
44.         movement.Disable();
45.         action.Disable();
46.     }

 

Unfortunately ATM there's no docs beyond the doc comments. A push on the documentation front is slated to happen soon. There's just some work on the action stuff that's expected have more significant impact on the API that we'd like to get done first. Better/more APIs around rebinding are also part of that.

Code (CSharp):

1. movement.ApplyBindingOverride(newBinding: "<gamepad>/rightStick");

So this goes through the bindings targeting the given action and puts `overridePath`s on them (`overridePath`, if set on an `InputBinding`, will non-destructively override the `path` set on the binding). However, the problem here is for the method to know which bindings to apply the override to. The way it's called here, it blindly puts the override on every binding, i.e. the keyboard bindings, too. Which is probably not what you want.

To target specific bindings, you have two mechanisms ATM (this is still being refined and will get improved APIs). You can target specific paths and/or target specific "binding groups".

By path:

Code (CSharp):

1.         movement = new InputAction();
2.         movement.AppendBinding("<gamepad>/leftStick");
3.         movement.AppendCompositeBinding("Dpad")
4.             .With("Up", "<keyboard>/w")
5.             .With("Down", "<keyboard>/s")
6.             .With("Left", "<keyboard>/a")
7.             .With("Right", "<keyboard>/d");
8.  
9.         // Override the path '<Gamepad>/leftStick' with 'Gamepad/rightStick'.
10.         movement.ApplyBindingOverride(path: "<Gamepad>/leftStick", newBinding: "<Gamepad>/rightStick");

By group:

Code (CSharp):

1.         movement = new InputAction();
2.         movement.AppendBinding("<gamepad>/leftStick", groups: "gamepad");
3.         movement.AppendCompositeBinding("Dpad")
4.             .With("Up", "<keyboard>/w", groups: "keyboard")
5.             .With("Down", "<keyboard>/s", groups: "keyboard")
6.             .With("Left", "<keyboard>/a", groups: "keyboard")
7.             .With("Right", "<keyboard>/d", groups: "keyboard");
8.  
9.         // Override any path in the gamepad group with '<Gamepad>/rightStick'.
10.         movement.ApplyBindingOverride("<Gamepad>/rightStick", group: "gamepad");

 

@Rene-Damm Many thanks) I understand that you are developing this system alone? Good luck in the development and early release.

 

Heh no, there's currently four devs working on the thing in various capacities and a couple platform devs jumping on and off as needed. If it was just me, there'd be no way this thing is going to go 1.0 any time soon

Thanks

 

I tested out the new version of the input system and the weird UI thing has been fixed. Not sure if it was fixed by me changing Unity versions or changing Input System version. I will try the old version of Unity I was suing at the time ands see if it was the case.

I am also having some slight issues if you could possibly help me with. I am trying to read back the value of a keyboard press. Just trying to read when the left arrow is clicked. I have the code below, but when I run it it gives me the following error.


Was wondering what data type the value read back is in. I thought it was an Int, but I keep getting invalid cast exception. Was wondering if you could tell me what I am doing wrong and also sorry for this question pretty new to the input system preview.

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.Experimental.Input;
3.  
4. public class InputDemo : MonoBehaviour
5. {
6.  
7.     public PlayerMaps actionMaps;
8.  
9.     // Start is called before the first frame update
10.     void OnEnable()
11.     {
12.         actionMaps.Enable();
13.     }
14.  
15.     private void OnDisable()
16.     {
17.         actionMaps.Disable();
18.     }
19.  
20.  
21.     void Awake()
22.     {
23.         actionMaps.Player.MoveLeft.performed += ctx =>
24.      {
25.          var value = ctx.ReadValue<int>();
26.          Debug.Log(value);
27.      };
28.  
29.     }
30. }
31.  

 

Ugh, will change that to throw a more helpful exception.

The value type is primarily determined by the controls the action is binding to and secondarily by "composite bindings" (name may change) placed within those bindings.

Basically, almost all InputControls are derived from InputControl<TValue> and thus have a specific value type they operate on. For example, a StickControl is an InputControl<Vector2> whereas AxisControl is an InputControl<float>. ButtonControls are AxisControls, too, in the current model so that it's possible to treat buttons as both axes and buttons (think triggers on a gamepad).

So, without composites in the picture, all that an action does when you ask it for a value is to go to the control that triggered the action and ask that one for its value. If that is "<Gamepad>/leftStick", for example, you'd have to do a ReadValue<Vector2>() as that's the only value type "leftStick" understands.

There's probably going to be a mechanism to explicitly set the value type that an action operates on and impose that restriction on bindings. In the code there's already InputAction.expectedControlLayout (which implies a value type), but it's not widely used yet and has no editor support.

Composites are a first step to open up value processing more. They basically allow synthesizing values from data read from controls. Eventually, this should allow for arbitrary value conversion/processing. E.g. binding a gyro to an action that expects stick-like motion and having the rotation automatically converted without the code that does ReadValue<Vector>() knowing the data didn't come directly from a device as such.

Anyway, lengthy explanation. My takeaway is we probably need to make this more explicit in the UI, too.

 

That would be nice and the changing it to a float from an int worked. I was so confused at first since in the debugger it was returning an int value all the time so I just assumed it was an int not a float, but hey everything works fully now.

 

As the first post of this thread puts "In the new model, actions are monitors that detect changes in state in the system. That extends to being able to detect patterns of change (e.g. a “long tap” vs a “short tap”) as well as requiring changes to happen in combination (e.g. “left trigger + A button”)."

How do I set up an action with combination? Thanks.

 

Unfortunately, chains aren't functional yet. Part of them is in the code but not to the point where they are actually usable.

 

So, I've started giving the actions-as-events stuff a do-over and I think it's starting to look more useful than that first attempt. The idea is, there's an InputActionQueue class now which you can use to listen to arbitrary actions and/or action maps. Whatever you hook it up to is getting recorded in the queue for processing whenever and wherever you choose to do so. Arbitrary many InputActionQueues can be hooked up to listen to the same actions and without interfering with other callbacks that may be installed on actions.

There's no automatic, frame-based flushing anymore. I think that part of InputActionManager was especially ill-advised. Instead, you control the processing and are responsible for flushing the queue.

Here's a snippet that demonstrates the setup:

Code (CSharp):

1. public DemoControls controls;
2. private InputActionQueue m_ActionQueue;
3.  
4. public void Awake()
5. {
6.     m_ActionQueue = new InputActionQueue();
7.  
8.     // Listen to all gameplay actions.
9.     controls.gameplay.Get().actionTriggered += m_ActionQueue.RecordAction;
10.  
11.     // Listen to specific actions.
12.     controls.gameplay.move.performed += m_ActionQueue.RecordAction;
13. }
14.  
15. public void OnUpdate()
16. {
17.     foreach (var action in m_ActionQueue)
18.     {
19.          //...
20.     }
21.     // Flush manually when done with the recorded information.
22.     m_ActionQueue.Flush();
23. }

Let me know what you think. Still hot off the press and not yet complete and needs refinement but I hope the direction makes more sense than the old InputActionManager. Also supports composite bindings now.

 

I'll take a look this week. I'll probably have more questions after I fiddle with it.

 

How can I use existing Unity input system or this new one to incorporate full body tracking with one or more of vive trackers: https://www.roadtovr.com/how-to-use-the-htc-vive-tracker-without-a-vive-headset/
In the link they use python script that gives x, y, z, yaw, pitch and roll. I would like to have a cheaper input trackers that will track joins on players body so we can pro programmatically move an avatar (third person)

 

@radrad07 That guide is already outdated as you can obtain pose data from OpenVR apis now (consequently via C#). And with the Vive Input Utility (VIU) Unity plugin (on assetstore and github) you can map roles to devices making implementing body tracking easy.

But bringing this back to the new Input system, has anyone compared/contrasted this with OpenVR's new input system now available via SteamVR? And how does the Khronus OpenXR spec come into play here with Unity's new Input system?

 

Got a few questions.

Is the InputActionQueue going to replace code like this.



I am a little lost on what the InputActionQueue will be replacing. Will the syntax be the same for reading back values from an action or will it change.

Question number two does the asset editor branch have the bug fixed from the develop branch because I enjoy the three column look, but also would like the bug fixes that were added to the mix in the develop branch.


When an action has two different binding that return two different values will it give any problems.
So let's say I have one binding that returns a vector 2 and one that returns float how would you handle that. Is there a check you can do to see what kind of controller or device sent the value back making it where I can just filter out which device returns which value? Saying all this at the moment I haven't ran into any reason you would have two different values bindings on the same actions was just curious.

 

InputActionQueue actually works off of this syntax. The callback-based interface is almost certain to stay. Along with the way values are read.

The idea behind InputActionQueue is that it can be quite inconvenient to be forced by the system to respond to an action right away. If we take the UI, for example, it has a very specific point at which it wants to translate input into UI events (BaseInputModule.Process). So instead of requiring every such place to manually come up with its own system to retain information from actions, InputActionQueue does that for you. You just hook it up like one of your own callbacks. Either directly into InputActions or using InputActionMap.actionTriggered to just listen to all actions in a map.

Overall, while I think the callback-based API is a good foundation for response processing, I'm still experimenting with various mechanisms built on top of it. The end goal is to not require anyone to do any myAction.something += blabla anywhere. It's easy to hide all the delegate management as a separate convenience mechanism.

Not at this point. But shouldn't be too long until that branch goes back into the develop branch.

It's a valid setup, though one with slightly questionable properties What the code can do is manually check the InputControl that triggered the binding and behave differently based on what it is. So, you could bind to a ButtonControl and a QuaternionControl at the same time and then manually check which one did the triggering and do a different ReadValue based on that.

Overall, while I think there's some value in keeping it open that way, ideally the code consuming actions doesn't have to care about particulars of bindings. This is kind of the idea behind composites. I.e. allowing to use differently typed bindings yet have them come out consistently as the same type of value.

 

I was about to ask, are you going to have a delegate-free mechanism for InputActionQueue at some point in the pipe? I'm finally done cleaning my little adapter framework and I was curious if you were gonna go back to the manual buffer read that the previous attempt used so we can avoid the overhead of delegates entirely if we want or need.

 

Which gamepads are you looking to support out of the box for 1.0 and how easy is it to add more? About a month ago I was trying to use the nintendo joy cons and they didn't work out of the box. I couldn't figure out how to add support for them myself as well. A step by step guide on how to add support for new controllers would be very nice.

 

@Rene-Damm - What's the stability/direction of IInputUser and friends? I'm still hacking away at my ECS Input device bridge (which was delayed a bit due to day job project ramp-ups and all of the recent changes with the recent ECS packages) and I'm wondering if the API is stable enough to use for basic queries. Does it have any automatic assignment management or is that entirely driven on our end?

 

Looks like things are leaning more and more towards no.

The good thing with the delegates is that anything can be hooked in really. So whether an action is responded to right away or whether it's just recorded for later processing, it's all the same to the core system. Still, looking at adding a fast path that bypasses the dispatch in certain situations may be worth looking at later. Though I kinda doubt the cost for the dispatch will really warrant that.

1.0 will probably ship with a fairly limited set. Xbox and PS4 controllers on Win and Mac and UWP, anything SDL-compatible on Linux, PS4 and Shield (and probably some misc controllers) on Android, officially supported gamepads on iOS, Xbox on Xbox, PS4 on PS4, Joycon on Switch, whatever is supported stock by the browser on WebGL.

On Switch or on desktop? Joycon on desktop we haven't looked at yet. Given the level of adoption of the device, probably a good candidate to look at next. On Switch it should work (needs more work, though).

Agree. Admittedly been singing the "we're going to work on docs very soon" song for a while now but it's going to happen, I promise. We're planning to go into feature lockdown quite soon and then it's all stabilizing, polishing, and documenting.

Unstable. Very There's still a good number of questions to figure out and the API is still regularly getting yanked around drastically.

Most likely something somewhat in the middle. It'll probably not be fully automatic but instead have a number of helpers and routines to flexibly allow implementing various strategies. Honestly, though, this stuff is still very much in flux so who knows

Not sure how useful this is but I can give you a quick brain dump of where it's at ATM. May well still have totally half-baked / stupid stuff, though.

The idea is that you put IInputUser on whatever represents a player to you and, through extension methods, that object then gains the ability to own devices and actions. You can do things like

Code (CSharp):

1. myPlayer.AssignInputDevices(devicesIHaveSelected);

But in most cases, you'll probably go through control schemes (plenty to still figure out here). E.g. for a single-player scenario you could have a way to select a scheme to default to

Code (CSharp):

1.     public InputControlScheme InferDefaultControlSchemeForSinglePlayer()
2.     {
3.         ////TODO: check if we have VR devices; if so, use VR control scheme by default
4.  
5.         var platform = DemoGame.platform;
6.  
7.         if (platform.IsDesktopPlatform())
8.         {
9.             // If we have a gamepad, default to gamepad. Otherwise default to keyboard&mouse.
10.             if (InputSystem.GetDevice<Gamepad>() != null)
11.                 return controls.GamepadScheme;
12.             return controls.KeyboardMouseScheme;
13.         }
14.  
15.         throw new NotImplementedException();
16.     }
17.  

and then assign that to your player and automatically assign matching devices

Code (CSharp):

1.         var defaultScheme = player.InferDefaultControlSchemeForSinglePlayer();
2.         player.AssignControlScheme(defaultScheme, assignMatchingUnusedDevices: true);
3.  

But there's still plenty about all this that I think still doesn't quite fit right or can be done better.

The entire setup is also meant to address the GUI isolation problem that @CDMcGwire raised earlier in the thread. Each player ends up with a set of privately owned actions bound to a set of devices assigned to the player. By passing the actions on to a UI input module specific to the player's eventsystem/canvas/camera setup, UI input becomes scoped to the player. Well, or so goes the idea.

 

Tested out the new control schema for the input system in the asset editor branch. Love the three column layout as usual it helps improve readability. The new control schema makes it a lot easier to filter out key bindings when looking for a specific key. Now I don't have to worry about typing something with s and every screen keyboard command appearing when I only want gamepads, mouse, and keyboard commands.

I got one question in the control schema I saw where you can make devices required or optional. Does the new system auto detect if a required device isn't plugged in? If so is there a bool we can check to make sure all required devices are plugged in so if someone doesn't have all the devices needed to play the game we can spit out some kind of message to the player.

Some feedback about the edit control schema button. I barely noticed the gear by the save button at first my only feedback would be make the edit gear somewhat more noticeable or instead of a gear say control options.

I am enjoying where the input asset editor is going. The flow is much better than the old input system. Keep up the good work.

 

Thank you for giving it a go and for the feedback! Much appreciated.

It's still in the process of shaping up but yes, I expect you will have that functionality.

I've relayed the feedback to our UX designer.

Great to hear.

Think we still have some way to go until we have something that does give you access to the system's functionality without at the same time throwing clutter your way but I too think we're headed in a much better direction than initially.

 

Thanks for the feedback! For the gear do you have any preference on what would be a clearer affordance? I’ve got a few ideas for the design but am curious to hear what users feel is more intuitive here. When you say control options are you thinking of a button style affordance for that?

 

Adding on to what I said I forgot to mention the main problem I had with it other then it being hard to see. At first I thought it was options for the currently selected item in the asset editor. Like the current action map, actions, binding, or property. At first I thought the duplicate function was for those until I clicked it to see what it really does.

So maybe instead of just a gear maybe say scheme options or something. Like a small button. Something to at least show this is for the control schemes and not the other stuff. Other than that I haven't seen any problems or nick pics about the current layout.

 

Hi, UNITY TEAM!

I create my BLE HID controller on ESP32 controller.
And now I am faced with the problem of recognizing the name of the device.

We are trying to solve the problem here:
https://github.com/nkolban/esp32-snippets/issues/659

Now I try to find on which side the error.
Either this is my fault or an error in your HID manager.
How the names of HID devices are parsed by editor?

It looks like UNITY Editor parsed name with UNICODE, when my HID device sends the name in UTF8.

Could this be?

 

That sounds wrong. Looking at the thread, this seems to be on Windows. Win32 APIs expect either ANSI or UTF-16. So my guess is that what happens here is that the string goes in as UTF-8, Windows thinks it's UTF-16, we read it out as UTF-16 when we do stuff like HidD_GetManufacturerString() and then convert it to UTF-8 (all our internal engine strings are UTF-8) and then in C# land, it gets converted back out to UTF-16. By then, it's gone from wrong to even wronger

Sending the string in UTF-16 should fix the problem I assume. AFAIK the stack in question here actually *only* supports UTF-16 (i.e. all the various IOCTLs that communicate with the driver).

 

Thanks for the answer!
Now everything became clear. It remains to understand how to solve this bug.
But I'm stuck between the developer of the bluetooth firmware and the developer of the input manager.

Comment from ble firmware developer:
https://github.com/nkolban/esp32-snippets/issues/659#issuecomment-427998487
We can't fix the parsing of names on the advice of this person?

 

Not sure what you have in mind TBH. We can't detect on our side whether the driver incorrectly passed the Windows HID stack an UTF-8 string and somehow correct for that.

Maybe I'm misunderstanding. Haven't gone through the thread in detail TBH.

 

I understood. Sorry. This is not your mistake.
I will study the problem further.

 

@Dotby Thinking about this more, I realized it should be dead simple to fix the product and manufacturer name without having to modify anything in the system. The HID comes with reliably recognizable vendor and product IDs (VIDs and PIDs in USB parlance) so overriding the name strings really should be a no-brainer.

On latest head, one thing you can do is

Code (CSharp):

1. // Hook into the step where the input system has discovered a new device and is now
2. // trying to figure out how to build a device instance for it.
3. InputSystem.onFindLayoutForDevice +=
4.     (int deviceId, ref InputDeviceDescription description, string layoutMatch, IInputRuntime runtime) =>
5.     {
6.         // We want to look only at HIDs.
7.         if (description.interfaceName == "HID")
8.         {
9.             // We know the PID and VID we're looking for so parse the HID device descriptor (passed
10.             // in the capabilities field of the device description) and check what we've got.
11.             var descriptor = HID.HIDDeviceDescriptor.FromJson(description.capabilities);
12.             if (descriptor.vendorId == 0x810 && descriptor.productId == 0xE501)
13.             {
14.                 // This is the HID we're looking for. We know the product and manufacturer names
15.                 // are garbage, so force set them.
16.                 description.product = "USB Keyboard";
17.                 description.manufacturer = "SIGMACHIP";
18.             }
19.         }
20.  
21.         return null;
22.     };
23.  

Customizing the HID fallback still needs work overall.

I'm still not entirely sure what your bigger picture here is, though. Skimming the thread, it looks like this is a keyboard in which case you probably don't need the HID path at all and can ignore the HID instance created in this case and instead just go through the default created Keyboard device on Windows.

 

So I did a pass on the UI with buttons, then realized that it might actually be easier and more explicit if it was part of the control scheme dropdown itself. Here's a quick mockup showing the behaviour. My thinking was having them all under the same dropdown would group the functionality and address the point you made that it wasn't apparent the functionality was just for control schemes. Let me know what you think.

 

That works a lot better in my personal opinion. Not sure how others feel, but by having it under the same drop down it does make it a lot clearer for what the buttons are used for.

 

@Rene-Damm do you still need the special build of, was it 2017.3 I think, to run the new input system?

I'm asking because I haven't tested it in a while and 2018.2 is officially out now and I don't see any new instructions...

 

It's in the main and beta builds now since 2018.1 I believe. I'm using it with 2018.3 betas.

 

Oh, nice.

But being a noob, I couldn't find it in 2018.2, and in the 2018.3 beta, the Package Manager seems to be gone from the menus. The only thing I could find was a "Modules" window that didn't list it, and a "Reset to Default Packages" menu that still left the 0.0.1 version of the InputSystem I had previously been testing in place...

Help?

 

I think it's under Settings -> Player -> Configuration -> Active Input Handling -> Input System (Preview)

 

I was wondering if someone might be able to help me. I ran into an issue where if I click off the Unity window while holding an input the input value is still read even if I have already released the key.

Code (CSharp):

1.  private void Awake()
2.     {
3.        
4.         actionaMaps.Player.Movement.performed += ctx =>
5.         {
6.             deltaForce = ctx.ReadValue<Vector2>();
7.         };
8.     }
9.  
10.     private void Update()
11.     {
12.         Debug.Log(deltaForce);
13.     }

With the code above if I click away from the Unity game view the debug keeps reading the value of the A key. Even if you clicked back on Unity it still acts like the A key is being held when it isn't.

Is this expected behavior? Is there something I am doing wrong with reading the values? How do i check if a key is being held or any input is being sent?

 

Then you have some errors in the console. Unfortunately as of now the Package Manager is running as an ordinary C# code, so if some exception happens before the Package Manager code, it fails and doesn't put itself in the menu.

If you solve the errors, the Package Manager will show up. The most common problem related to it is the default .NET run-time version. Usually it should be 4.x equivalent. It is under Settings > Player. Although it's possible you have other problems.

 

Ok, so I found the Package Manager. It must have been so late last night that I just didn't spot it.

But now I seriously can't find the Input system, even though I've enabled the display of all preview packages:

 

@cecilcruxis , you can use OnApplicationFocus message in monobehaviour to find out whether your game has a focus or not.

 

@Rene-Damm Quick question, i've been messing about with the input system lately but have ran into an issue. How would one go about getting the input control path from a InputEventPtr given from InputSystem.onEvent

Thanks!

 

Is this supposed to replace the cross platform input as I’ve noticed it’s been deprecated?

 

@Rene-Damm Ok i think i figured out what i wanted to do using InputSystem.AddStateChangeMonitor though InputSystem.AddStateChangeMonitorTimeout would actually be more useful for what i'm doing, but it doesn't have an overload which takes NotifyControlValueChangeAction/NotifyTimerExpiredAction like AddStateChangeMonitor does and StateChangeMonitorDelegate isn't public which means i'd need to basically copy that class into my own code to make this work correctly. Is there a chance at getting a similar overload for AddStateChangeMonitorTimeout?