Repeating keypresses after delay for keyboard keybinds

[aBlueShadow]

This restores a behavior we had back in the SFML days: If a key is pressed, it sends the keybind signal just once, only after a short delay it starts repeating, like with the text input. This allows much better control of slider values via keyboard keys.
This does not affect joystick axis bindings, and I also added a new function getRawValue() for the few occasions this behavior would not be desired (basically just combat maneuvers, and probably ship rotation).

keyboard.mp4

[oznogon]

This is going to be subjective, but I consider this to be a regression even over the current SDL behavior, which also isn't ideal but is a matter of re-tuning and ramping rates in ways that are appropriate to each control.

SFML's behavior was also poor IMO. The raw repeating keystroke inputs aren't deterministic across systems and can be modified outside of EE in unexpected ways. For instance, I disable key repeating in KDE, so this effectively breaks all continuous keybind inputs for me. This is especially disruptive on Helms, where keybind steering becomes unusable.

We can have discrete inputs, even repeating, using SDL for consistent behavior regardless of OS settings, and also without such a long and disruptive pause.

[aBlueShadow]

As I mentioned

And I also added a new function getRawValue() for the few occasions this behavior would not be desired (basically just combat maneuvers, and probably ship rotation).

So I intended to replace the getValue() functions with getRawValue() for steering and combat maneuvers, as there shouldn't be a reason why we we would want an input delay here. The rest are mostly sliders, even with disabled repeats I would assume that would be better than the unprecise movement we have now? But I have to admit, I did not test that specific setting.

[daid]

I agree with oznogon, depending on OS key repeat I do not like.
I also think the rawvalue is wrong. For the simple reason that joysticks jitter around "zero" when standing still, and getting this value all the time will constantly "do" a tiny bit of movement, sending out network requests.

Making the deadzone configurable might be something that would be wise however.

[aBlueShadow]

You are right, rawvalue is a bit of a misnomer, but rawvaluewithoutdeadzone would have been a bit unwieldy, and making it an actual raw value that includes jitter within the deadzone would defeat its purpose. I just could not come up with a better name.