Godot: Holding Gamepad D-Pad does not repeat event

[hickop]

Operating system or device - Godot version:
3.0 master Linux with Logitech F710

Issue description:
Changing focused element with D-Pad or changing Sliders value is tedious because player need to tap direction multiple times.

[27thLiz]

Mhh, I don't think we're sending echo events for gamepad buttons.. might be useful indeed.

[vnen]

AFAIK, echo events for keys are handled by the OS and the delays can be configured there. Adding for joysticks would mean to add a configuration for the delays too (and to actually disable it). Note that there are no echo events for mouse or touch either.

I don't really expect echo events for joysticks and when it's needed I implement myself (I even override the OS echo settings for keys in-game to have uniform experience). There are also other things to consider like how to echo analog controls.

[HummusSamurai]

@vnen Couldn't this also be simulated by checking is_action_pressed() and a float delay counter?

[vnen]

@HummusSamurai yes, and quite easy to do with scripting.

[kubecz3k]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[lekoder]

@HummusSamurai @vnen I just encountered the very same issue, and ability to easily script-around it is deceptive.

1. While it's easy to detect that action is pressed and introduce your own counter, detecting if the pressed action was actually a gamepad and not keyboard action is not so trivial. This breaks behaviour on keypress.
2. As-is the H/VSliders are hardly usable with gamepad out of the box. I would expect bundled controls to work with all supported control schemes out of the box.
3. While the issue can be solved with work-around scripting, introducing this to already established project is tedious. There seems to be no easy way to issue an artificial echo event for action.
4. Foremost, since engine took upon itself to abstract away actual keypress/mouse/joybutton behind an action abstraction layer, it seems reasonable to expect that action interface presented to the application will be unified. User should not be required to strip down this abstraction layer in order to achieve basic functionality.

On grounds on above, I motion to re-open the issue and present a unified action abstraction layer to application.

[vnen]

On grounds on above, I motion to re-open the issue and present a unified action abstraction layer to application.

This is not really what the original issue asked for, so I prefer if a new issue is opened with a new proposal.

Let me reply to the points still:

1. You don't really need to detect if it's gamepad or keyboard, you can simply ignore the echo events all the time and do the repeating in your own code.
2. As I said in other issue: LineEdit is also not usable by gamepad, it doesn't mean we should provide a gampad-accessible virtual keyboard. I'd argue this is an issue with the controls, not with the input.
3. I honestly don't think it's that hard. I've done it in the past by simply consuming all the regular events and sending specific actions when needed. The Input system already allows you to send custom events. It requires a bit of extra configuration (I essentially had two sets of actions: one for receiving events and one for actual use in game), but also you don't really need echo events for all the possible actions.
4. While there is an abstraction, the final player is using an actual device and expects it to behave the way it does everywhere. If the OS is sending a key event, it's not Godot business to decide to not send it to the game. At the same time, Godot shouldn't decide to make up a button press event just because the player is holding it for too long. And as I said before: this requires extra configuration options (overriding the player's preference in the OS settings) and requires to be done too mouse and touch events as well, which makes way less sense.