are many recognized limitations and inefficiencies with this entire approach,
however, it's a quick and dirty way to get something working, where before
we didn't.
Here's a patch to locate the base package inside the application bundle on OS-X. The patch also disables the CPSForeground hack in boostrap.cxx, which is unnecessary if the we're running as a proper bundle rather than a Unix command line program.
Both of these changes are only compiled if OSX_BUNDLE is defined (I'm doing this via a setting in ProjectBuilder), so if you're building on OS-X using configure + make, you shouldn't see any chance.
now read the config file out of the individual aircraft directory rather
than the collective Aircraft-yasim/ directory (which is now obsolete.)
This requires a corresponding update of the base package cvs.
$FGROOT/data/Aircraft hierarchy. There could be some long term performance
concerns if a person has a *huge* collection of aircraft or a really slow
file system, but I see zero performance blip here from recursing the default
CVS tree. We should also allow the user to specify the whole path to the
-set.xml file if they don't want to recurse ... this way we could eventually
come up with an aircraft selection dialog box on the front end so the user
could manually walk the tree to the desired aircraft. There also the system
wouldn't have to search for the aircraft.
functions (note to Norman: I looked at the web page you listed and that
looks like a good idea, but I don't have time right now to go through and
debug an entirely new routine. What we have works well enough for now I hope!)
immediate end to glut, only that I'm going through and cleaning up (and
taking inventory of the actual glut dependencies in case I want to investigate
SDL.)
I have added a fledgling replay system that records flight data and control
positions during the flight.
I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set. This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.
This is the initial version so there are kinks that still need to be worked
out, please be patient.
etc.
Improved the weather system to interpolate between different
elevations and deal with boundary-layer conditions. The configuration
properties are now different (see $FG_ROOT/preferences.xml).
requested parameters to determine if this should be an on-ground vs. in-air
start. The problem was that we never defaulted the value to anything so
if we didn't match an in-air condition, we simply inherited whatever value
was there from before.
