[MikkOwl]

Originally Posted by brando

I've never noticed this one, probably because I've never found a reason to use deadzone on any of my controller axes. I DO set curves for all my axes

Filtering makes no difference, but deadband or sensitivity (courved response done through IL-2) does. Check it out if you haven't.

When I'm flying a plane I find myself constantly trimming anyway, either with the stick and pedals or the trim wheels - so it doesn't much matter whether the centres are creeping or not, so long as the instruments are centred in the cockpit.

This is fine for off-stick flying, but it it becomes an issue if the controls move on their own when you are moving across the center (imagine when gunning, even if the effect is not large enough for most to realize).

Originally Posted by Aviar

Sorry, but I don't seem to have this 'problem'. I followed your instructions to reproduce your issue. I set the deadband to 50 on all three axis.

The red and green boxes always recenter perfectly and never deviate from the center position.

Good that you tried it out. The amount of offset for the green square I am talking about is very small - one pixel up and one pixel to the left. Did you try it in-cockpit? Because there it is easy to notice (when zooming in with the FOV, static view on the ground) if the control stick moves in the slightest when repeating the same test. Easier to see than a green square that moves miminally. The stick should of course not move not even the slightest if things work as they should.

I also use the CH Control Manager software to tweak my HOTAS settings. So, if this is the kind of 'external programs' you mentioned, it may be the reason I don't have the centering issue you described

I meant the only way to have courves or deadzone (not that I use deadzone, but I do like courves) is to use external programs, if one wants to avoid this control centering bug. In my case at least.

Originally Posted by AndyJWest

Just a thought, does this show up on DeviceLink? It could just be a graphical glitch that has no effect on the 'real' control inputs.

Devicelink input cannot use IL-2's native courves/deadband so the bug cannot affect it.

It is not a graphical glitch - in fact, I noticed it when flying in an IL-2 on a longer flight (with time acceleration at times) and I noticed that it was a bitch to get the stick just 100% right, and then when testing a little I noticed that it outright turned the ailerons in the opposite direction I wanted to turn to (I had stick centered, wanted to apply a bit left-aileron to compensate for a right rolling tendency and straight up the plane and keep it there. But when moving stick very slightly to the left, the plane started rolling more to the right at first, until I moved a little bit more, where it eventually started to move in the 'correct' direction. This is due to the bug described - my stick was centered, but the courved etc IL-2 input was offset to the left a little. When I moved to to the left, the bug would stop acting (and the input would go into the real center); causing the opposite control response.

It is noticable both graphically on the control stick in game (under the reproduction steps I mentioned) and in the hardware > input screen. And it affects all controls that can be bound under "HOTAS" (not that anyone uses courves on throttle, prop and flaps but it does, I checked, set the courves through IL-2 Joy).

Just be aware it is slight, so slight I have no trouble believing 99% of users just haven't really noticed it. But definitely it will show, if the bug exists on one's system, using the reproduction steps.