John Barrett wrote: > what I'm asking is "everything looks like it works through globals > rather than discrete instances of aircraft+fdm+autopilot -- am I > looking at a serious architectural change to get multiple > independent ac+fdm+ap simulated concurrently ??"
Pretty sure, yeah. :) The last time I looked at FlightGear's "core internals" (most of my work, like the YASim FDM, is peripheral) was about a year ago, doing the 2D-panel-in-3D-cockpit hack. Lots of existing code was written to reference "The Panel" and some work had to be done to enable the notion of multiple panel objects. Likewise, there was no easy notion of "this aircraft" within the rendering tree (all you get is an ssg node walk back). I just hacked around this one and put in a global array of panel objects with a (hopefully obvious) comment that these should be per-aircraft when that capability arrived. FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either. The problem with some great new features is that they show up with code that is "ready" to integrate, but without the integration work done. So they languish in the CVS tree until everyone forgets about them. I can recall at least one occasion where a unused module got replaced by a simpler (and arguably less functional) one precicely because the original never got integrated very well and the replacement actually worked. The extreme programming cult manages to get this idea right (every religion has a kernal of truth, right?) with their insistence on constant refactoring and integration. Features are useless in isolation. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
