Fixed axis inputs clashing with discrete inputs

[codeinclined]

I've noticed with some of my own projects that mixing axis inputs with other types of input in a single action (such as "move_left") can cause the two to "fight" each other. It mostly happens when you hold down a key for an action that also has an axis assigned to it. Randomly, you could just lose the state of the key being pressed until you lift the key and press it again. Other times, it can just ignore the keypress altogether. I think it's a timing-specific thing with the engine's input code if the analog sensor in the gamepad momentarily exceeds its deadzone (which can happen, especially with noisier sensors).

I saw this behavior occurring right away when I first ran this project and implemented a simplified version of the fix I did in one of my own projects to get around this issue. Basically, actions with axis inputs are split into two actions. I named these "discrete_move_left", "joy_move_left", etc. I called the keyboard version "discrete" rather than "key" as a pattern. The only thing needed to fix this issue is to keep axes separate from discrete inputs. You could add D-Pad buttons to the discrete actions alongside the keyboard without any issues. I didn't do so here only because I didn't know if we had something in mind for the D-Pad in the future.

Just to reiterate, not all actions will need duplicate actions for joypad. Only actions with axis inputs seem to cause problems. This may not have been an issue for most people, but if I'm encountering this across multiple projects and versions of Godot, then it might also affect others in the future.

• [X] Motion.gd: Fixed random axis input collisions on "move_xxx" actions with discrete input
• [X] godot.project: Split the following actions into two actions:
  • "move_left" => "discrete_move_left", "joy_move_left"
  • "move_right" => "discrete_move_right", "joy_move_right"
  • "move_up" => "discrete_move_up", "joy_move_up"
  • "move_down" => "discrete_move_down", "joy_move_down"

(This is a resubmit of #87 due to my mistakenly working off of master the first time I submitted the PR)

[Zireael07]

Looks like a Godot bug that should be reported to the engine repo, too.

[codeinclined]

@Zireael07 I’ve considered it. Not sure how you’d fix it at the engine level beyond setting a higher default dead zone for axes if such a thing exists.

[NathanLovato]

Thanks :)