> That's actually a counter-example: this is all information that > FlightGear will have to have by default, but FDMs like JSBSim will not > (necessarily) -- since FlightGear owns the panel and the UI, it is the > component that tracks the position of every switch, stick, and so on.
JSBSim will need to have all this information to model the aircraft in standalone mode. Additionally, if JSBSim does have all this information, the aircraft should still fly even if FlightGear is started up using the C-172 panel, the FCS using default values. The aircraft modeler will have intimate knowledge (we hope) of the FCS for an aircraft, and the FCS definition for a unique aircraft best resides in the config file along with the rest of the aircraft specific characteristics. JSBSim is not only a FlightGear FDM, as I have mentioned before. We have an excuse to include the FCS (and autopilot and other non-visual but still flight related models) in that JSBSim also serves (and aims to serve) aero engineering students. It's meant to be a flight dynamics tool for study and FCS experimenting. In general, I might agree with you. You could split out the FCS, the autopilot, the EOM, the propulsion, etc. Then, at some point, you might say, "Hey! Let's put all of these classes under a base class that gives us some utility, some generality, and it just makes sense." Then you'd put it altogether and you'd have basically what we have. JSBSim has not been put together in a vacuum, nor without industry precedent. Given ten different people (from ten different backgrounds) you'd get ten different flight models. Jon _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
