David, 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. Curt. 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 > [EMAIL PROTECTED] > > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
