Anyone else noticed this controller bug?
 

EDIT: Others have confirmed it. A video showing the bug in action can be seen on page 3.

I've suffered from this (and a couple of others I met) since I first got IL-2 1946 in November. It's very annoying to say the least. Could any of you also check if you have this same (rather serious as far as flightsims go) bug? I already reported it to the 4.09m bug topic stickied above, and here's a repost. Please check if you find the same behaviour.


DESCRIPTION / SYMPTOMS

When using IL-2's native courves or deadband functions for joysticks, IL-2 in-game joystick will move away from true center if physical joystick is centered.

VERSIONS AFFECTED

Observed since at least version 4.08m. Mods or not does not alter outcome.

HARDWARE

WinXP-32 Home Edition (latest service pack). ASUS P5-B Deluxe with up to date drivers. Tested with older and newer drivers, including for USB. Tested with different USB ports and USB drivers, hubs vs no hubs.

TESTED WITH:
Logitech Extreme 3D PRO
Logitech G940
Logitech G25 Racing Wheel (!)
Saitek Quadrant
All devices tested with different versions of their corresponding drivers.

Was present from beginning, no mods. Have reinstalled completely fresh to make sure. Have deleted all config files for user and conf.ini for testing purposes.

TO REPRODUCE

1. Start IL-2.
2. Go to Hardware > Input
3. Change the first three or so sensitivity sliders to zero for pitch and roll (it can be seen with even the default settings, but first try this).
4. Move joystick around and observe the red input and green output squares in the monitor on the same screen. Move around some ways from center, and then center repeatedly, slowly and quickly, especially near and at center.

The red is where the user's joystick is, the green is how it is moved in IL-2 after being adjusted/filtered by IL-2. When moving it around the center, the green square is centered (since deadband means there should be no reaction at all in IL-2). But when centering the red square (actual joystick), the green moves approximately one pixel up and to the left away from center. Moving away from center, makes the IL-2 adjusted/filtered green square move INTO center again (where it should have been all along).

You may enter a cockpit on the ground and zoom in on the stick in the cockpit, and repeat the same movements. With a big deadband, the stick should not move at all when moving the stick around, only remained static in center. But it moves slightly (very little) to the left, and forward, when joystick is centered. Behaviour also visibly seen with rudder pedals and levers (if they use courves or deadband).

If using a normal no deadband & sensitivity courve (going from 5, 10, 15, 25 etc) you can observe this: moving away from center slowly, makes the IL-2 adjusted/filtered green square move INTO center first, until a certain point is reached (not far), at which it starts behaving completely correctly. Bug is only when near or at center.

NOTES

• Affects every type of controller from various manufacturers.
• Affects every axis that is bindable in IL-2 (trims, flaps, rudders).
• Device calibration is irellevant. It applies even to axes and IL-2 things that have no center (throttle etc). If the red input square is centered, the adjusted green will move offset from center.
• The offset is always to the left, or if the axis is vertical (like pitch) it is upwards.
• The offset is seen only when any kind of deadband or less than 100 sensitivity is set at the center (i.e. the leftmost sensitivity slider in the hardware > Input screen). It does not affect the axes already set uniformly by default to be flat (like flaps, trims, prop pitch, throttles) but they too will display it if deadband or sensitivity is tweaked.
• The offset bug is not visible in the third party IL-2 joy utility, but by using that utility, lowering sensitivity or having deadband near the center of any axis bound to anything (like flaps) can show that in game, the bug really does affect every single axis.
• The only way to not experience this self-moving offset is to set the sensitivity to 100, deadband to 0 and use external programs to try to tweak in a joystick/device courve, such as dxtweak2 or the Logitech Profiler.

Interesting. I must say that 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 that are controlled by potentiometers - pitch, yaw, roll, throttle, trim up/down, trim left/right - using the IL2Joy utility; but,as stated, no deadzone, and no filtering.

I seem to recall, from years ago, that it was explained that these latter functions were intended for older devices that jittered around their centrepoints. It may be that you have no need of these filters in the first place. Also, it all seems to be rather a 'static' interpretation of input. 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.

I can see this might cause problems when using the Autopilot function offline, or Level Stabiliser flying a bomber, but it's still adjustable in the latter case using trim. I suggest that leaving deadzones and filters alone might help

brando

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.

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

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).

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 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.

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.

Anyone else noticed this controller bug?

No

I have torn out and deleted anything pertaining to my IL-2 installs (main one was the steam version but had an older in my program folder as well). Went through registry with a comb to delete any mention of IL-2. Uninstalled the Logitech Profiler drivers and deleted all references to them in the registry. Uninstalled and deleted all mention of the Saitek Quadrant drivers/software. Rebooted several times. Downloaded Il-2 again from Steam, fresh. Launched (4.08m), testing it out - no change. Same bug.

However, with the joystick now having no curves set by outside programs, it was harder to get it completely centered (in order to observe the bug, especially in the cockpit). I had to look for it for a while, esp when starting airborne and camera moving around a bit, before I could certify it was still there. And it is. Sucks...

The stick is seen moving slightly as I described, when the joystick is completely centered. And it does indeed affect the aircraft flight, could be seen from outside and inside, especially when under time acceleration.

That's the spelling I was looking for, thanks for pointing it out. I kept feeling disturbed by it lately as "is this really as it should be? Feels wrong". :) Need to get my Firefox spelling checker plugin working again.

Hmm, that is crappy for me and good for you. Did you closely observe the stick with maximum zoom on the ground to see if it moved in the slightest when joystick goes from dead center to near center etc?

Did you try it in the hardware setup screen AND in-game cockpit as mentioned in the reply to Aviar?

After more testing, I've found that it is not as apparent with using only deadband as I suggested using. When using only deadband to test it, it does move offset, but since the stick never returns to true center this is almost impossible to notice when in the cockpit visually.

So if anyone could please try the following method and I would be very happy:

1. Set sensitivity of your roll and pitch in IL-2 to zero for the three leftmost ones, and set deadband to zero for both.

2. Step into the cockpit ON THE GROUND (do not be airborne since it is harder to verify) and zoom in on the control column/stick.

3. Move your joystick very carefully across it's center point, as if barely moving from center at all. What I see is that the column moves slightly to the left (just a bit) and slightly forward whenever the joystick is at true center. When moving away from it, the (cockpit) control column returns to true center.

If you have any external software to change the curves of your stick, set it to lowest sensitivity, as that will make it much easier to hit the centermost positions of the stick.

I just tried this with my Saitek Quadrant with nothing Logitech control-wise connected and the virtual driver bus interface disabled in the system settings even, and I observed the above.

I find it very unlikely that IL-2 would be any different on my computer compared to others', and it cannot be a hardware problem since it is only brought on by trying to use the IL-2 curves (Sensitivity) native to that application. The bug itself appears when a control input is at true center, which implies that there could be a coding mistake where the curve sensitivity processing is turned off if the controller is centered, as 'there is no need for it', and it re-engages as soon as the controller leaves center. But for some reason what is considered 'center' for the processed input is slightly offset, perhaps the exact same distance that is required for the controller to move before the curve processing is re-enabled again.

That plane has trims - but I presume you mean you move the stick around gently near the center at the same time as described in the reproduction steps and yet it flies absolutely straight, even in time accelleration.

As you said though, you followed the instructions and could not reproduce what I see. That's good enough for me.

I presume the steam version (which is the one I bought) of IL-2 is somehow defunct, as that's the only thing file wise that can differ between us presuming a clean install and all.

In the example you provided, it could be either way, because the P-80 has aileron and rudder trim (if I'm not mistaken). If you are trimmed to fly straight with stick centered, it would be that with the bug just the same.

I can't try your example because my G940 slop prevents the stick from being completely centered without a hand holding it there (and it's hard to do it continously as there's no tactile feedback). I did see the stick move in the cockpit and the plane reacted even though sensitivity was set so that no movement was supposed to be possible.

The P-80 control stick moves very noticably with the bug btw. Try setting ALL the sensitivities for pitch and roll to zero in IL-2 and step into the P-80 cockpit. Surely the in-game stick should then under no circumstance be able to move. If you have the bug, then the stick can be seen moving forward (when the Y axis of the joystick hits center) and left (when X-axis touches center) as long as the real joystick is centered. So moving slowly over the center point of the real joystick should make the cockpit stick move left-right, forward-back etc slightly but noticably if you keep camera focused on it.

Note that if you have a well centered spring joystick (for example), the first thing you are likely to notice is that the in-game stick moves to the right and backward a bit whenever you move your stick from center.

Give me a moment and I will record a brief replay displaying how it looks like, then upload.

I recorded the control column/stick moving by itself even though sensitivities were set to 0 - to find that the replay doesn't show it moving. Isn't that AWESOME? All I could record was a stupid looking high speed replay of a 262 slightly changing roll direction and pitch even though the control column isn't moving. Not even going to bother showing such junk.

Tried your P-80 example. Without touching any trims what so ever it has a phugoid oscillation up and down (which is not important). But yes, moving the stick over the center position makes the in game control stick move as I have described, moving the plane accordingly (slight left/right roll, and some minor pitch change, visibly quite clearly when time accelerated).

I think I have just about had it with trying to get anywhere with this bug. I'm going back to disabling all the in-game curves and just using external programs to tweak curves with, that way no bug and no more nonsense. That it didn't even record on replay was the last straw.

Thanks for testing and checking it out. No idea who else is affected and what causes it but it is small enough not to be noticed by most anyway, so I'm betting it will never be officially recognized or fixed.

Yes, it can visibly be seen, although not 'stare you in the face' obvious due to the small amount.

I made a typo in the fig.2 illustration. It should read "underneath green", not red.

http://hem.bredband.net/mikko.artist/center_bug.gif

I set the roll and pitch axes of my stick to 50% dead band (in IL2), no filtering, and all 100% sensitivity sliders. I saw the green square move in the input setup section, for both roll and pitch, when the real stick was crossing the centre.

I then watched a Beaufighter's and P-51's stick when on the ground, and could not see any movement at all in the column/stick, when doing the same movements as above.

I use a 4096 step BU0836A and hall effect sensors. Due to it's long throw, I normally use 100% sensitivity and no filtering, and have noticed (when keeping the wings level) that IL2 has a noticeable step around joystick-centre, when at any other position, it a tiny joystick movement yields a tiny in-game joystick movement. I've always thought something was a little wrong... along with the strange interpretation of power/pitch axes (I know from DIView that the stick is giving 4096 steps for these axes as well, yet IL2 gives me 2-3% increments).

Yes, I can reproduce this.

Well for what its worth I did a screenie of my MSFFB2 centring in hotas.

After moving the stick full around and then letting it centre it shows perfectly in the middle of the cross-hair red square under the green square, I can only assume that these other peoples sticks have faults of some kind or are not setup properly.

My stick is 9 years old and works faultlessly after daily usage of around 4-5 hours, shame they stopped making them :(

Here's my settings if anyone wants to try them :)

[rts_joystick]
X=0 1 4 9 16 25 36 49 64 81 100 0
Y=0 1 4 9 16 25 36 49 64 81 100 0
Z=0 10 20 30 40 50 60 70 80 90 100
RZ=0 10 20 30 40 50 60 70 80 90 100 0
FF=1
U=0 10 20 30 40 50 60 70 80 90 100 0
V=0 10 20 30 40 50 60 70 80 90 100 0
1X=0 10 20 30 40 50 60 70 80 90 100 0
1Y=0 10 20 30 40 50 60 70 80 90 100 0
1RZ=0 100 100 100 100 100 100 100 100 100 100 0
1U=0 100 100 100 100 100 100 100 100 100 100 0
1V=0 100 100 100 100 100 100 100 100 100 100 0



http://img.photobucket.com/albums/v1...1021-15-59.jpg

Question to everyone (Letum, Julian, Aviar, KG26_Alpha etc): what version of the game do you have? As in, DVD, steam, direct2drive or whatever else is out there. Mine is the STEAM version.

Never initially centered. It follows a clear pattern - if joystick centered, green (and in-game) off-centered (the bug).
The yaw axis is offset because it reads my G940 stick TRIM1 wheel as yaw axis, and I had not centered it.

It is the opposite: the red box is the 'input' that IL-2 reads from your actual joystick position, while the green is the processed 'output' that is used to determine in-game control movements. However, if sensitivity is set to 100 all over, and no deadband is set, then there is only the green. That is when the bug appears to go away for me.

The actual aircraft movement is seen in replay playback. Can see it chance pitch and roll - the effects of the bug, but cannot see the control column move. Two possibilities exist: 1. the replay fidelity does not include control movements that are very slight visually, or 2. the engine believes that the column is centered when recording the replay (and technically it should be) and so plays it back as if it was - but it retains 100% fidelity of the aircraft actual movements.

Repeat the same above but set deadband to zero, then observe control column. And if you can, choose the Me-262 A1 in a 'scramble' mission starting on the runway, and go to gunsight mode (Shift-F1), as the control stick in the cockpit is then VERY close to the camera and from a more top down perspective.

Using deadband makes it go off-set, but it does not go back to center when one's joystick leaves the actual center. So, do it with zero sensitivities and zero deadband.

Yeah, that strange 'interpretation' in the center is sure what it feels like for me, if I don't use 100% sensitivity and no deadband. If I make use of no IL-2 joystick tweaks, then it is okay. I can't tell 100% as there is the 'reversal bug' on the G940, making it slightly jumpy in certain conditions, and I do use curves (a lot of it) normally from the Logitech profiler, since the IL-2 native ones are bugged.

The 2-3% thing seems to be the way IL-2 reads the axes. I get it as well on devices that have 256 positions (while in-game throttle might have 120 positions).

As I asked in the first line in the post, let me know what version you have of the game (steam etc). Watching that screenshot it is absolutely clear you don't have the bug.

However, the hardware isn't faulty, for I have tried connecting and assigning all kinds of controllers to all kinds of functions in IL-2. It affects the rudders for example, and trims, throttle, pitch, roll, FLAPS - anything that can use an axis. Even using the Saitek Quadrant (as only connected device in an experiment), using a lever each for pitch and roll, shows the bug behaviour 100% reliably as any other controller. It is something to do with IL-2 itself as it only appears using controller tweaks native to IL-2; place the red square in the middle with any controller and it goes off-set. It does not exist when not using them.

Interesting about the boxed DVD version. Maybe this turns out to be affecting all steam versions, for example? It's not the first time steam and other versions have had quirks. The steam version already broke the setup executable (it is not possible to launch it and set up your hardware stuff before launching the game, everything must be done in game or in the conf.ini file).

Regarding your erronous edited thingy, it's nothing special :) But useful to be left for clarification for others who might not be as sure. Don't let personal prestige affect you.

_____

To be specific, my steam version, first downloaded (and later redownloaded) was the one pre-patched to 4.08, which could make a difference, because they provide the whole folder, as if it was already installed from a DVD and patched to 4.08. Someone having a steam version which was pre-patched to an older version might have been able to avoid getting the same (possibly broken) files, as they patched to 4.08 and onwards manually.

Whilst there is a certain amount of misunderstanding of the input options around, as a mechanical engineer by qualification, with strong interests in electronics and programming, and having designed and made my own hotas, I don't think I have too many misunderstandings of this topic.

Because I don't use filtering, and set all sensitivity sliders to 100%, with no dead band, I don't see the original problem shown by MikkOwl when flying in IL2. However, I could reproduce it by following MikkOwl's steps, but only in the axis configuration screen, and not in the cockpit.

The problem I mentioned regarding level flight might not be related to the one being discussed.

Originally 4.07m from an Australian (same as European?) DVD, upgraded to 4.08m then 4.09m with UI 1.1 mod. My tests were done in modded 4.09.


Indeed. My best guess is that IL2 checks for a match to certain percentages, whereas the controllers don't quite match the values that IL2 expects. For example, the controller might output 34.125%, whereas IL2 is looking for 34.000%, hence 34 is skipped. Just a guess, however.

I definitely don't have a hardware fault either, I have never seen this in other games or setup screens, or DIView.

Did you try it without deadband in the cockpit? Especially using the view I suggested in the Me 262. It should be noticable obviously in most aircraft, but some more than others. One problem I found is that it's not easy to hit the dead center position of a stick on my G940 in particular, when trying to do the cockpit testing (since there were no squares to guide me and it has 'slop'). Putting in some curves from outside of IL-2 made it much easier though.

The control impact is small. It's most easily seen when flying time accelerated.

If you did it all then, move along :)

Though I'm sure you are talking about a real effect, I can't help wondering if it reallly matters that much. Real-world aircraft wouldn't be expected to fly hands-off for long, and being perfectly trimmed for a shot is a rarity, so how does this affect anything of consequence? And come to that, I don't think any real-world contol system can have been totally error-free either: cable-operated systems are always prone to slackening, and even pushrod systems will have a degree of 'float' around neutral loading, unless they are artificially stiff.

It matters enough for me not to ever subject myself to it, certainly. It is annoying when the plane moves in a direction opposite to control inputs, for example, especially during gunnery. Others do possibly not suffer from it either, which is a concern in multiplayer.

When flying hands off, in a plane that does has the required trims, it is a non-issue, since one can just trim it away when flying hands-off. In planes that don't have trims, it can be a real pain in the ass during cruising as the only option is either to fly at a much lower (or higher) RPM on the engine to counter the left-roll input, or to constantly hold the stick and apply tension on it to the side. I've tried it and could not deal with the strain on the wrists.

I just use external programs for it instead now, so for me the impact is very small: only a loss of some tweaking ability.

EDIT: Do tell more about how the systems work and should behave like, it is something I have not heard much about. I love learning about aircraft all across the past 25 years :)

I'm not quite sure of what you mean regarding 'zero sensitivities' and zero dead-band. A zeroed sensitivity slider will give a dead band, is that what you want?

Look at the image I posted to show the exact settings.

Zero sensitivity as in the sliders set to 0 for several of the leftmost ones in the hardware > input screen, but also deadband set to zero.

Although they should be the same (we know this), they do not act the same in the game. That is why I revised my instructions on how to reproduce the bug in the best way to use sensitivity tweaking instead of deadband.

Using deadband makes it go off-set in the game, but it doesn't return to center when the joystick is not centered. But when only using sensitivity instead, it does return to center, making the movement much more observable.

I repeated the test using no "dead band", but the first sliders set to 0%, and saw the incorrect stick movement in both the setup screen and in-game. I can see this as being quite annoying for people who use a dead zone, though I am making the assumption that this occurs when the dead zone is smaller.

For your viewing pleasure:

a video (xvid AVI)
http://www.jpfiles.com/misc/dead_zone_test/262.avi

In the video, I am moving the real joystick slightly left and right, and up and down, over the centre point whilst staying completely inside the dead zone set by the sliders - the in-game stick should not be moving at all.

It does not only affect having sensitivity to zero, but anything less than 100 for the leftmost one!

Now try all these things, but with default settings (which is a curve set approx 10, 20, 30, 40 etc, just hit the DEFAULT button in the input screen). The same shit happens. When centered, it goes offset. When moving away from center, it moves into center first, then moves towards where the actual joystick is moving. Also feel free to try it in mid flight and see how the aircraft actually does respond completely accordingly to this bugged movement.

None of this should be happening, and it does affect things. I am going to link to this from the bug report thread that is stickied. I do hope they can throw in a fix.