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


Flightgear-devel mailing list

Reply via email to