New to this title

[KillaALF]

Look in the \Doc folder of your installation (x:\steam\steamapps\common\DCS A-10C). Alternatively, all the relevant documentation can be downloaded from here

[GhostDog]

"spiking axis input"- this seems to be an extreme way to put electronic axis motion that cannot even be detected by the human eye when staring at the controller calibration screen.

 

 

 

Incorrect, a very simple software filter would fix this problem. I used to believe it was noise too, until I started looking more closely. My X-65 rotary axes are rock-stable, no or very little discernible noise, and yet I still get shaking, at the same rate I got with my ancient, beat-up, crappy X-52 in fact!

 

So I think this shows us something. I think it shows that the zoom axis has discrete steps. If, when you stop moving the rotary, the electronic value from your rotary happens to fall very near one of the bounds between the discrete zoom levels, it will shake, as even a tiny amount of mechanical/electronic noise will be enough to cross between the two boundries.

 

The easiest solution I can think of is to decouple the zoom axis from direct hardware control and freeze the zoom position when the motion on the axis is very low. Simply put, first calculate a dP/dt value, where dP is the change in axis position based off the current and previous sample of the axis position, and dt is the time between those samples. Code for this would be something like:

 

 

current_P = get_axis_position(rotary_axis)
current_t = get_time()

dPdt = (current_P - prev_P)/(current_t - prev_t)

if absolute_value(dPdt) > threshold then
   zoom_axis_position = get_axis_position(rotary_axis)
end

prev_P = current_P
prev_t = current_t

You would probably also want to enable direct hardware control for a certain period of time after a threshold dPdt value was detected, but the above code gets the idea across. This is very simple stuff here. If there was an API interface between our controller axes and the C++ executable, hell, I could write this code in just a few minutes. Hmm... actually maybe I should study some of the functions that in the Lua export environment.

 

Anyway, the point is, we shouldn't be giving ED a "free pass" on this. They could very much fix this problem. I imagine that the reason they haven't is because it's low on the priority list compared to other things. So if we were to make enough wishlist threads or complaints about it, we might be able to bump it up on the priorities list.

 

Just stumbled across this. Well that explains a lot. I thought the pots in my controllers were going bad.

[cichlidfan]

BTW, I see the same jitter when I assign the slider to the rudder trim in P-51. With the slider in the right spot you can watch the rudder trim knob jitter back and forth on the screen. I can't detect the same movement in the rudder or trim tab so I have just been ignoring it.

 

If this is part of the same code issue then it really does need to be addressed since it is being dragged from one product to another.