Thank you, we'll take a look and get it merged.

@dany93 I think this is OK but I would like your approval. If your good with this please go ahead and merge.

Just for the discussion - is this really correct?
If i remember correctly, the trim wheel connects not to the elevator, but it's trim tab.
So trimming when parked for example should have no effect on the elevator - its the airflow flowing over the trim tab that moves the elevator into another position, and this should be eflected/impemented by force-feedback alone.

So in my opinion, the current behaviour is correct regarding the yoke, but the elevator should maybe not be moved by the trim wheel like its currently is (only in flight).

Just for the discussion - is this really correct? If i remember correctly, the trim wheel connects not to the elevator, but it's trim tab. So trimming when parked for example should have no effect on the elevator - its the airflow flowing over the trim tab that moves the elevator into another position, and this should be eflected/impemented by force-feedback alone.

So in my opinion, the current behaviour is correct regarding the yoke, but the elevator should maybe not be moved by the trim wheel like its currently is (only in flight).

You are technically correct, but the current behaviour of trim in most flight simulators is dictated by these 2 issues:

1. PC flight controls are in 99,9% not force-feedback (and hence cannot react to airflow)
2. Even if they were, modeling control surfaces reacting to airflow would be much more difficult to implement anyway - I don't know if the aerodynamic coefficients commonly available from flight tests (Roskam, etc.) include the ones necessary to model airflow effects on control surfaces.

For these reasons, the approach commonly taken by flight simulators is to allow the trim to change flight control displacements even in the absence of airflow. This is IMO the best possible compromise, even if it is technically unrealistic (mostly from a visual point of view, though).

In any case, the current behaviour of FG C172 has certainly a discrepancy, in that external control surfaces move but flight controls remain centered. To keep consistency with how trim action is currently modeled, flight controls should move as well when changing trim settings.

I think @hbeni is right regarding reality for the elevator, however @Murmur79's is the best compromise in simulation. The discrepancy is for the elevator yoke position only in flight.

This is IMO the best possible compromise, even if it is technically unrealistic (mostly from a visual point of view, though).

Thats not just a PoV issue. In real life, you can get out of elevator traversal range when mistrimmed at landings for example. By moving the Yoke also when trimming, you effectively either exaggerate that effect or you inhibit it.

It is a horse lead by a cart: The yoke moves not because of the trim, but because of changed airflow the pressure to the yoke changes. Your model moves the yoke as direct result of trimming.

In any case, the current behaviour of FG C172 has certainly a discrepancy

Yes it is. However in my opinion the proper fix would be:

1. Add a trim-tab to be animated to the elevator
2. make the elevator trim just displace this trim tab
3. make the yoke control only the elevator animation (not the underlying simulated value for the fdm; that leave as is!)

Maybe I just don't understand correctly...

In any case; I think it is a good Idea to also add a configuration option (probably "on" as default") so the user can disable this in case he has either other feelings or a force feedback system.

I for example fly with mouse, and when trimming the plane the yoke does not need to move. For example when applying power, this results in the correct behavior of "i need to push the yoke forward" and when trimming away the pressure, the yoke can stay where it is. The "felt power to push" goes from n to 0, but of course i cannot feel this. But it's what happening to the yoke when looking at it when flying.
In other words, the yoke position i set with the input of my choice, is alaways conducted with unlimited force. When i set the yoke to 0.5 pitch, it is like doing so as a ultimatively string robot, and as long as i hold it so, it is fixed as if i continuosly use my muscles to hold it there.

With a joystick that wants to center itself all the time, this is different, however, because the "no pressure" position is always the centered one, and when letting go of your joystick this will dramatically move your yoke.
Is this fixed by this request here, when properly trimmed?

@hbeni wrote

In real life, you can get out of elevator traversal range when mistrimmed at landings for example

True in real life.
In FG, every FDM that I've seen is such that if the trim is applied on a control, it limits the remaining amplitude for this control surface. If the elevator trim is full, you cannot go farther with the yoke. Even if your joystick can still be moved.

The C172 has no aileron trim, am I right?

In FG, every FDM that I've seen is such that if the trim is applied on a control, it limits the remaining amplitude for this control surface. If the elevator trim is full, you cannot go farther with the yoke. Even if your joystick can still be moved.

Indeed, for example in the FG C172, if you trim 100% nose up, pulling the stick will have no effect since the elevator is already at its max nose up position, while pushing the stick all the way down will produce neutral elevator (so you lose 50% of control authority). I think this is the best compromise for a flight sim, given the lack of force feedback on 99.9% of PC flight controls.

The issue however is that currently the trim moves the control surfaces but not the yoke/pedals. This is inconsistent with how trim effects are currently implemented: if it is decided that moving the trim actually moves the elevator (as I said, the best compromise for me), then the yoke should move as well. There is a direct and fixed relationship between flight controls position and flight surfaces position in an aircraft with reversible flight controls like the C172.

As it is now instead, if you move the trim, you can see the elevator/rudder surfaces moving, while the yoke/pedals stay centered. This also happens in flight.

Back in '21 we also had an interesting discussion about this: HHS81/c182s#382

Edit: With an interesting implementation we discussed back then, see jakkos98 comment there
Edit2: And also the insight: make it switchable

Thats not just a PoV issue. In real life, you can get out of elevator traversal range when mistrimmed at landings for example. By moving the Yoke also when trimming, you effectively either exaggerate that effect or you inhibit it.

No, because considering how the trim mechanism is currently implemented in FG (and in most PC flight sims), the modification I'm proposing would not change anything in flight dynamics or control authority.

It would be just a visual change regarding the yoke: as it is now, the yoke always maintains the same centered position when the aircraft is flying trimmed, whatever the speed/AoA it is trimmed for; with my modification instead, the yoke would actually change its position when the aircraft is trimmed for different speeds/AoA's. Just like it happens in the real aircraft.

So, just to be sure, the modification I'm proposing has no effects whatsoever on any aspect of the flight dynamics. It is purely visual, and consistent with how trimming is currently modeled in the sim.

It would be just a visual change regarding the yoke: as it is now, the yoke always maintains the same centered position when the aircraft is flying trimmed, whatever the speed/AoA it is trimmed for

Really?
This all was stable flight:
(ignore the artificial horizon, i was level. Gyro was mad at me because of CTRL+u(

In these situations I should not had pressure on the yoke.
Had I used a joystick, of course I would had t press constantly to maintain the insim-joke/joystick position. There the "effortless" zero does not correspond to the "pressure" zero, and I think this is all about what you want to fix.
And I think it is fine - but make it Optional, so mouse users can choose not to apply this.

In these situations I should not had pressure on the yoke. Had I used a joystick, of course I would had t press constantly to maintain the insim-joke/joystick position. There the "effortless" zero does not correspond to the "pressure" zero, and I think this is all about what you want to fix. And I think it is fine - but make it Optional, so mouse users can choose not to apply this.

Uhm, I think you're misundertanding what my modification does.

My modification will only change the visual position of the yoke in the cockpit (to be consistent with elevator position, as it should be).

Do a comparison flight test between the master C172 and the branch with my modification: you'll notice that when flying at the same conditions, everything will be the same, including of course the internal variables of the fdm.

The only difference will be the visual position of the yoke in the cockpit: it will be the correct one with my modification.

Again, to reiterate, with my modification nothing would change in flight dynamics, neither for people using joysticks or mouse or any other device.

Indeed, my modification just changes the output to some visual variables (specifically, the position of cockpit flight controls), and it does not change in any way the fdm. This can be easily seen by checking the few changes made to the code.

Thanks for pointing that out :)
And sorry for me being picky 🙈

The C172 has no aileron trim, am I right?

Yes, you are correct. But we do have the elevator trim modeled. I also remember someone working on the FDM to control that surface and vice versa. I don't remember offhand what that entailed though.