them back and forth to the FG struture everytime I updated the flight model.
However, I have realized that this is not necessary. I just need to copy
the control positions and environmental parameters into the LaRCsim structure
before updating the FDM, then copy every thing back out into the publick FGFS
structure afterwords. This seems to solve (or at least help) a westward
drift problem some poeple had been observing.
being calculated correctly at the beginning causing the first terrain
intersection to fail, returning a ground altitude of zero, causing the plane
to free fall for one frame, until the ground altitude was corrected, but now
being under the ground we got a big bounce and the plane always ended up
upside down.
I've made some changes to the Scenery handling. Basically just tidy ups.
The main difference is in tile.[ch]xx where I've changed list<fgFRAGMENT> to
vector<fgFRAGMENT>. Studying our usage patterns this seems reasonable.
Lists are good if you need to insert/delete elements randomly but we
don't do that. All access seems to be sequential. Two additional
benefits are smaller memory usage - each list element requires pointers
to the next and previous elements, and faster access - vector iterators
are smaller and faster than list iterators. This should also help
Charlie Hotchkiss' problem when compiling with Borland and STLport.
./Lib/Bucket/bucketutils.hxx
Convenience functions for fgBUCKET.
./Simulator/Scenery/tile.cxx
./Simulator/Scenery/tile.hxx
Changed fragment list to a vector.
Added some convenience member functions.
./Simulator/Scenery/tilecache.cxx
./Simulator/Scenery/tilecache.hxx
use const fgBUCKET& instead of fgBUCKET* where appropriate.
./Simulator/Scenery/tilemgr.cxx
./Simulator/Scenery/tilemgr.hxx
uses all the new convenience functions.