Nice, so the problem is caused by wing sweep angle, that’s clear now! Wondering why Asobo doesn’t convert swept wings into a Mean Aerodynamic Chord for calculation of pitching moments… Why on Earth would the center of pressure move forward when changing a straight wing into a swept wing of the same chord and surface area, doesn’t make sense at all? Don’t need to have a background in aerodynamics to understand that its exactly opposite…
I was not trying to outsmart you, just bringing to your attention that misunderstanding can be created due to bad translations in the dev tools. I actually agree with you on the fact that the number -9.4° doesn’t agree with the graphical representation. By the way, you’re still creating plenty of lift at +/- 9° AoA, given that the typical critical AoA is in the 14° region.
1 Like
No worries, all good 
1 Like
What I’m missing is a stabilizer AOA, you could have a -9 degree AOA on the Elevator, with no net pitching moment as it is compensated for by the horizontal stabilizer. Maybe the elevator incidence is the angle between the longitudinal axis and elevator chord line or the stabilizer chord line and the elevator chord line?
I’m not sure this info is presented anywhere in the dev tools…
If I’m on the ground with no airspeed on the default A320:
Stabilizer 0:
- Full up elevator = -12.7 degrees
- Neutral elevator = 0.0 degrees
- Full down elevator = +9.1 degrees
Stabilizer full up (100%):
- Full up elevator = -12.7 degrees
- Neutral elevator = -10.8 degrees
- Full down elevator = -1.6 degrees
Stabilizer full down (-100%):
- Full up elevator = -2.0 degrees
- Neutral elevator = +10.8 degrees
- Full down elevator = +11.9 degrees
Weirdly when giving full up elevator and then trimming the stabilizer UP the elevator incidence doesn’t change and stays -12.7 degrees…
From the SDK:
" The placing of the MAC leading edge (reference chord) at the correct position along the airplane body is important for a correct CG indication in gauges However, it does not affect flight dynamics. This means that the only wing geometrical parameters influencing the simulation are:
- (S)
- (b)
- (c_{root})
- wing incidence (the influence on AoA on lift calculation)
From them the math computes as:
- (c_{tip} = \frac{2S}{b} -c_{root})
- (\lambda = \frac{c_{tip}}{c_{root}})
- (\bar{c} = \frac{2\left(1+\lambda+\lambda^2\right)}{3\left(1+\lambda\right)} c_{root},)
- (AR = \frac{b^2}{S})
Note that the following geometrical parameters can be prescribed but are used only for debug or gauges indications:
- Wing dihedral
- Wing position vertical apex
- Wing position longitudinal apex
- Wing position reference chord
- Wing CG reference chord
- Wing sweep
- Wing twist "
That’s not true…
Look at this one, maybe you are able to make sense out of this…
When the stabilizer is full up the elevator incidence does not change from neutral to full up.
When the stabilizer is full down the elevator incidence does not change from neutral to full down.
Can you change the elevator up and down limits in the flight_model.cfg?
Try to set them to 40° or something absurdly large like this. Because you might be hitting the default 16° limit value.
You think the elevator movement is only the visual model? I’m wondering how they came up with these things, max. elevator deflection of 16 or whatever degrees is fine I guess, but this should be irrespective of the stabilizer position, i.e. not a combined elevator + stabilizer max. deflection 
… Or maybe it is like that on the real Airbus but then the visual model is wrong.
Anyway, elevator incidence in dev mode is a combined elevator + stabilizer angle. So you could have a 9 degree incidence with no resulting pitching moment due to the stabilizer position compensating for it.
Edit: Boeing 747 has the same stabilizer / elevator behavior.
I’ve just tested it myself and the same occurs with 40° max deflection on both the elevator and trim and removing the 0.8 scalar on the elevator max angle.
I actually think they’ve tried to implement the variable horizontal stab using the elevator control. But it doesn’t work as it should. Since the trim moves the elevator, you can’t go farther, even if the animation plays.
EDIT: the trim is the elevator, confirmed by the AP debug window. So adding trim is like putting more elevator.
1 Like
Same on the default C172, when selecting full up elevator for example and then trim nose-up, the elevator incidence increases until reaching 0% trim and moving into the trim “up” range (and vice versa for down elevator + down trim). I assume they did this as a workaround for the limitation set by non forcefeedback joysticks with a floating trim position, and then used the same on trimmable stabilizers.
I think they should step away from the joystick position being the control surface position in the sim and approach the joystick more as the “force” input rather than a “control surface deflection input”. For example, when flying the Cessna 172 and trimming nose up, you should see the in-sim yoke move towards you and you’ll need to exert force (push forward on the joystick) to keep the elevator centered and keep flying level. They already use a force based approach with airspeed, at higher speed you can’t give full control surface deflection. I think it would be way more realistic, at least control surfaces and trim works as it should in real life.
1 Like
It’s all the same in the end, it’s just that the actual linkage between the control surfaces and the aircraft controls is not simulated. That’s actually good for airliners (except the 737 lol), but yes not accurate for all GA planes.
I don’t think there is a workaround to this specific problem at the moment, unfortunately…
What I think they should do is make the trim tab on a conventional elevator move the actual elevator just as in the real world. The joystick then becomes the force applied and is no longer directly connected to the in-sim flight controls. On aircraft with a trimmable horizontal stabilizer there is not even a problem 
. They could simulate that realistically using the tactic they have chosen, as in the joystick spring loaded center position is the elevator neutral position (i.e. elevator faired with the stabilizer), the trim DOES directly change the pitch in the real world by moving the stabilizer instead of the elevator. Unfortunately it seems they’ve copied the same Cessna approach onto jets…
1 Like
Thats a good approach but it also seems they let the engine control the throttle, not the other way round. I think that’s the reason for the lag between joystick input and throttle movement.
1 Like
That’s probably cause they don’t simulate a FADEC. With a FADEC you set desired thrust, and the FADEC manages the engine to achieve commanded thrust. But if all you have is a map between throttle position and thrust, then thrust changes are instant. So you then might choose to filter the throttle movement in order to simulate turbine inertia.
Not saying that this is what they’re doing, but sounds plausible to me.
1 Like
Sounds plausible. Its the same btw - though not to that extend - with the piston ones.
1 Like
This wasn’t the case in FSX/P3D and I doubt that it suddenly is in MSFS.
Copied from a different thread but also relevant here:
Regarding flight controls I think they should choose between either of the approaches as described below and not a mix of the two methods as we are seeing in the sim right now:
- The control inputs given are directly related to the control surface deflection, joystick full back is elevator full up, period.
- The joystick inputs are a force input rather than a direct flight control input. In other words pulling the joystick full back represents the maximum force an average person is able to exert on the controls, for example 400 N.
In the second case, at zero speed the control surface deflection is directly related to joystick position as there is no stick force, at higher speed the maximum control surface deflection and rate of deflection is reduced due to increased stickforce. This is kind of what they are doing already, but they need to improve as it is now totally impossible to pull the aircraft into any kind of accelerated stall or maintain altitude during steep turn etc.
Also the in-sim yoke or stick in this case should represent control surface position, instead of mimicking your joystick. For example, pulling the stick full back at high speed, the in-sim yoke would not move full back initially and progressively moves further back as speed decreases and subsequent decrease in stickforce makes it possible to pull the yoke further back until reaching full deflection at a some point.
Added benefit would be that trim could be accurately simulated this way. The way it is coded now the trim on a conventional aircraft works kind of like a moveable stabilizer as the in-sim yoke and elevator themselves do not move when trimming. In real life, if the yoke would stay where it is (e.g. stuck elevator) the trim tab would start to act as a tiny elevator but instead would work in reverse! The way trim is simulated in MSFS (and most other sims) would therefore never work in real life.
It also looks very non-intuitive if you would for example fly the Cessna using only pitch-trim (keep joystick centered), cut the power, reduce speed to stall speed while maintaining altitude with trim (trim nose-up). If you now switch to external view and take a look at the elevator you would find the elevator is centered and only the trim tab is deflected, also in the cockpit the joke is centered, in real life you would have the yoke in your stomach at this point.
If you consider the joystick input as being a force exerted on the flight controls and “disconnect” the relationship between joystick position and control surface position (in-sim yoke position). I think you could actually simulate the trim as it works in real life. For example, when trimming nose-up using this philosophy you would find the in-sim joke moving aft and you’ll need to push forward on the joystick to keep the elevator centered and therefore keep maintaining altitude. Trimming full nose-up you’ll potentially need full down input on your joystick to even out the force created by the trim tab and keep the in-sim joke (and therefore elevator) centered.
Asobo is using the above technique already (although implemented very poorly) to simulate increase of stickforce with increasing airspeed. They should implement either a force based or direct approach instead of the weird hybride half-baked approach they have chosen to use right now. I think considering the joystick input as a force exerted on the flight controls is the way to go, otherwise it is very easy at home without feeling g-forces or increase in stickforce with increase in airspeed to overstress the aircraft and would not solve the issue of sensitive and “twitchy” controls.
10 Likes