For me its difficult to point out exactly what the problem is with the flight model, maybe someone with in depth knowledge can see what is going wrong from the (long) video below. All of these issues came to light when trying to figure out why all MSFS aircraft are so sensitive and “twitchy” on the flight controls during crosswind landings. A couple of bugs:
- First off all to get a proper crosswind at ground level you need to set an insane windspeed at altitude, as MSFS takes the “ground wind” entered by the user, uses that as the geostrophic wind and then modifies it using a very rough rule of thumb which only works for light to moderate wind speeds to a surface wind. In order to have a surface wind of 25 kts, gusting 35 kts for example, you’ll need to select 50 kts gusting 70 kts in the weather menu (!) as MSFS cuts the surface wind in half. This makes simulating a proper crosswind landing with twitchy MSFS aircraft even more difficult and makes it more gusty and turbulent at higher altitude compared to ground level, in the real world it is the other way around.
- Seeing that even heavy aircraft like the Airbus A320 and Boeing 747-800 are tossed off flight path really easily with the slightest crosswind or turbulence and are feeling like a Cessna under those conditions, the question about inertia (or the lack thereof) came up. To test this I tried to pull the fully loaded Boeing 748 and Airbus A32N into an accelerated stall. Its difficult to say if there is a real lack of inertia or if there is an issue with elevator effectiveness. It basically comes down to this, when flying the A320 or Boeing 748 and pulling the yoke or stick full back, the aircraft does NOT enter an accelerated stall, instead the aircraft enters a vertical climb or loop. The flightpath of the aircraft does not stay behind sufficiently to increase the AOA passed the stalling angle.
- Related to this, when stalling most MSFS aircraft, no matter if it is a Cessna 172 or Airbus A320, no matter the aircraft weight or CG position, the aircraft becomes a falling leaf instead of performing a clean stall break, a wing drop or spin. In a climbing turn or descending turn the correct wing doesn’t stall. Performing a steep turn, you’ll run out of elevator authority before reaching critical angle of attack etc.
I’m not particularly interested in having the simulator simulate the edges of the flight envelope and beyond with perfect realism. But the basics must be right, for anyone using MSFS for training, it is important the correct wing stalls during the base to final turn for example, when being to aggressive on the controls the aircraft should enter an accelerated stall instead of making a GTA V style loop etc.
In the below video I went through all different kinds of maneuvers, trying to demonstrate what is wrong with the MSFS flight model. I tried to have as much information possible on screen, the developer mode PITCH visualization, some basic simulator figures, the sidestick is visible on the bottom left side of the screen, as are the throttles, PFD, ND and ECAMS. The aircraft used is the default A320 with flight computers OFF (direct law mode). I went through basically the same kind of maneuvers on the Boeing 748 with the same results, just to indicate it is not a problem with one particular flight model. I noticed the CG is quite far forward at MTOW in my tests so I went back into the sim with the CG on the aft limit (not recorded) and I found no significant difference.
The Flight Path Vector (FPV) is selected and should give some idea about the AOA (the angle between the FPV and the aircraft symbol) assuming no wind, you can see that the aircraft is able to fly at very low speed (below 40 kts indicated airspeed even) at a positive angle of attack without any stall warning. On the contrary the stall warning sometimes sounds at very low AOA.
Maneuvers performed (MTOW):
- Accelerated stall at 250 kts
- Accelerated stall at Vmo
- Full stall in landing configuration
- Full stall with flaps 1 (forgot the fully retract the flaps)
- Full stall in clean configuration
- Stall in 45 degree bank steepturn
Maneuvers performed 10% fuel, no payload:
- Accelerated stall at 250 kts
- Accelerated stall at Vmo
- Full stall in landing configuration
- Full stall in clean configuration
- Stall in 45 degree bank steepturn
- Some more accelerated stalls, full back sidestick and THS full up
- Some rapid pitch ups and attempted accelerated stalls using outside view so you can see the AOA indicator.
- Crosswind landing with 25 gusting 35 kts at ground level.
Video
Time stamps added:
Accelerated Stalls
When flying straight and level and pulling the sidestick full back, the nose pitches up but the aircraft keeps following the original flight path initially due to its inertia, this “disconnect” between the aircraft pitch and the flightpath (and therefore relative airflow) causes an increase in AOA passed the stalling angle of attack.
You can see from the flight envelope below the result of using full flight control deflections, below the designed maneuvering speed the aircraft will enter an accelerated stall before reaching the aircraft designed limit loadfactor (+2.5g for most modern air transport aircraft), when flying faster than the designed maneuvering speed the peak loadfactor will be higher than 2.5 g before entering an accelerated stall.
You can see that in MSFS the flightpath and pitch rate stay more or less in synch when pitching up sharply and the AOA therefore never exceeds the stalling angle of attack. Result: the aircraft enters a vertical climb until running out of energy or even loops instead of entering an accelerated stall. Even with full up elevator AND full up stabilizer trim, the aircraft won’t enter an accelerated stall. I noticed that the AOA during a sharp pitch-up only changes as a factor of airspeed. During the pull-up at Vmo for example, you can see the AOA stays perfectly within limits, then increases slowly as airspeed decreases. Its a little weird for me, I would expect the elevator and stabilizer are more effective at higher speed and therefore should result in a higher AOA when pitching up sharply at Vmo compared to 250 kts or lower. From the outside view, when looking at the AOA indicator, it almost looks like there is an AOA limiter installed, the AOA rises rapidly towards the stalling angle and then stays just below.
Does anybody understand why the lift vector is negative at a positive angle of attack when flying upside down (at 33:50)??? The lift vector turns around, at some point even pointing directly in the direction of travel…
Maneuvering Speed (Va)
Definition: The Manoeuvring Speed (VA) of an aircraft is an airspeed limitation determined by the aircraft designer. At speeds exceeding the manoeuvring speed, full deflection of any flight control surface can result in damage to the aircraft structure.
The stallspeed can be calculated by multiplying the 1g stall speed x the squareroot of the loadfactor. According to the sim the estimated stall speed at MTOW is 178 kts and at 10% fuel and no payload 129 kts. With a 1g stall speed of 178 kts it only takes 2g at 250 kts to stall the aircraft, which is the same as a 60 degrees angle of bank steep turn.
| MTOW | 10% Fuel, No Payload | ||
|---|---|---|---|
| Loadfactor | Stallspeed | Loadfactor | Stallspeed |
| 1 | 180 | 1 | 130 |
| 1.5 | 220 | 1.5 | 159 |
| 2 | 255 | 2 | 184 |
| 2.5 | 285 | 2.5 | 206 |
| 3 | 312 | 3 | 225 |
| 3.5 | 337 | 3.5 | 243 |
| 4 | 360 | 4 | 260 |
In short, at MTOW, the designed maneuvering speed is around 285 kts. When pulling the nose up at 285 kts the aircraft will reach a peak loadfactor of 2.5g, the same time the aircraft enters an accelerated stall and loadfactor decreases. For an empty aircraft the design maneuvering speed is only 206 kts. Above those speeds, using full control inputs the aircraft will reach a peak loadfactor above 2.5g before stalling, causing structural damage or even structural failure. Again according to the diagram:
You can see that in the sim at MTOW and Vmo, the peak load factor reaches around 2, while the peak load factor at empty weight reaches around 3. In real life, when performing this maneuver above design maneuvering speed you will reach far greater peak load factors and pull the wings straight off.
Full Stalls in 1g - Level Flight
Full stalls (clean and landing config): the aircraft behaves the same as the default Cessna 172 and other aircraft I have tested. The Airbus does not reach stalling angle and makes a stall break, drops a wing or enters a spin, instead become a “falling leaf” and keeps oscillating around the stalling speed, even with full up elevator AND stabilizer trim.
Stall During (Steep) Turn
Stall during (steep) turn: the aircraft starts descending, keeping its AOA below stalling angle with full up elevator and stabilizer trim.
Crosswind
Apart from missing the feel of any mass going down that flight path, the aircraft behaves weird during crosswind conditions, for some reason the aircraft pitches up early during take-off with crosswind, during landing, whilst keeping the elevator in the flare position, the nose stays in the air. When flying in no wind conditions the aircraft does not exhibit this weird pitch behavior.
Conclusion
I think there could be two reasons for this odd behavior:
-
There isn’t enough inertia simulated and therefore the flight path responds too rapidly and stays in synch with the pitch. This would also explain the sensitivity and twitchiness of the controls, in gusts and in turbulence and the ability to loop a fully loaded aircraft.
-
The pitch authority is insufficient. Asobo did show in an aerodynamic video that they simulate exceeding the stalling AOA on the horizontal stabilizer during large elevator deflections, maybe they have overdone this effect and the elevator authority is now severely compromised. At 2:00:
In any case, I think we can all agree this behavior isn’t right. If someone has any other ideas, please comment below and lets figure this one out for Asobo.
Edit: Elevator Deflection versus Airspeed
I think I found atleast one of the issues, when looking at the elevator deflection it is somehow depending on the airspeed, so full back sidestick at Vmo only means a few degrees of elevator deflection. I think this is due to another “improvement” they’ve incorporated to make make planes behave more “realistic”. I believe this was explained in some developer Q&A, but I can’t find it.
They’ve explained something like, its harder in real life to pull the stick full back due to the feedback from the flight control system and G-forces so they’ve limited something. Just tested on the Cessna 172, exactly the same thing going on, no full elevator deflection at high speed. This would explain the weird stall dynamics and inability to pull the aircraft in an accelerated stall, it does however not explain or solve the sensitivity issue.
The implementation is done very poorly, to the point that you can’t even stall an aircraft anymore, can’t maintain altitude during a 45 or 60 degree steep turn etc. From the video below, you can see the elevator deflection above my mouse pointer. When inside the cockpit you have no hind that this is even happening as the yoke position mimics your joystick position and is unrelated to the actual elevator position! Not how it works in real life at all of course, totally unrealistic.
I’m thinking they have done this to mask the underlying problem of sensitive and twitchy flight controls. I think they’ve “dumbed down” the up and down draughts for the same reason. If they would get rid of this elevator deflection by airspeed / G-loading effect or open up the up / down draughts fully they will get a lot of complaints as the underlying problem of sensitivity has not been solved. It should not be necessary to have this maximum limit on flight control deflection as a factor of airspeed, even Level-D simulators aren’t able to simulate g-forces, although they do simulate higher stick force at higher airspeed. There is nothing realistic about full scale elevator input being 28 degrees elevator deflection at low speed suddenly becoming only 7 degrees defection at high speed.
Asobo, please, please remove this or make it an option!!!
Elevator Trim
Something else I found out which I thought was interesting is the way MSFS simulates the elevator trim on conventional flight control systems, for example on the Cessna 172. When trimming the elevator the elevator deflection itself does NOT change, but the aircraft somehow does pitch up / down, almost as if the aircraft has a trimmable horizontal stabilizer. I don’t know how other simulators simulate this as there is a limitation here without force feedback and floating in-trim position.
In real life, the trim tab moves the elevator, which in turn creates a nose up / down pitching moment. Since the elevator deflection does not change at all, and the aircraft does not have a trimmable horizontal stabilizer, how on Earth does the aircraft trim in MSFS??? In the real world if you would trim while the elevator is held in position or is jammed / stuck the elevator trimtab itself starts to become a mini-elevator but instead works in REVERSE, i.e. trimming nose up will move the nose down and vice versa. The way MSFS simulate elevator trim should in theory increase the elevator pitch authority. In real life the elevator trim drives the elevator itself to the up or down position, with the trim fully nose up, the elevator (and yoke) would be fully nose up. In MSFS you could trim the nose all the way up and still have elevator in the neutral position, so range left to pitch up even further, unless they somehow compensated for this.
In the photo below you can see the aircraft trimmed nose up with elevator neutral. This would never work in real life, the situation below would actually cause the trim tab to act like a tiny elevator working in reverse, pitching the nose DOWN instead of UP, also there wouldn’t be much pitch authority as the surface area of the tab is very small. The purpose of the trim tab is to move the elevator, in this case to the UP position which in turn pitches the nose up.
In the video below you can see the yoke (and elevator deflection) does not change when trimming. When releasing the aircraft from active pause moving the elevator controls the pitch even further, even though the elevator is already trimmed full up or full down. In real life when the elevator is kept where it is, trimming up or down has only a small (reverse) effect, the aircraft will more or less keep flying level but it will require a lot of stickforce to keep the elevator in this position.
I’m not saying it is wrong and I don’t know how other simulators handle the limitations imposed by using a non force feedback joystick without floating center. I do think the current implementation is a poor way of simulating elevator trim, I think it would be more realistic to approach the joystick inputs as the force applied rather than the absolute control surface position, this would also match their approach with regard to previous topic. If I understand it correctly X-plane uses the force based approach, the deflection of the control from its spring loaded neutral position is taken as the force the pilot applies to the control, rather than the controls absolute position. I think this is a more realistic approach to trimming. MSFS has chosen a strange approach were everything is a weird mix between the joystick controlling absolute control surface deflection at low speed but force based at higher speeds.
The joystick simulating the absolute control surface position rather than force is the core of another problem, in MSFS it is possible to steer the aircraft with the autopilot engaged, this is impossible in real life as you can’t physically move the controls when the autopilot servo’s are engaged. The correct simulation would be to completely ignore the control inputs via your joystick or yoke with the autopilot engaged. When large inputs are given the autopilot should trip offline and hand over controls to the pilot, just as in real life when you apply excessive force on the controls with the autopilot engaged. In every single aircraft I have ever flown, there is not one where I could control the aircraft with the AP engaged, you can’t physically move the controls with the servo’s engaged so below the autopilot disconnect threshold control inputs should be completely ignored.
Elevator Trim Acceleration
Another odd design choice is the weird acceleration in the pitch trim, when trimming for more than a few seconds the rate of trim starts to increase. This is not how trim works in real life, with electrical trim the rate is constant no matter how long you keep trimming. When making large trim changes using a manual trim wheel I would start with large trim wheel inputs and then finetune when getting closer to the in-trim position. The trim accelerating with time is therefore counter intuitive and has nothing to do with the real world. It would be pretty dangerous on aircraft with big trimmable horizontal stabilizers to have the trim running away like that.
The theory is correct… implementation is a whole other story 
