Apart from that, a little feedback from bugman may be good, because we're currently talking about the Canvas and how to use it with MP/AI models - so given that he recently touched the scenegraph code, it would be helpful if he could share what he is thinking, even if that just means sharing his plans on how to do this in the future - because
James basically agreed with his proposal, and the whole "
ownship" assumption must be teased out anyway, because it's been lingering in the tree for over a decade meanwhile, and crippling FlightGear quite severely (including even fairly recent additions like the Canvas system obviously):
http://www.mail-archive.com/flightgear- ... 00881.htmlCurt wrote:We need to be able to have multiple instances of various FDM's
running concurrenty (and with your proposed changes, accessible
through the property manager interface.) I'm thinking of things like
random 'traffic' that would get created and deleted. For instance we
have fdm[0], fdm[1], fdm[2], fdm[3] and then we delete fdm[1] because
it flew out of range, but now another aircraft flies into view so we
need to create fdm[4], etc.
http://thread.gmane.org/gmane.games.fli ... ocus=13342Andy Ross wrote: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
https://sourceforge.net/p/flightgear/ma ... /34631875/Richard wrote:the property tree as it is currently
is in need of some rework because of the ownship (single desktop
aircraft) approach. This is easier than it sounds - basically most of
the property tree becomes part of the aircraft and only a few items are
shared. This will also allow the switching of aircraft. The reason to
consider this now, and maybe not implement it, is to ensure that the
design will support this when it is time to implement it.