- 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.
Modifications to support querying navaid database by station ID (not just
frequency.) Some corresponding changes to testnavs.cxx to test new
functionality.
>90deg, even though src/Cockpit/radiostack.cxx has code to deal with
those; as a result, no backcourses were getting through.
This fix allows the common case of backcourses to work again, but
breaks the uncommon case of a runway using the same frequency for two
separate localizers. That special case will have to be detected
somehow. Still, this fixes more approaches than it breaks.
My last patch fixed the initialization problem only for the main branch, but
ignored the _MWERKS_ branch.
- merged the branches, only the loop head needs different treatment;
- don't access n.type before it is initialized (valgrind complaint)
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.nav.gz entry, so we would have
got a mixture of the broken one and the previous one; in case of
the first entry, that would have made nice random values ... ;-)
- move the automatic FGNav variable into the loop, so that the gets
cleanly constructed for every database entry.
- commented out the frequency min/max exploration, which isn't used at all
- updated the commented out debug output statements, which were simply
copied over from the nav* files, but never adapted (I needed them :-)
- merged the _MWERKS_ and the generic branch, only the loop head needs
different treatment
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.fix.gz entry, so we would have
got a mixture of the broken one and the previous one; (valgrind
complained ...)
- move the automatic FGFix variable into the loop, so that the gets
cleanly constructed for every database entry.
- don't access fix.type before it is initialized
- updated the commented out debug output statements (they were copied
over from navlist.cxx but never adapted)
When the loop starts, n.type is still undefined, so the while statement
depends on unitialized garbage. The input operator cares for the [End]
bracket anyway (returns if the first character is a '['). So it is safe
to check for it after reading the line and break if necessary.
are being driven from an external data source.)
Akso found and fixed a bug in the simgear that caused the time to go goofy
temporarily while scenery was being loaded.
- 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.
ends of the same runway share the same frequency. This is probably the best
we can do until we impliment some sort of operator interface to manually set
which end is active (like is done in real life.)
a) I was compairing feet vs. meter (making the range 3x too. big)
b) I was using the diameter in place of the radius (making the range an
additional 2x too big.)
c) Updated the equation for calculating range to model the weak transmitter
not being picked up at upper altitudes.
We still might need some additional tweaking, but I think we are starting to
get in the right ball park.
good as we can get" until we find a data source with actual VOR magnetic
offsets. We can use VOR offsets from some fixed date, but not all VOR's
were installed on the same day so no matter what date we pick we will be off on most of them.
FlightGear subsystems -- it isolates some of the config and #ifdef
stuff in a single place.
2. Added a new FGSubsystem interface, defined in fgfs.hxx; so far,
only FGControls implements it, but if that works, we can start letting
it propagate through the system and simplify the code in main.cxx and
fg_init.cxx (which is terrifyingly complex for anyone new to the
project).
3. Added new src/Main/fgfs_props.[hc]xx files with convenience
functions for tying properties under FlightGear.
4. Experimentally modified src/Controls/controls.cxx to tie properties
directly (rather than tying to BFI functions). I'd appreciate it if
you could get this into CVS as soon as possible, so we can see if the
template stuff causes trouble for any other platforms before I add
properties to the other subsystems.
5. Miscellaneous superficial modifications to other files.
In addition, I've made a couple of further changes:
6. Modified BFI to add support for setting the view axes (i.e. with a
joystick hat).
7. Cleaned up bfi.cxx and removed all cout statements.
