I think I will support this proposal under a couple of conditions.

1) 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.  Also probably sooner rather than later,
John is going to want to be able to air drop his X-15 from our Cessna
310. :-)

2) As you know, accessing property manager values via static
propertynode pointers is more efficient because you only have to do
the expensive string name hash lookup once the first time the routine
runs.  It would be nice to have a set of static property node
accessors set up that any code could use, rather than having each
routine duplicate the static propertynode element it needs.  Perhaps
it would make sense to put all these static accessors into FGInterface
and creat accessor functions for them? <stepping back out of swinging
distance> :-)

3) And we'll need three very large folks to sit on Norman and hold him
down while we do this. :-) :-) :-)

4) Norman sent me a raft of changes for Mingwin that might conflict or
at least make different changes in some of the same areas as you are
looking at.  I didn't get a chance to work my way through them all
today, but I should probably do that and apply as much of that as
makes sense in light of your proposal, while trying to avoid the
changes that might potentially conflict.


David Megginson writes:
> I'd like to rip out most of the FGInterface (src/FDM/flight.hxx)
> methods and strip it down to the bare essentials: basically just the
> init/bind/unbind/update methods.  There's a lot of kruft in there that
> nobody uses, and it's far too brittle for our fast-growning flight
> models: note that JSBSim.cxx already bypasses it for recent changes
> (going directly to the property manager) and YASim was designed to use
> the property manager from the ground up; no one is bothering to extend
> FGInterface for the new features that are appearing.
> The adapters for the various FDMs currently work like this:
> 1. Copy state from FGInterface into the internal FDM model.
> 2. Cruch a bunch of numbers.
> 3. Copy state from the internal FDM model back to FGInterface.
> That means that there's no performance advantage to holding the values
> in FGInterface -- they have to be copied anyway.  The new approach
> would be
> 1. Copy state from the property manager into the internal FDM model.
> 2. Cruch a bunch of numbers.
> 3. Copy state from the internal FDM model back to FGInterface.
> The difference is that the FDMs would have much more freedom in
> choosing what state information to copy in and out: an F16 model might
> want to publish the state of its leading-edge slats, for example, and
> a water bomber might want to let us know how much is left in its water
> tank.
> I'll have to do this incrementally because there's so much there, but
> I think it will be a big win for FlightGear -- dead code means bugs
> (like uninitialized variables), and it's also a barrier-to-entry for
> new coders trying to learn their way around.
> Comments?  I'll record Norm's vigorous objections in advance.
> All the best,
> David
> -- 
> David Megginson
> _______________________________________________
> Flightgear-devel mailing list
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Curtis Olson   Intelligent Vehicles Lab         FlightGear Project
Twin Cities    [EMAIL PROTECTED]                  [EMAIL PROTECTED]
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Flightgear-devel mailing list

Reply via email to