I can confirm this is occurring... again... My input devices I tested are: XBOX 360 For Windows (Controller), and Saitek Pro Flight Combat Rudder Pedals.

I can't fly until this is fixed :(

I will add that I've tested an xbox one controller and saitek prox52

Hey all, some updates and a possible (although stupid) workaround:

Hey guys,

Thanks to Ratszo's post here: http://forums.bistudio.com/showthread.php?186337-New-Patch-has-decreased-sensitivity-of-my-input-devices-(controller-and-pedals) - I tested out unbinding one of my controllers at a time. That is: I ensured I only have ONE non-keyboard/mouse device bound to my rudder.

This seems to be a usable workaround for the issue.

When I have the XBOX 360 controller - right stick bound to rudder and my saitek pedals bound to rudder - my rudder rotation is cut (I assume) in half.
When I unbound one device, and tried the other - I got my full rotation back...

So this will work for now - but I prefer to have my fall-backs available - and I see no game logical reason that would require this sort of change from BIS. If the reason was to fix an issue where using two input devices would result in double turn speed: then the solution is not to average each device... It is to enforce a maximum turn radius on game objects that need one...

That is a very bizarre change... This work around fixes the symptoms but this should still be addressed by the devs. Thanks for this find Jay

So... anything to report, BI? Seems like you "fixed" this before, and it's come back and now it's getting ignored.

You're right - the input of multiple axes mapped to one action are averaged.

I'd recommend sticking to mapping only one axis to an action.

So the solution to your bugs is for us players to avoid your bugs? Glad to see this took you guys 9 months to figure out

I'm sorry to disappoint you.

This is how it is intended to work. It suits the dual throttle controllers. It also can provide more precise control in specific setups.

Mapping two different axes to one action isn't supported as a standard. Here it is but it comes with limitations.

Thank you for replying oukej, I appreciate you confirming what we all knew. It seems rather silly to cater to a specific type of controller while simultaneously screwing everyone up (No onecan have a control setup for SFM and AFM on the same profile now) but you know your demographic better than us.

I do wish you would make the AFM collective speed uniform across the board for the non-analog input though

Feel free to suggest a better solution