Stabilizer Trim Tooltip Discrepancy

See title.

I've noticed it in lots of payware addon aircraft.

Always tought it was a developer's fault, but there are so many I begin to suspect some FSX error.

Pic is from Captain Sim 763, but I could post lots of other pics from other aircraft and other developers.

http://i789.photobucket.com/albums/yy176/buffalo2602/2015-3-11_22-47-37-131_Copy_zpsadqhirvb.jpg

As you see, actual trim setting is somewhere between +3° and +3.5°, but tooltip reads -2.0°.

Any ideas ?

Wim

Graphics display vs the REAL value sown in tool tips is a frequent problem in FS not due to a fault in FS itself, but lack of attention by the coder. Gauges can get rather complicated and some coders think close is good enough. Also, some people mod their planes causing unintentional errors. Trim is one of the most problematic gauges because they are often coded with very low resolution to save space vs the importance of the display. In some planes, the pitch trim will not move at all within 2 degrees of change.

In your image, the tool tip is -2 degrees and the indicator -4 (guessing since it's partially covered up) But since zero is at the top, it looks to me as if you have negaive trim which the tool tip confirms.

It could be the coder paid less attention to testing negative trim believing it would not normally be flown this way which in most planes is an indication you are flying too fast for the weight and flaps settings.

If this trim is compiled into a CAB file, it can be corrected with some reasonable XML coding effort.

-Pv-

In your image, the tool tip is -2 degrees and the indicator -4 (guessing since it's partially covered up) But since zero is at the top, it looks to me as if you have negaive trim which the tool tip confirms.

Believe me, it's at +3.3°.

Even partially covered up (by what ???) you can see it's in the green, so definitely NOT negative.

If this trim is compiled into a CAB file, it can be corrected with some reasonable XML coding effort.

Allright, here we go... CaptainSim.b767.cp.cab - pf_s008.xml

               (E:TIME OF DAY, enum) 1 != (A:LIGHT PANEL, bool) &&

















               (L:ElevatorTrimPos,degrees)









(A:Electrical master battery,bool) !




       [b][/b]

The tooltip is the standard FSX tooltip (in bold) for the trim indicator.

In the SDK it's defined as "Elevator (Pitch)Trim && Position Indicator (%((A:ELEVATOR TRIM POSITION, degrees))%!4.1f!°)"

Looks OK to me. Any suggestions ?

Wim

I would have to install the model to tweak it through experimentation (there aren't any hard numbers you can just throw at it) and I'm not interested. You can probably fix it yourself through experimentation by playing with these:

Create for yourself a cold and dark saved flight. Move the trim, adjust the code, save and reset the saved flight. Rinse and repeat.

First confirm that zero is zero and work from there. Do all your work on the ground with the engine off and move the trim through its range by hand.

-Pv-

Hm, that's for keeping the white band within the gauge border for extreme negative values. Don't think that's a problem.

Think I'd better rewrite the tooltip based on L:ElevatorTrimPos rather than using the default FSX tooltip.

BTW in the SDK "ELEVATOR TRIM POSITION" is defined as Radians, while the standard tooltip refers to Degrees. Could this be a cause ?

Wim

"BTW in the SDK "ELEVATOR TRIM POSITION" is defined as Radians, while the standard tooltip refers to Degrees. Could this be a cause ? "

I don't think so. The standard tool tip will give the absolute value of the trim which is what you want.

You just need to adjust the offset of the graphic so the needle and the tooltip match regardless of their property.

-Pv-

Not really, but I think I figured it out meanwhile.

IMO the tooltip shows the absolute position of the stabilizer (which on most planes is slightly negative).

The white band on the gauge shows the relative deviation from the stabilizer's default position.

There's a relation between the two, but it must be AC dependant. Don't think I'll go deeper into this. For me, the discrepancy is explained.

Wim