I’m having a problem with the new input system. In my game, the input gets read every update through InputAction.ReadValue, and everything works fine. But after about 20 seconds of playing, the inputs stop registering for around 10 seconds before registering again and everything works as normal.
When the input stops registering, it freezes, the ReadValue returns the same value over and over, regardless of whatever I’m actually pressing on the keyboard. I’m 95% sure that this is a problem with the Input System, as the delay happens after all of the loading and other lag-inducing processes happen inside my game.
I’ve tried looking at the Input Debugger, but it also doesn’t show any new input while I experience the freezes.
Hopefully someone else has a similar experience or a possible solution, I’ve been tearing my hair out over this!
I have this too. Mine freezes for some 5 seconds. It seems that it only freezes once in the entire session.
[whydotheforumsnothavestrikethroughsgoddamit]Problem is: I updated to 2019.3 and to a new version of the Input System package at the same time, and I can’t be bothered to downgrade either to test.[/strike] Ah, screw it, I’ll try downgrading the package.
I was using 2019.1.14f1 and 1.0.0-preview.5. I updated to 2019.3.10f1 and 1.0.0-preview.7 and started having this issue. I downgraded to 1.0.0-preview.5 in 2019.3.10f1 and continued having this issue. I can only conclude that the bug was introduced in the native backend in 2019.2 or 2019.3.
Strike that too. After actually restarting the Editor between package version changes, the issue magically went away. This is more inconsistent than whether my coroutine will decide to inexplicably stop halfway through.
@SpiccyMayonnaise and @Ramobo , have you been seeing the issue only in the editor and in combination with package upgrades or also in players?
But the devices were still there?
My first suspicion was that the domain reload between package upgrades went sideways and that the system lost its data in the process. ATM the domain reload logic in the input system is not equipped to also handle version changes. So if the serialized data from before the domain reload is from an old version and there is a new version that expects different data, the system is likely to just lose its devices and then not do much of anything anymore.
As I said, the issue just magically went away after I messed with the package versions trying to find which one introduced the bug. I did restart the editor a few times ever since the bug started, but before this test, so that probably didn’t have anything to do with it.
It happened in the editor and I didn’t export any builds while the bug was occurring, so I don’t know whether it happens in builds.
Now that I think about it, I do have domain and scene reload disabled. Is the Input System fully compatible with this?
OK, so I have just upgraded to the 1.0.0 release of the Input System package, and the problem appears to have gone away. Note that I had to restart Unity as well.
Yes, I could see my mouse and keyboard in the list, but there was no input coming through.
Anyways, the problem seems to have just fixed itself, perhaps the new release made it go away. I’ll update this thread if the problem comes back.
Officially, no. We have a work item in the list to explicitly add support. Several users have reported it working already but that’d be more accidental than intentional at this point.
The problem cropped up again, however it went away immediately after restarting the editor.
It was not upgrading the package version that fixed it earlier, rather it was me restarting my editor after upgrading.
Not sure what causes it to happen in the first place, but if I just have to restart the editor every couple of days, I can deal with it.
we are experiencing something similar too, just 5 seconds of freezing randomly, not on all the PCs, just some of our colleagues. We use 2020.1 and rewired.
PS.: it’s just the mouse to freeze, the keyboard input is fine
Hi I have been receiving this bug for months now. I thought the latest update would fix this but the problem is still there.
It works for few seconds after play, freezes for a few seconds, then works again after that. The thing is the mouse in the input debugger also wont get any update during the freeze.
Also ran into this issue. Same deal as what others have said; input stops registering for a few seconds in the editor after about ~20 seconds of hitting play. Everything works fine after those few seconds. Only resolution seems to be restarting the editor, but it then crops up again later.
I am not sure I have been clear, but just in case: We are still using rewired, we didn’t replace it. We just stopped using the direct hardware layer and enabled the unity input option within rewired itself. Sorry, I don’t remember right now the correct names of the options. Just a check solved the problem, if it’s not in the native layer of rewired, I have no clue where it can be. Just a reminder that the problem was happening with specific hardware configurations.
I understood that. Disabling Rewired’s native input is essentially crippling the whole system because native input provides so much functionality that is not available through UnityEngine.Input. I never consider disabling native input a viable solution to problems. It’s akin to an emergency shutoff switch, but should not be used under 99% of circumstances in my view.
What I was trying to explain to you is that Rewired itself is probably not doing anything to cause it. It’s the confluence of Rewired native API calls to Windows and the Unity’s and/or the Unity editor’s. This has been the root cause of many problems in many different ways. It’s not something Rewired is doing, but what Rewired is doing is being affected by what Unity is doing. Here’s another example I ran into.
Rewired’s native XInput implementation implements a separate output thread for handing vibrations so the main render thread is never affected by slow responses from XInput when sending a vibration. It was reported to me that some game was having a 3-4 second period of frame-rate crashing lag on the main thread when sending vibrations in rapid succession with a specific device and then forcibly removing the battery to disconnect the device (or the battery just dies). I knew I had already spent countless hours refining and honing the XInput implementation to avoid all possible main thread delays due to vibration as this issue came up years ago when the Xbox One devices were released. They behaved worse than Xbox 360 devices, requiring the multi-threaded approach to prevent issues. Well, I was seeing the same old frame-capping behavior when sending vibrations again even though I had already implemented multi-threaded input and output. I debugged down at every level to find out what was possibly causing this lag as it made no sense that it would be stalling the main thread. There was zero code in Rewired that was accessing XInput from the main thread. Then I realized – UNITY also makes calls to XInput. Based on my testing, they make calls to XInput from the main render thread. That was what was causing the 3-4 second stall. Not Rewired, not Unity, but the combination of making Set Vibration calls through Rewired on a separate thread while Unity makes calls to get input from the device on the main thread. The device was gone from XInput, yet it still reported it present and was accepting SetVibration calls with no error, but with a long thread stall on each call. Rewired’s calls didn’t affect the frame rate because it was making them on a separate thread, but then Unity makes calls to get input from XInput on the main thread, and those calls also lagged out while the device was in this limbo state, stalling out the render thread. So, no, this was not a problem with Rewired. It was an artifact that Unity runs at the same time as Rewired. Low-level API issues may bubble up through both systems.
OK I am not sure how similar the example you posted is. I am sorry in case you got this too, but the frame rate was not affected at all as well as the CPU load. It was just the mouse to freeze otherwise everything else worked fine (including keyboard input)
I wasn’t intending that example to explain your exact problem, only to be a point of reference to see how something Unity does with a native API may result in some side effect that makes it look like Rewired is causing a problem. The keyboard lag example with Raw Input is much closer to what you are describing.
Is this happening in the Unity Editor only or in game builds? I have no way to reproduce it so I have no way of debugging this new Unity version-related problem.
it’s very hard to repro as we had difficulties to repro on different machines using the same mouse as well, but at least you need to have that specific mouse model (Mad Catz RAT 8+). If I remember correctly it was happening in the editor as well as on the client.
