I've fixed a bug in FGRunways::search(aptid, tgt_hdg) which wasn't working properly for airports with multiple parallel runways. I've also firmed up and pulled out into it's own function the GetReverseRunwayNo code, and done some input checking.
As a result of fixing the above in runways.cxx, I've pulled out the
parallel implementation in the functions that set position by airport and
heading/runway number in fg_init.cxx and called the runways functions
instead.
// search for the specified apt id and runway no
bool FGRunways::search( const string& aptid, const string& rwyno, FGRunway*
r )
there was a bug, in that each runway corresponds to *two* runway numbers
(eg 01/19, 10L/28R) but the function was only checking one. I've modified
it to check the supplied number against both possible numbers for each
runway.
Secondly, I sent in the function:
// Return the runway closest to a given heading
bool FGRunways::search( const string& aptid, const int tgt_hdg,
FGRunway* runway )
a year or two ago now when I first did the ATIS. I'm not sure what I was
doing at the time (copied most of it out of fg_init.cxx) but I don't think
it's ever worked, so here's a brutal modification that does!
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
It seems that the airport database was changed some day and the End?Flags
changed from floats to strings. The database definition, though, was not
adapted and still created number entries. Reading out these flags led to
access to memory, that was never initialized. While it didn't cause crashes
during normal use, it actually caused one when I ran fgfs in ddd. Seems,
that the concerned memory region wasn't zeroed out then and hence uncovered
the bug.
Of course, the runways.mk4 database has to be re-created with the new
definitions.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
Here's an unusual patch for FlightGear -- I've created .cvsignore
files for every source directory, to make CVS output more informative.
This is especially nice when using cvs-examine from (X)Emacs to look
for changes.
from the pre-ssg / render everything ourselves days. Replaced with a
material library manager that is much better suited for working in the
context of ssg. This simplified and cleaned up a ton of old junk.
old routines from SRGP. Steve's plib/sg.h does a nice job of completely
replacing this (and since plib is already around) and is a nice clean design
so it just makes sense.
