Agreed. The stick force for a force feedback stick is proportional to Cm_de* elevator_deflection + Cm_dt * trimtab_deflection and the trim is used to set this to zero. Of cource it has no effect if there isn't a forece feedback stick.In this case, the tailplane lift could be calculated by Cl_de * (elevator_deflection + Force_Feedback ? 0 : Constant(?) * trimtab_deflection), which is the previous equation with provision for a force feedback stick. Force_Feedback is true if there is a force feedback stick.

Agreed. The stick force for a force feedback stick is proportional to Cm_de* elevator_deflection + Cm_dt * trimtab_deflection and the trim is used to set this to zero. Of cource it has no effect if there isn't a forece feedback stick.In this case, the tailplane lift could be calculated by Cl_de * (elevator_deflection + Force_Feedback ? 0 : Constant(?) * trimtab_deflection), which is the previous equation with provision for a force feedback stick. Force_Feedback is true if there is a force feedback stick.

Thanks mgh ,Then all those who read this post and the replies (to it) have to conclude that the issue I rised here about trim is not really a bug in MSFS. The post was however of a big interest by the fact of showing how choosing the right joystick is important when dealing with realism in MSFS.An other question mgh : As you surely know, in MSFS, the XYZ airplane axes pass through the visual center of the aircraft model instead of the cg (as in real world). Do you think that this difference is a problem?

An other question mgh : As you surely know, in MSFS, the XYZ airplane axes pass through the visual center of the aircraft model instead of the cg (as in real world). Do you think that this difference is a problem?

I'll answer this... The model origin is just a reference point.. and you can offset this reference point (I prefer not too, as I set things like lights, and contact point by model coordinates), as can be seen in this paragraph of the cfg file:

WEIGHT_AND_BALANCE]max_gross_weight = 2550 // (pounds)empty_weight = 1650 // (pounds)reference_datum_position = 3.6, 0, 0 // (feet) distance from FlightSim Reference position: (1/4 chord, centerline, waterline)empty_weight_CG_position = -3.0, 0, 0 // (feet) longitudinal, lateral, vertical distance from specified datum

In this case, the reference piont is moved 3.6' forward of model origin.. and then the CoG(empty) is moved back 3.0' .. effectively setting it to 0.6' forward of model origin. You can set the CoG anywhere you like.. but there's another trick in here. Model origin depends on the modeler. He could set the 0,0,0 center of his model anywhere he chooses, which can complicate all the offsetting a bit. The common denominator, that keeps us all near the same page; is that the in-sim VISUAL representation of the model, is the model's 0,0,0 ... regardless of where you set the reference point, and empty CoG.Back to the trim stuff.. You guys are making it more complex than it needs to be. MSFS simply moves the elevator deflection range (effective, not what you see) ... as in, a nose-down trim does nothing more than make MSFS see a downward elevator deflection when the control (and visual model) is set neutral. Much like real Mooney trim, that's all it does.. move the whole range. That's why, with some models, when you have too much down-trim, you can't get enough effective elevator deflection to even get off the ground.

Let me try a re-do, of my diagram:'B' represents trim set neutral; so that both the control(and visual) deflection are the same as the effective deflection.'C' represents the trim set all the way down; so that full up control (and visual) deflection are in reality, a neutral deflection and with the controls (and visual) at neutral, the effective deflection is actuall 1/2-way to full down..

I'll answer this... The model origin is just a reference point.. and you can offset this reference point (I prefer not too, as I set things like lights, and contact point by model coordinates), as can be seen in this paragraph of the cfg file:In this case, the reference piont is moved 3.6' forward of model origin.. and then the CoG(empty) is moved back 3.0' .. effectively setting it to 0.6' forward of model origin. You can set the CoG anywhere you like.. but there's another trick in here. Model origin depends on the modeler. He could set the 0,0,0 center of his model anywhere he chooses, which can complicate all the offsetting a bit. The common denominator, that keeps us all near the same page; is that the in-sim VISUAL representation of the model, is the model's 0,0,0 ... regardless of where you set the reference point, and empty CoG.Back to the trim stuff.. You guys are making it more complex than it needs to be. MSFS simply moves the elevator deflection range (effective, not what you see) ... as in, a nose-down trim does nothing more than make MSFS see a downward elevator deflection when the control (and visual model) is set neutral. Much like real Mooney trim, that's all it does.. move the whole range. That's why, with some models, when you have too much down-trim, you can't get enough effective elevator deflection to even get off the ground.

Hi Brett , but you missed my question about the aircraft XYZ axes.I mean that, looking at the visual model (spot view), the aircraft Pitch, Roll and Yaw axes are always at the same point (the visual center of visual model), whatever the cg location is. In real world, aircrafts pitch, roll and yaw around the cg point location.

Hi Brett , but you missed my question about the aircraft XYZ axes.I mean that, looking at the visual model (spot view), the aircraft Pitch, Roll and Yaw axes are always at the same point (the visual center of visual model), whatever the cg location is. In real world, aircrafts pitch, roll and yaw around the cg point location.

No, they're not.. the pivoting point is a function of CoG, and wing apex (both real airplanes and sim models).. Try really messing with those numbers and see what happens.

Let me try a re-do, of my diagram:'B' represents trim set neutral; so that both the control(and visual) deflection are the same as the effective deflection.'C' represents the trim set all the way down; so that full up control (and visual) deflection are in reality, a neutral deflection and with the controls (and visual) at neutral, the effective deflection is actuall 1/2-way to full down..

Ok Brett, but how do you explain then the absence of an elevator lift component from elevator at trim situation? As we said before, only the wing lift (equating the aircraft weight) apprears to be involved at trim (considering of course the case of the H tail incidence set to zero; see aircraft.cfg).

Ok Brett, but how do you explain then the absence of an elevator lift component from elevator at trim situation? As we said before, only the wing lift (equating the aircraft weight) apprears to be involved at trim (considering of course the case of the H tail incidence set to zero; see aircraft.cfg).

Probably because there need not be an elevator lift component... the elevator alters the wing's AoA, and that's where the lift comes from ?

As for MSFS pitch/roll/yaw animation... just put a C172 on the ground with default loading (two 170# pilots and 100% fuel) .. then go to spot view.. and then the payload screen,, Stick 600# in the baggage area, and when you pop back to spot view.. you can watch pitch animation resulting from relative fulcrums (not the model origin)... it will pitch up at the main-gear contact points..

Agreed. The stick force for a force feedback stick is proportional to Cm_de* elevator_deflection + Cm_dt * trimtab_deflection and the trim is used to set this to zero. Of cource it has no effect if there isn't a forece feedback stick.In this case, the tailplane lift could be calculated by Cl_de * (elevator_deflection + Force_Feedback ? 0 : Constant(?) * trimtab_deflection), which is the previous equation with provision for a force feedback stick. Force_Feedback is true if there is a force feedback stick.

Has anyone tested a force feedback to confirm this?I don’t have one.It sounds like your saying a force feedback joystick responds to trim.Does this mean the FFB joystick’s neutral position moves…like a real yoke/stick?I’ve tried them before, but I didn’t get the impression the neutral point moved.

Hi Brett , but you missed my question about the aircraft XYZ axes.I mean that, looking at the visual model (spot view), the aircraft Pitch, Roll and Yaw axes are always at the same point (the visual center of visual model), whatever the cg location is. In real world, aircrafts pitch, roll and yaw around the cg point location.

Sort of off topic...but actually I have seen this one. And I would call this is a bug.Or at least the SDK doesn’t make this point crystal clear - the model’s pivot should be located at the CG.The visual model will roll on its pivot - not the CG as located in the config.The flight model may very well be using the proper CG....but visually the roll rotations pivot on the model's origin.So the solution is to put the model’s origin at the CG.If you look at the 737 example in the SDK docs…you’ll see the ‘Aircraft’s Visual Model Center’ is located at the CG.I can only confirm the vertical offset is being ignored…the lat and long offsets may work.

Ok Brett, but how do you explain then the absence of an elevator lift component from elevator at trim situation? As we said before, only the wing lift (equating the aircraft weight) apprears to be involved at trim (considering of course the case of the H tail incidence set to zero; see aircraft.cfg).

I suggested that the additional lift at the tailplane to trim the aircraft is proportional to Cl_de * (elevator_deflection + Constant(?) * trimtab_deflection) with a non force feedback stick. There doesn't have to be an elevator lift component at zero stick force: the trimtab_deflection term provides it. For simplicity assume that the Constant term is 1 when the expression becomes Cl_de * (elevator_deflection + trimtab_deflection) Suppose that to trim the aircraft +5^o of elevator_deflection is required with a corresponding displacement of the stick from the neutral position. To reduce the stick force to zero, the stick and hence the elevator both must be in the neutral position. To keep the aircraft trimmed there must therefore be +5^o of trimtab_deflection.Looking the default Cessna172, visually the elevator follows stick movement and is always in the neutral position when the aircraft has zero stick force which is consistent with the expression.The trimtab itself isn't modelled.

Sort of off topic...but actually I have seen this one. And I would call this is a bug.Or at least the SDK doesn’t make this point crystal clear - the model’s pivot should be located at the CG (average).The visual model will roll on its pivot - not the CG as located in the config (+load).The flight model may very well be using the proper CG....but visually the roll rotations pivot on the model's origin.So the solution is to put the model’s origin at the CG.If you look at the 737 example in the SDK docs…you’ll see the ‘Aircraft’s Visual Model Center’ is located at the CG.I can only confirm the vertical offset is being ignored…the lat and long offsets may work.

The attached figure is from the FS2004 FSEdit SDK and is the best illustration I've seen.The default FSX Boeing 747 aircraft.cfg file sets the reference_datum_position 83.5 ft fwd of the Flight Sim Reference Position (Aircraft’s Visual Model Center) and the empty cg 7 ft (83.5 - 90.5 ft) aft of it.

I'll try another way to explain it..The model origin is decided by the modeler. I've modeled a dozen or so aircraft, most of which are FSX native.. all can be found at Simviation. All that MSFS knows, is that that origin is the 0,0,0 point as seen in the design software (Gmax). We try to set that at the wings, 1/4 chord back, for no other reason than to make displaying the model easier. More times than not, that's relatively near the empty CoG. I've experimented with all types of combos of model origins, CoGs, and wing apexes, and can tell you confidently that that model's pitch/roll/yaw animation pivot points are determined by relevant factors. If the model is on the ground, for pitch it's the landing gear contact points. For flight pitch, it's a combo of wing apex, and CoG (as loaded).I could re-load one of my models into Gmax.. and then move the entire model so that the 0,0,0 point is way out in front of the model, and even skew it laterally.. The problem with this obviously, is that the 'spot-view' focal point would be way out there too. Where MSFS 'thinks' the model should be, would be an empty spot from spot-view.. the model itself would be seen well 'behind' that spot.ANYway, as long as I propery offset the CoG and wing apex form this bizarre origin, it will pitch on the main-gear at rotation, and pitch from a point that takes the offset apex and CoG into account... it won't pitch around the model center, as though it were on some sort of invisible stick extending way out in front of it.Now I'll admit to never having taken a test to that extreme (like a model origin 100 feet in front of the airplane), but I will when I'm near my modeling computer.. I could be wrong, but from what I have seen countless hours of testing, I doubt it

The attached figure is from the FS2004 FSEdit SDK and is the best illustration I've seen.The default FSX Boeing 747 aircraft.cfg file sets the reference_datum_position 83.5 ft fwd of the Flight Sim Reference Position (Aircraft’s Visual Model Center) and the empty cg 7 ft (83.5 - 90.5 ft) aft of it.

Thanks that's the exact drawing I was referring to ;)Brett it could be that only the vertical CG offset is ignored...I haven’t tested this well.I suppose most real-life weight and balance calculations ignore the vertical axis...so it may have been overlooked.I might try relocating the datum so the vertical CG offset becomes zero – that could help.For now the aircraft does roll on the model’s pivot which is the underside of the wing spar.