Bug Runtime Error "Exceeded budget for maximum input event throughput per InputSystem.Update()"

Not sure if this is a bug or I'm doing something wrong, but if I'm in play mode with the new input system for more than a minute or two I consistently get this runtime error that stops play mode.



The only script in this test project does this

Code (CSharp):

1.  
2. public void Start()
3.     {
4.         _map = InputAsset.FindActionMap("Player");
5.         _moveAction = _map.FindAction("Move");
6.         _horizontalAction = _map.FindAction("Horizontal");
7.         _verticalAction = _map.FindAction("Vertical");
8.         _attackAction = _map.FindAction("Attack");
9.         _jumpAction = _map.FindAction("Jump");
10.  
11.         _moveAction.Enable();
12.         _horizontalAction.Enable();
13.         _verticalAction.Enable();
14.         _attackAction.Enable();
15.         _jumpAction.Enable();
16.     }
17.  
18.     public void FixedUpdate()
19.     {
20.         Horizontal = _horizontalAction.ReadValue<float>();
21.         Vertical = _verticalAction.ReadValue<float>();
22.  
23.         Attack = _attackAction.ReadValue<float>();
24.         Jump = _jumpAction.ReadValue<float>();
25.     }
26.  

which I don't think is doing anything crazy.

Unity 2022.2.2f1
Input System set to Process Events in FixedUpdate

I looked at the docs and I don't see how me not pressing anything would generate over 5MB of input event bytes in a single frame.

 

Same here, no idea what's happening.

 

In 2021.3 I get this when I tab away from the game while it's playing (it stops updating), and then tab back. It's just a glut of input data backlog that needs to get absorbed or discarded.

What input device(s) are you using at the time? Any special high-event-bandwidth mouse drivers, etc.?

 

Just a mouse, keyboard and a mayflash adapter. But if what you say is true it makes sense because this adapter has 4 slots and the HID viewer in the Input Debugger shows the dpad being represented by independent left/right/up/down

BIT

buttons but also as a Hat Switch marked as a

DpadControl

. The problem is that for some reason the adapter has Hat/right (aka right on the dpad) default to 1 instead of 0, while left/up/down are all correctly 0. So Unity's Input system detects hat/right as permanently being activated from all 4 adapter slots even when no controllers are plugged in. Fortunately though the independent dpad/right button correctly defaults to 0 and works as intended, but the flood of hat/right inputs that are still coming from the 4 adapter slots could explain the reason behind the error.

(Pic demonstrating the text above) (button14 is the independent dpad/right button and correctly defaults to 0, and the hat/right (which is the same button on the dpad) defaults to 1


Speaking of that though, I don't fully understand it because for some reason:
-The Listen button in the InputActionAsset doesn't detect the fake Hat/right presses (which is good).
-PerformInteractiveRebinding also doesn't detect the fake Hat presses (which is good).

But if I do any of the recommended solutions in this thread https://forum.unity.com/threads/check-if-any-key-is-pressed.763751/
for finding out if there's any button press active, such as:

InputSystem.onAnyButtonPress.CallOnce(ctrl => Debug.Log($"{ctrl} pressed"));

This detects the fake Hat/right input coming from all 4 empty adapter slots and triggers 4 times every frame even with no controllers plugged in.

Code (CSharp):

1. for(int i = 0; i < Joystick.current.allControls.Count; i++) {
2.    if(Joystick.current.allControls[i] is ButtonControl button) {
3.       if (button != null && button.isPressed)
4.          Debug.Log(button);
5.    }
6. }

This method of checking for any input when a controller is plugged in also detects the fake hat/right press every frame.

So I'm not sure the difference between them to explain why Listen and PerformInteractiveRebinding don't detect it (as desired) and why the various "if(anyButtonDown)" checks shown above do.

Also the

PlayerInput.onControlsChanged

callback fortunately doesn't detect the fake hat/right input either, but I don't understand why.

It would be useful to know how they're internally detecting inputs in all of those things and potentially expose it to make a more accurate anyButtonDown via code.

I can obviously create a custom class inheriting from InputDevice for this specific adapter that ignores the Hat switch entirely since it's not really needed because the independent dpad buttons work. That would work for everyone using this same adapter. But that doesn't solve the issue for someone with a different adapter that may suffer from the same problem.