Closed PinkSerenity closed 8 months ago
Hello,
Can you explain better what is the problem? maybe with a example code or screenshots?
Hello, I have experienced the same bug, which apparently wasn't a thing in an older version I was using on other project.
In the current version published on the Godot AssetLib the joystick output value is being rounded to pointing at an angle of 0°, 45°, 90°, 135°, 180°, 225°, 270° or 315°. The output is still normalized but the values will always point to one of those angles.
The joystick seems right on the UI but when using the output, either directly or through the Godot Inputs, the movement of players doesn't look continuous as it is changing at 45° intervals.
Using the functions shared by @PinkSerenity seems to fix this problem so far, removing the rounding and making the output more continuous. Thanks for checking this issue :)
Sorry, I was pretty stressed out because of the university project I had used the asset for, and then unfortunately forgot about it until @BryanWi reminded me again.
Code is a simple set_point_position(1, vector * 100)
with the coordinates of the starting point being (0,0)
.
By the way Input.get_vector()
seems to be fixed, I didn't notice any difference when using that.
I could pinpoint the issue in the original code:
func _update_input_action(action:String, value:float):
if value > InputMap.action_get_deadzone(action):
Input.action_press(action, value)
elif Input.is_action_pressed(action):
Input.action_release(action)
I think the issue is that value
already has deadzone_size
applied to it (the function is called with output.x or output.y respectively, which are calculated with deadzone_size
) and now you check the built-in deadzone variable. if value > 0
fixes that, but then the built-in deadzone is ignored completely. The alternative is ignoring deadzone_size
and calculating with Input.action_get_deadzone()
instead. I'd argue that if people set deadzone_size
in the inspector, they want and expect that one to be applied.
When using input actions, using
Input.get_vector()
(which apparently got fixed) as well asInput.get_axis()
results in vectors that are 8-directional. I updated the following methods to fix it: