I've done som more work on the gps instrument.
- You can now input airport-, nav- or fix-ID to select a waypoint.
- You have to specify either "airport", "nav" or "fix" in the waypoint-type
property (some fixes and navs have identical IDs).
- Formatted the time to waypoint output.
- Cleaned up and changed some propery names (wp-heading -> wp-bearing).
- I've also added a name member to the FGNav class so that the gps instrument
can get the name of the nav.
- Changed the airport name parsing in simple.cxx.
places now use sgCartToGeod() instead of rolling their own
approximation. And YASim is now using exactly the same 3D coordinate
system as the rest of FlightGear is.
I believe.) :-)
- The height of the navaid was not being properly converted to meters
before being used in our internal calculations. This caused the GS
to be placed too high.
- I was using the wrong trig function to calculate the current approach
angle of the aircraft. The distance to the GS source is the euclidean
point to point distance and represents the hypotenuse (not the ground
distance) so I need to use asin() rather than atan() to calculate the
angle.
- I was calculating distance directly to the GS source, rather than
taking into consideration that the GS transmitter projects a plane,
so I need to take the distance to the line where that plane intersectso
the ground. Previously, the way I modeled my distance calculation, the
GS transmitter effectively formed a 3 degree cone from the source. The GS
transmitter is usually placed a 100 meters or so off the runway edge so
the cone model could never bring you in to the touch down point precisely.
With these changes, the GS will bring you in precisely to the touchdown
point as defined in the default.ils.gz file (it wouldn't before.) The only
issue that remains is that it will bring you in to the elevation defined
in the ILS database, which doesn't necessarily match the DEM/SRTM terrain
at that point. Still on average, this will be a big improvement until we
can do a better job of getting the runway end elevations nailed correctly.
if the station is too far away. Instead, simply return the closest station.
All the code that searches navaids does it's own range checking anyway.
This will make the navlist query functions a bit more useful for other
types of functionality where you may need to lookup a station without
consideration of range (i.e. presetting your position relative to a navaid.)
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.
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.
