Norman Vine wrote:
Curtis L. Olson writes:
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.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.
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.
It is realy quite simple
you either have
1) an abstract class with 'Normalized units'
class Control
or 2) a bunch of specalized classes
class Angle_Controller
class Toggle_Controller
class Percentage_Controller
etc .....
Both schemes have advantages
Quick question Do valves take 1 or 2 full rotations of the handle to fully open ?
I think we are limiting the discussion here to only flying control surface positions, i.e.
- left aileron deflection - right aileron deflection - elevator deflection - rudder deflection - nose/tail wheel deflection. - various flap deflections - various spoiler deflections.
However, what about slats which often deploy linearly rather than via a rotation. What about speed brakes that deploy linearly rather than via rotation. Even flaps themselves can be a complex combination of pieces that move together and don't necessarily have one particular angle you can assign to them.
Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel.
But when it comes to flaps, slats, and speed brakes it's not nearly so simple. There, normalized values make a lot of sense. But then to follow along with the logic, do we want to output our control surface positions in one consistent way, or do we want to mix and match units, and if we do, what if we come across some oddball aircraft where the control surface angle is a completely non-sensical concept?
Regards,
Curt.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
