Encoder mode for button assignments

[Dragon1-1]

Currently, an encoder can only be bound to DCS controls as a pair of standard buttons. Each pulse of the encoder sends a single tap on the button. In practice, this is not ideal, and has serious issues when multiple rapid presses, as happens when an encoder is turned rapidly. 

Could we get a mode that would make the button presses act like rolling the mouse wheel over a control? That, too, is an encoder, so DCS already supports that type of input. Ideally, it'd be a checkbox when binding controls, to tell DCS to treat a particular button as an encoder input. This will help anyone with that kind of control on their gear, Winwing and Virpil both include encoders into their peripherals, and of course custom panels often feature those as well. 

[cfrag]

23 hours ago, Dragon1-1 said:

Could we get a mode that would make the button presses act like rolling the mouse wheel over a control? That, too, is an encoder, so DCS already supports that type of input. Ideally, it'd be a checkbox when binding controls, to tell DCS to treat a particular button as an encoder input.

This sounds interesting, but I'm not sure I fully understand your idea. The mouse wheel is (technologically) exactly like the encoders on, say, my Virpli Panel: on my mouse, one button (MouseWheelCW)  fires when I turn the wheel in one way, the other (MouseWheelCCW) fires when I turn it the other way, neither fires when the wheel doesn't move. In DCS, the mouse wheel gets some special attention because it is also connected to the mouse pointer (or view center in VR), the 'cockpit cursor'. So the mouse wheel also has a spatial location attached. Using the spatial information, we can use the CW/CCW pulses from the mouse wheel and feed them as input to multiple cockpit controls: radio volume, HMD brightness, CRS select etc when we move the curser over the respective controls. 

Is that what you are looking for? The option to use an encoder wheel as input for whatever we are pointing/looking at? Otherwise I'm not entirely sure what your are suggesting, but since I have a lot of these encoders, I'm very interested in how we can enhance their use. 

[Dragon1-1]

1 hour ago, cfrag said:

Is that what you are looking for? The option to use an encoder wheel as input for whatever we are pointing/looking at? Otherwise I'm not entirely sure what your are suggesting, but since I have a lot of these encoders, I'm very interested in how we can enhance their use. 

No. Try binding an encoder to a knob. Roll your mouse wheel over a knob (for example, the Spitfire's trim wheel), then try turning the encoder. You'll see the difference, the latter method results in a very slow rotation, and not only that, if you turn the encoder very fast, the presses get "banked" and the wheel still turns while you're no longer turning the physical knob. This is because DCS gives the mouse wheel a special treatment, because it knows it's meant to be "tapped", but can't be held. Turning a knob via button bind is meant to be accomplished by holding down the button.

What you are describing is the reason why I'm pretty sure it'll be easy to code. Just add an optional checkbox saying "this is an encoder" and apply the same behavior the mouse wheel gets if it's checked. Holding down the button is the same as a single press (to guard against unexpected behavior when setting the checkbox on something that isn't an encoder), and multiple single presses in quick succession are treated as continuous rotation, or holding the virtual control down.

[cfrag]

2 hours ago, Dragon1-1 said:

Roll your mouse wheel over a knob (for example, the Spitfire's trim wheel), then try turning the encoder. You'll see the difference, the latter method results in a very slow rotation, and not only that, if you turn the encoder very fast, the presses get "banked" and the wheel still turns while you're no longer turning the physical knob.

Ah, indeed. I think that's related to the way DCS receives these signals, and might not necessarily be related to DCS itself but the intermediate software. My Virpil Configuration software can set up the delay and buffering between individual triggering, but I, too wasn't able to get anywhere close to the precision of the mouse wheel - in any app, nut just DCS. The mouse wheel, on the other hand, is fed from windows directly, and I suspect that this has something to do with its precision; it may be even be interrupt driven which my VPC software cant do (or rather, I did not find something that allows me to configure it that way). 

2 hours ago, Dragon1-1 said:

What you are describing is the reason why I'm pretty sure it'll be easy to code.

Let's see what they can come up with, and how precise it can be. A nice idea would indeed be that while the button detects 'turning' it turns on it's own spped and we simply keep turning the dial until we get to the desired setting (meaning there is no 1:1 relationship between input signals and increase/decrease, but merely 'keep turning at own speed while the input pulses). That might work.

 

[HILOK]

RL avionics often use proportional "steps", depending on how fast you turn an encoder. for instance, if you need to select a reciprocal heading you would not have to actually produce 180 "bumps" using the knob. instead, turning it fast would make it step by 10s, and slow turning would revert to step 1. thanks to that mechanic, after some getting used to, almost any setting can be achieved with 2 - 3 well proportioned turns. (the software FSUIPC for the MS flight suite mimics this quite effectively to some extent)

i dont think this mechanic has been implemented into DCS yet, not for the mouse wheel either. at least not for every module consistently, as you can easily see, when trying to set your altimeter or heading in the huey.

i also think this would be great for proper use of hardware encoders, mostly for cockpit functions that use an encoder and/or have a wide input range, e.g. altimeter QNH setting, HDG bug, radio FRQ selector, trimmer wheel; it would usually not be useful for knobs that control a relatively small range and incorporate stop ends like volume, lighting knobs, etc.
therefore making it a user option in the control settings (as with the axis "slider" function) seems a good idea to me. 

 

[cfrag]

Just now, HILOK said:

turning it fast would make it step by 10s, and slow turning would revert to step 1.

That would be an excellent expansion of the current control interface! If ED then also allows us to edit a curve to what 'speed' maps to what increment, this could make our encoders quadruple in value (I currently use them sparingly because they are so clunky to use)

 

[JCTherik]

On 4/17/2023 at 8:55 AM, cfrag said:

turning it fast would make it step by 10s, and slow turning would revert to step 1.

That may be possible to do with joystick gremlin.

 

On 4/15/2023 at 12:27 PM, Dragon1-1 said:

In practice, this is not ideal, and has serious issues when multiple rapid presses

Is this the virpil encoders by any chance?

 

Because in my experience, the virpil encoders are a hot garbage, they straight up skip inputs when scrolling them too fast, sometimes they skip an input even when going slow.

 

I tried to raise that issue ages ago somewhere, and got downvoted and flamed into oblivion, cause ofc. "virpil is da best". They may be da best in their axes and sliders, but their hats are kinda meh and their encoders really suck.

It seemed like a hardware limitation to me, as in, the knobs physically not being able to register fast movements. Mouse scroll wheels tend to have optical sensors, so any humanly achievable scroll speed can be measured, the virpil ones may just be metal contacts in my guess, which would mean at higher speed, the metal springs in them would just skip the dents and not make contact at all.

Edited April 27, 2023 by JCTherik

[cfrag]

3 minutes ago, JCTherik said:

That may be possible to do with joystick gremlin.

I've tried, but could not get it to work. If you have an idea, please share it, I think it would be a great help to me,

5 minutes ago, JCTherik said:

It seemed like a hardware limitation to me, as in, the knobs physically not being able to register fast movements.

I also think it's a hardware issue (I'm also using Virpil, and their encoders and buttons don't impress me much), and I think it's a microcontroller firmware issue. My Alpha joystick also has an encoder (a wheel that feels like a mouse wheel), and that works ok. Not great, but well. Yet only if you set it up in DCS as a mouse wheel. So it seems to me that the encoders work ok when set up as mouse wheel, but severely under-perform when set up as encoder. Strange.

[Dragon1-1]

I use Winwing encoders (they seem like pretty regular parts), and I can see the presses register in SimAppPro. However, they seem to be "buffered" if the encoder is turned too quickly, as opposed to doing something smarter. This might be an issue with how Windows HID interface handles rapid button presses (it has no concept of an encoder), however I'm pretty sure that at least a partial solution in DCS is nonetheless possible.