Input reading imprecision? or is that a floating point issue? idk but it messes up my input readings

[pseudo patrol]

Using a simple

var raw_inputs : Vector2 = Input.get_vector("move_left", "move_right", "move_up", "move_down")```
I cannot get a consistent 1 reading, i would have guessed this was simply a floating point issue, but if that were the case i suppose movement_inputs.length() == 1 would be like "yeah sure thats equal" but thats not the case so im assuming this is due to how godot registers inputs?

Plus this is weird I don't get the same exact length going left (A key) and going right (D key)

moving right vs moving left (although the input length is not always exactly that as it jitters a bit but i still consistently move slower to the right) look at "Raw input length"

^
|
this happens on keyboard but not using joystick which is even weirder

oh shit this happens due to the controller being plugged in and being read as well, adding its small deadzone to the final results well that solves the second issue but not the first one which is: my input length is not at a stable 1 even when holding down a keyboard key, it keeps jittering towards 0.9803672813.... which seems too big to be a float imprecision

but still that sucks, having a controller plugged in may interfere with the keyboard movement??

[lost veldt]

did you fix it?

[pseudo patrol]

I did not

this is a bit of a mess i'll try laying it down

• Having a controller plugged in shifts Input.get_vector() if both joysticks and wasd are mapped to the same input action: like this

this is an unrelated problem to:

• Input.get_vector() reads an inconsistent 1 either when pushing a joystick, or when pressing W, A, S or D.
  It jitters to 0.98xxx/0.990xxxx

[lost veldt]

You're using: var raw_inputs : Vector2 = Input.get_vector("move_left", "move_right", "move_up", "move_down")
This function combines all input sources (keyboard, controller, etc.) that are mapped to the given actions

[pseudo patrol]

Yes

[lost veldt]

That means
Keyboard (A, D, W, S)
Controller axes (left stick, right stick, etc.)
If both are active then their values are combined. This is what's causing your inputs to jitter or deviate from expected values like 1.0.

[agile mirage]

that's just how floating point numbers work they are pretty much never "exactly" the value you want to be, but close enough. this is mainly because many exact values are literally impossible to display as a floating point number.
That's why godot includes methods like is_equal_approx() to compare floating point numbers.

[lost veldt]

Temporarily unplug the controller and test the same input logic

[pseudo patrol]

so should I use is_equal_approx() when checking if "input length" is equal to one?

[pseudo patrol]

unplugging the controller solved my first

• issue

but not the second one

[lost veldt]

Yes

[agile mirage]

yes

[lost veldt]

Use is_equal_approx() any time you're checking if a float is equal to some specific value

[pseudo patrol]

nice, thanks, so float == float is something i just should never do?

[lost veldt]

not needed just recomandation

only if you are Comparing integers stored as floats (e.g., 1.0 == 1.0)

[agile mirage]

you could do it when you specifically assigned both values. but when one of the values gets generated by a calculation it isn't reliable.

[lost veldt]

In Most Cases: Use is_equal_approx()

[pseudo patrol]

And also, does every project made in godot have that issue of having a slightly shifted input reading when multiple controllers are plugged or when one controller is plugged and youre using a keyboard?

thats funny i wonder how other engines handle it

[agile mirage]

didn't really experience something like that yet (also don't really work much with multiple input devices), but if that were a problem specific to godot it should be a bug (not saying it doesn't exists, but if it does you should report it)

[pseudo patrol]

I will look into it, trying it out on unity and unreal to see what happens

Thanks a lot to you both

[lost veldt]

no

[pseudo patrol]

I suppose you would have to create 2 input actions, one with only joystick assigned and the other with digital presses assigned, and take them into account for movement only if their length is above 0.05 or something

but sounds like something the native input actions should take care of

[lost veldt]

read docs

[pseudo patrol]

forgive me if you are not talking about the native deadzone, but what i am saying is that the deadzone is ignored if you are pressing a key

deadzones ignore the analog value if the input action value is below a certain threshold, thus the drift is taken into account when pressing move_adirection with a digital press.

instead godot should ignore the stick value if and only if the raw os' joystick value is below the threshold. that would prevent it from being read and added to the result of a digital key

[lost veldt]

The deadzone is applied at the level of action strength, meaning if the total strength exceeds the deadzone, the input counts.

If a joystick has a drift of, say, 0.03, and a key is fully pressed (which equals 1.0)

[pseudo patrol]

Yes exactly it is applied at the level of action strength, so a drift of 0.03 turns my digital key inputs to either 1.03 (which is rounded correctly to 1.00 so it doesnt matter), or 0.97 which may be annoying

If instead the deadzone was applied at a previous level, it would be ignored in the case i just described

would that not be better?

[pseudo patrol]

sorry if i am saying something foolish but I feel like "i should use another input action for joysticks" and "i should unplug my controller if i am not using it" are both, sure not a big deal, but definitely mildly inconvenient

[lost veldt]

TRY IT BUT YOU CAN ALSO TRY READING DOCS??

[pseudo patrol]

I did the first time to told me to 😭 but i can't seem to find what i am referring to

im sorry if you feel like im wasting your time feel free to ignore me

[lilac loom]

Is there a physics materail on the RigidBody and if so does it have a friction value greater than 0?

[covert gale]

You could also use clamp to limit the speed too? provided you just want to go at a consistent speed.