Ownship refactorings
 |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
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.[1]
There also is the conflicting design of the how the OSG scene graph is currently managed, and the new subsystem design for greater independence. The conflict resulted in the breakage of the particle system (now fixed), the precipitation manager (WIP), and possibly other lesser known scene graph branches. [2]
We need to be able to have multiple instances of various FDM's running concurrenty (accessible through the property manager interface.), 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. [3]
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). Andy Ross 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 git 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.[4]
References
|