Conversation
|
Also added keybinding for adjusting scanning parameters stepwise. |
I haven't seen an issue filed on this. What is the issue? Is the use case that you want to adjust the sensitivity for keypress binds that adjust a slider or dial or similar control? Or does the encoder simply not register? If the unreliable behavior with knobs/encoders is fixed, would these keybinds become redundant? |
|
I ask because if we can make it so that any applicable keybind's rate and behavior are tuneable, we wouldn't have to implement stepwise logic ad hoc for each input. Could do it once instead of dozens of times and again for any new binds. |
|
I haven't filed an issue because I just got one of those macro keyboards the other day, And as my implementation is basically the same as your patches for impulse and jump controls (which was ironically introduced because the other bindings where too sensitive for key presses), which also work fine for that hardware.
Almost never. Maybe once or twice per 20-step revolution. My assumption is that the pulses are too short.
Of course it would be nice if we have less keybinds, but on the other hand we already started it with the helms and jump controls and I don't think there is much left. I think only 4 for the engineering slider, and theoretically 2 for ship rotation, but I think holding down a key feels much better than rotating a knob. |
This adds keybindings for 15 degree steps for the manual weapon aiming. When the binding is used, the aim will snap to the next multiple of 15 rather than just adding 15°.
That way you can use rotary encoders or knobs on macro keyboards for aiming. As they only send a short signal each step, they do not work reliably with the weapons_aim_left/weapons_aim_right bindings.
Each step is a 1/24th of a full circle, which means you will hit both 8 cardinal and 12 "clock" directions. It is also pretty close to the 20 steps per rotation that many rotary encoders have, and you won't get a perfect positional match anyway.