Jon S Berndt wrote:

Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot be seen. Neither Amps nor fluid pressure are reported on a zero to one scale. Aerosurfaces can be drawn and seen, and that's not done on a zero to one basis either. Like I said, there are some things that can be done on a zero to one basis, such as landing gear deployment. But, aerosurfaces are reported in degrees, regardless of whatever aircraft it is, it's already "generalized" to its lowest common denominator. Why it should be further "reduced" and then reassembled to the exact same value (one hopes) later on when rendered via SimGear - that's defies description, IMHO.

It is true that we can pollute our code (a.k.a. "implement wrappers") to satisfy FlightGear, but why? We know what the control surface limits are. So, what do we do? Pass a normalized value AND the aerosurface limits so they can be reconstructed later? Why not just pass the raw value and be done with it?

Code that massages physical parameters to make up for shortcomings in the rendering/animation system doesn't belong in the FDM. If it doesn't belong in SimGear or on the FlightGear side, it belongs in the FGInterface class - but I don't think it even belongs there.

I know this sounds "forceful", and I don't mean to step on any toes here, I just feel strongly about this.

For what it's worth, I recall there being some sort of substantial discussion at the time this was implemented, I just don't recall what that discussion consisted of. I tend to support your position John, however, let's not act too hastily because a lot of code and animation depends on this behavior.



Curtis Olson
HumanFIRST Program
FlightGear Project
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d

_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to