Brief description of the issue:
Detail steps to reproduce the issue encountered:
It has been one of the most annoying problem I’m finding with FS2020, as if there is no direct relationship between hardware controllers and their representation in game.
Context
For example in the 747, the yoke roll angle animates slowly and doesn’t match your hardware controller position. On top of that, it is not even linear but the rotation angle is the inverse of a sigmoid (slowly near center and accelerating at the edges).
There is another aircraft which I have not tested with 1.18.13 yet, where you can test side-by-side the controller animation problem I’m describing above. Load the G36 and compare the animation of the mixture and the propeller levers when using a hardware throttle quadrant with both physical levers. One of the two moves faster than the other for the same lever deflection change.
The same control input flaws can be seen with steering tiler, and brakes and the game is handling these axis like it used to be with older games, where joystick/keyboard only allowed ON/OFF positions and the more you keep the input ON, the more the yoke would roll for example (the inverse sigmoid function I mention above).
I believe this way of doing is right for piloting the game with an XBox controller where you have limited input range (you can’t compare a controller 1 inch stick to a Honeycomb yoke roll amplitude for example).
But I also find this default behavior wrong especially when using more sophisticated hardware controllers.
Problems
One of the main problem I can see with the 747 is that it is not just the visual yoke roll angle which is changing slowly, but it seems the control surfaces are also moving slowly, as if they were not moving per my hardware controller input, but by the dampened slowly rotating 3D yoke in the cockpit. I know these could be hydraulically actuated and there is no direct relationship eventually, but the “sensation” is that you’re out of control. It doesn’t seem to be the case on smaller aircraft but this raises the question what is FS2020 doing with the raw axis input value prior feeding the control surface logic and/or the animations.
As for the steering tiler, it seems the tiler maximum deflection gets attenuated by the aircraft speed artificially. There could be aircraft with such “dampening” or “limiting” factor based on speed, but it seems to me ALL aircraft are having the same controller input filtering applied regardless.
In addition, the difference of position between the hardware yoke and the 3D yoke poses another problem in VR, where your proprioception no longer matches what you see.
Solutions
1- If FS2020 is currently filtering the axis input like described above:
- Make this an option in the accessibility (or elsewhere settings).
.
→ when enabled, it would be like it is today
.
→ when disabled, you’d have direct match between physical and virtual yoke, brakes, tiler, etc…
Basically it is about offering the choice between filtered and raw axis handling.
2- If this is not a controller input filtering problem but only a visual animation problem at the model level:
- These animations should be avoided by aircraft vendors in my opinion.
.
→ using aircraft like this in VR is really disorienting sometimes because of the difference between your proprioception and the visual feedback (it might just be me though).
.
→ these could also be making the user to overshoot or undershoot corrections when the visual yoke on screen is distracting from the physical yoke corrections.
I believe most vendors are using the default ASOBO behavior files for their yokes, brake pedals, etc… and if the animation making the yoke slowly moving to reach the actual physical position is in these behavior files, then disabling these animations could be done globally and conditionally too (see point 1 above).
In all cases, I believe this is something which requires additional attention because it doesn’t always feel right.
NB: It is not dissimilar to the typical 1sec switch animation found in many aircraft: you click the switch and it takes 0.5 to 1sec to change position, slowly moving from one end to the other. I believe it is useful when using a keyboard shortcut because it gives you time to get the visual cue, but I also believe it is wrong when using the mouse, a physical controller, and soon a VR controller. In these cases, my opinion is that the switch should change nearly instantly like IRL (in other words, switch animations should never be longer than 0.1s which still gives 6 frames at 60hz and 3 frames on Xbox at 30hz).
For this last point, I find most Asobo aircraft are fine with regard to the switch animations in general though!
Do you have any add-ons in your Community folder? If yes, please remove and retest before posting.
Are you using Developer Mode or made changes in it?
Provide Screenshot(s)/video(s) of the issue encountered:
PC specs for those who want to assist (if not entered in your profile)
Build Version # when you first started experiencing this issue:
Are you on the Steam or Microsoft Store version?
Did you submit this to Zendesk? If so, what is your ticket #?
n/a