bunch of memory leaks that had accumulated over the years. FlightGear
doesn't currently bother to destroy and recreate a YASim context, but
at least it can do so now without worry.
PistonEngine class has grown an "Engine" superclass. Some other stuff
moved around too, and I cleaned up some property naming while I was in
there. This hasn't been tested very thorougly, hopefully I didn't
break anything.
reads the /consumables tree for input to determine weights, but
places output only in /engines/engine[n]/fuel-consumed-lbs where
it gets picked up by the Nasal code.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
Link the standalone executable against the source files explicitly rather
than libYASim, as the Irix linker can't handle the unneeded dependance on
other parts of FlightGear.
