Input settings deadzone values not respected

Hi,

I've got the default dead zone values set up in the project settings of the input system. Default deadzone min is 0.125 and max is 0.925.

These values are not respected for the default axis setups I have. I get events fired with CallbackContext containing these values:

mov: 0,03137207
mov: 0,02587891
mov: 0,02148438
mov: 0

Any hint how to handle the input to take into account the deadzones?

Thanks,
Stefan

 

What's the controls you are binding to?

ATM the deadzone min and max are expected to be picked up by every StickControl. In particular, the default deadzone min and max should affect the StickDeadzoneProcessor sitting on the stick itself as well as the AxisDeadzoneProcessor sitting on the X and on the Y axis individually.

 

sorry for reviving an old post
but i'm having the same problem

I add the Axis Deadzone on my InputSystem, changed the values, and nothing seems to change.

I'm binding on the Left Stick on a Xbox One Controller

 

I can confirm this failing for me as well with the manager preview package.

Applying a global Default Settings deadzone of Min 0 and Max 1, then applying a Axis Deadzone processor to an action or binding works perfectly.

It seems as though the Default Settings is being processed no matter what, and the Axis Deadzone processor is used on the filtered data afterward. This feels broken.

I think my confusion here is that there is a Default checkbox in the Stick/Axis Deadzone Processor that pulls the values from the Global settings (and inserts the numbers!) but the deadzoning seems to be additive.

 

I agree, that if this is intentional, I believe it should be changed. The dead zone of the input settings is always applied first and all InputActions can only process the already filtered signal. For example, I set the settings deadzone to 0.4 - 0.6 and then try to use a custom deadzone one of the InputActions 0 - 1, which doesn't work because it only receives the filtered values that are trigger within 0.4 - 0.6.

It would be more straightforward and convenient if the default deadzone would be applied only if there was no custom deadzone. I don't see any use case for wanting to add both filters, because this only gets confusing. Also, the settings define the default deadzone. Some specialized controls want to be more precise or less precise than that, so the default should be something in the middle, not always the lowest filtering. In the current state, I have to always keep the settings at 0 - 1 or very tiny deadzones, which defeats the purpose of having the setting.

Thanks for listening!

 

Hello,

I'm also not able to make it work, any update on this issue ?

here are my settings

https://imgur.com/N0rYV3I

I still get values below 0.2 from the joystick, drives me crazy...

 

I thought the Input System was supposed to be stable? Upgrading to .7 broke UI until i added a define manually, and i am also running into this exact issue.

I am using an onscreen control, so i can see exactly what i put in. With the deadzone settings set to 0 and 1, and the preprocessor added, the inputsystem still doesnt report the values accurately.

Its also impossible to set it to 0 as override, the value just reverts.

 

Oof thats some ugly UX heh.

I've been setting Default Deadzone to 0 and 1 respectively, then just adding deadzones to the inputactions/bindings where I need them. I think your input action layouts would work with that too yea?

 

For me, using version 1.0, neither the default nor the InputAction StickDeadzone processor do anything to remove deadzones. I just wrote my own in the code that handles the input.

 

I'm having a similar issue but perhaps I'm using the wrong command here? I'm getting the vector 2 for the left stick directly from the player input component on my player like this.

Code (CSharp):

1.         playerinput.currentActionMap.FindAction("Move").performed += ctx => LSInput = ctx.ReadValue<Vector2>();

The value of LSinput reaches above the max dead zone and below the min dead zone if I use the default dead zone or if I use a processor on the control. Am I getting this value the wrong way? I could easily apply my own dead zone in the code, but that seems silly.

 

having the same issue

 

Yeh still the same in 1.1.0 preview 5... this is annoying... again it takes so much time...
It seems that the global setting for axis dead zone is always respected... we need to be able to override it using overrideProcessors...

 

Just stumbled on this myself, while trying to understand why a racing wheel device had to be turned so much.

I mean, what's the point of having the UI saying this:


When it's not even an override? (it sums up to 0.1).

Oh, by the way, I already tried:


It gets applied -after.

So unfortunately that's not a solution. I guess I'll have to set it globally to 0...

 

Yeh... what i am thinking of doing is set it globally as 0 to 1 and then add deadzone processors for every action... idk if it's only me, but it feels dirty this way !

 

Same problem. Axis deadzone just do nothing, have to change the global setting.

 

Kind of solved this by write my own simplified version DeadzoneProcessor...

 

Oh I got it……the global deadzone will always be working! and the deadzone processor is processing the value AFTER the global settings! (for example: if you set a 0.2 global min value, then the processor will begin to get a >0 new stick value when the raw stick value is >0.2. The processor is working based on this new value)
And there is one more thing: DO NOT USE digital normalized value! when use this, you'll only get a 0.7 or 1 stick value that will penetrate your deadzone processor (unless you set a 0.8 deadzone wich is too large).

 

Using versions 1.1.0-preview.3 and 1.1.1
From my experimentation the global settings are ALWAYS applied. If you put a stick deadzone processor on an action, then it will be applied to the input AFTER it has been processed by the global settings.

Below I have the global settings set to their defaults. I also have a ridiculous processor on the action itself.



This is the result. The value from the action—pictured on the left—is the deadzone value of the globally processed
value—pictured on the right in the input debugger.


Here I've removed the deadzone from the action, and applied it to the binding instead.


This does nothing. I've tried every permutation of this with every controller I have, and I always get the same result. I have to create separate actions for each device that needs unique deadzone settings—racing wheel should never have a deadzone, but gamepads require them or you get ghosting.


Edit: I just tried this again and the binding deadzones are working, but only for gamepads. Joysticks don't use the binding deadzones still.

Edit Oct. 26, 2021: The PlayerInput class is also randomly switching over to gamepad input if no other input device change their values. The default scheme is set to Joystick and filter noise on .current is checked in the settings. This can be solved with default deadzone settings, but at the cost of ALL input being normalized with those settings. I now have to turn off auto switch or tell uses the unplug all gamepads, making auto-switch pointless anyway.

 

I hate having to necro old threads like this but this seems to still be happening in 2020.3.30f1 LTS on Windows 10.
Even a simple custom processor gets ignored as well.

Regretfully, I have to resort to "manually" deadzoning the input value in a C# script but that shouldn't be necessary. From what I can read in this thread there was no logical solution found and the interaction between global defaults and specific processor settings is still muddled?

A word to my usecase:
I am only checking the x-Axis of the left stick of a gamepad. Requiring the absolute of the input value to be above a high threshold is an easy way to force the player into "stick flicking" behaviour to trigger a quick-reaction strafing/dodge movement.

Edit:
A thought occured that this might have something to do with how the input system determines an action has been "performed". The checks for whether or not an action has been performed do not seem to respect the processors. If that is the case, I seem to be using it wrong.

 

Okay. So after consulting the documentation again and especially re-reading up on the differences between interactions and processors I managed to fix it myself.

In essence, I was trying to force a "button-like" behavior on an Action of type Value and control type Axis and it turns out that processors only "post-process" an input value after the phase of an action has already been determined via the interaction. The key was knowing that there is a "default interaction" taking place when no specific type is set and that gave me the clue I needed.

This is the current setup that allows me to easily set a threshold (or "actual axis-deadzone", if you will) for the left stick that needs to be passed in order to trigger the action as "performed":



The naming is still a bit janky in my opinion, but I understand it better now. Maybe this will help other people in the future.

 

Having this same problem. The on screen stick just won't even update input unless I move it half way.

 

Did you resolve your issue?

 

I don't know why this happens.
I have same problem with "Invoke Unity Events" behavior on Player Input.
But When "Send Message" behavior at Starter Asset, I don't have this problem.

 

I just discovered that the global settings are ALWAYS applied...

Really it was not clear AT ALL !! It made me lose a lot of time !

 

Yes, I had to go in and update the global settings for higher precision.