StickDeadzone going below min & above max

[CaseyHofland]

How else to put it: processor is not working.

Here I print out the magnitude of the Left Stick on a Gamepad with a deadzone, and lo and behold it goes below 0.125, and it goes between 0.925 and 1 too.

There are no other processors or interactions on this input action.

Here is the code:

    private void OnMove(InputAction.CallbackContext context)
    {
        Debug.Log(context.ReadValue<Vector2>().magnitude.ToString("0.###"));
    }

Called by move.action.performed += OnMove.

I have so many issues with the Input System but now it’s literally not doing what it was designed to do. I don’t even know how to ask for support on this, I know your codebase is a mess and frankly I’m keeping myself from using words I can’t take back. It’s like every time with this system.

I would advise you to decouple your low level layer and rework your high level layer, this time with a clear focus instead of 15 different ways of implementation, none of which seem to work with processors apparently.

[rdjadu]

@CaseyHofland

Here I print out the magnitude of the Left Stick on a Gamepad with a deadzone, and lo and behold it goes below 0.125, and it goes between 0.925 and 1 too.

That’s not how the deadzone processor works. It renormalizes in the range you give. So of course it drops below 0.125 and above 0.925.

////EDIT: Put another way, what you’re setup is saying is “treat 0.125 as my ZERO and 0.925 as my ONE”. So if the stick axis is below abs(val)==0.125, you get zero. If it’s above abs(val)==0.925 you get +/-1. And in-between you get the full [0…1] range. TBH I don’t get what usefulness the setup you’re describing would have.

[CaseyHofland]

@rdjadu

That’s not how the deadzone processor works. It renormalizes in the range you give. So of course it drops below 0.125 and above 0.925.

But that’s my point, the console log still prints things like 0.05.

The setup above doesn’t accomplish anything but log in the inspector to show that it’s not treating 0.05 as 0 and it’s not treating 0.95 as 1.

Ergo, the stick deadzone doesn’t work. And I’m not even doing anything weird with it, literally just using it as advertised.

[CaseyHofland]

@rdjadu I didn’t really understand what you meant until I saw the code for it. I’ll leave my own explanation here as well.

So if your stick deadzone min is 0.125, and your stick magnitude is 0.1, it will clamp to 0: great. What the documentation DOESN’T tell you is that any magnitude between your min and max is renormalized. This is the Stick Deadzone’s equation:

Mathf.Sign(value) * ((absValue - min) / (max - min));

// e.g.
Mathf.Sign(0.2) * ((0.2 - 0.125) / (0.925 - 0.125)) =
1 * (0.075 / 0.8) =
1 * 0.09375 =
0.09375 // new magnitude

Nowhere in the documentation does it say this.

Phasing out these values might be useful in cases where you want to drive animation that switches between full sprint on full stickpress and walking on anything below your max, where these values can be used as precise marker values.

So this one was on me, but I remain adamant that your codebase is a mess. InputActionState is a 4500+ line script that, in an object oriented world, apparently needs to hold every class’s hand. Sorry to work this in here but I’m at the end of my wits with the code for this thing and I’m gonna keep making a fuss about it until in 10 years the backend for this will be replaced with something less hernia-inducing.

[SF_FrankvHoof]

@CaseyHofland

@rdjadu I didn’t really understand what you meant until I saw the code for it. I’ll leave my own explanation here as well.

So if your stick deadzone min is 0.125, and your stick magnitude is 0.1, it will clamp to 0: great. What the documentation DOESN’T tell you is that any magnitude between your min and max is renormalized. This is the Stick Deadzone’s equation:

Mathf.Sign(value) * ((absValue - min) / (max - min));

// e.g.
Mathf.Sign(0.2) * ((0.2 - 0.125) / (0.925 - 0.125)) =
1 * (0.075 / 0.8) =
1 * 0.09375 =
0.09375 // new magnitude

Nowhere in the documentation does it say this.

Phasing out these values might be useful in cases where you want to drive animation that switches between full sprint on full stickpress and walking on anything below your max, where these values can be used as precise marker values.

So this one was on me, but I remain adamant that your codebase is a mess. InputActionState is a 4500+ line script that, in an object oriented world, apparently needs to hold every class’s hand. Sorry to work this in here but I’m at the end of my wits with the code for this thing and I’m gonna keep making a fuss about it until in 10 years the backend for this will be replaced with something less hernia-inducing.

A ‘deadzone’ is any zone that is ignored, mainly to prevent errors due to hardware-inconsistencies.
However, as a developer, you want to be able to simply use axes as a 0-1-value. So anything within the ‘livingzone’ for your controller is normalized to that range.
deadzone is thus used to translate your Controller-Input to the Input-Axis for the engine. Once you’re inside your game, you should always be treating your Input-Axis as a 0-1 value. The DeadZone is more low-level than you should (normally) be looking at while in-game.