Fly a plane in normal level flight, without SAS on (make sure you use a nice stable plane design that doesn't require SAS just to fly straight.).

Take your hands off the controls for a bit.

Then do this at the terminal:

set ship:control:pitchtrim to 0.5.

Note, it has no effect at all.

Then try:

set ship:control:pitchtrim to -0.5.

Still no effect.

Try it with actual pitch:
set ship:control:pitch to -0.5.
and the effect is immediate and obvious,.

I suspect, but don't know KSP's system well enough to prove, that technically the trim controls are irrelevant when using a computerized flybywire controls set in which you're also setting the main control (i.e. if you say pitchtrim is 0.3 but pitch is 0, then the pitch of 0 overrides the pitch trim entirely). I think that it's not US that's ignoring the trim, but KSP itself. I think the trim system might "live" entirely in the player UI area, meaning that its purpose is just to adjust where the player's controls system gets centered, and in the end all the system really pays attention to is the final resulting control value after trim got applied to move its center point.

i.e. I think it might be this in KSP's normal way of dealing with it:

control_value = trim + player_deflection.

And then the main KSP system just looks at the control_value, and doesn't care whether the value got that way from trim or from player or both.

So when we give KSP a set of controls like so:

• control_value = 0
• trim = 0.3

Then it presumes we've already calculated a control_value according to what the player did, and thus it's totally ignoring the trim. (i.e. it's acting as if the player had deflected by -0.3, resulting in a return to the zero point from the trim point).

On another point, when we do this, the player sees no effect on the controls indicator either. They only see an effect if we set the pilot values not the raw values, and we're not allowed to set the pilot values in the script, only query them, according to our own rules.

While we're on the subject, IMO we should be able to set the pilot controls for trim. I can see the argument for leaving them read-only for the normal controls, but for the trim controls it would make a lot more sense for the autopilot to be in charge of the trim while the main pilot can override that using the main controls.

The fix may actually be to remove pitchtrim, yawtrim, and rolltrim entirely if they aren't doing anything anyway, and instead allow pilotpitchtrim and pilotyawtrim and pilotrolltrim to be settable instead of read-only.