* Fixes errors selecting 'nearest' items, including duplicates
* Stable behaviour around the poles and dateline
* Decently efficient, even for 'everything within 500nm' queries
The quotes form is normally only used for headers with path relative
to the including file's path, though the standard doesn't strictly
mandate this. This is consistent with the rest of sg/fg, it makes the
code's intent clearer and helps to find headers. (And it's a few
milliseconds faster, too.)
instrument of the same name. In the future I'd prefer to rename the
instrument class instead (FGMarkerBeaconReciever?) but this is the safest
change for now.
Thanks (again) to Yon Uriarte for pointing out the problem (which seems to
affect MSVC more than gcc)
saving for beacons, but since they're surprisingly few (in nav.dat), not a
an enormous saving in real terms. The major motivation is that marker beacons
don't behave like other NavRecords for radio interaction - they have no ident,
frequency or range (in the sense that NavRecord means them).
airportList search function. At least for me (with a mutex-based SGAtomic),
large vectors of referenced-pointers is a Bad Thing - copying on vector
resize is thrashing the locks.
static FGAirport helpers. As a result, another global index goes away. Use
the helpers to avoid ugly FGPositioned down-casts in various places.
Also converts the environment/METAR code to deal with FGAirport pointers,
instead of string identifiers, and contains work-in-progress code to implement
the AirportList dialog using FGPositioned. This isn't enabled yet for various
reasons, but is the final piece to allow FGAirportList to be removed.
by frequency (which makes sense), and use the FGPositioned spatial data if
required. As a result, the marker beacon list is gone (since beacons are only
searched spatially). In the process, clean up various minor things - most
notably, all the 'airport-related' navaids (ILS, GS, LOC, and the beacons) now
store a FGRunway* instead of an airport id string. This is more precise, and
saves string allocations.
const) which were previously tricky but now easy. Make it possible not to
index certain types (used for taxiways) and exclude anonymous items from
the name index. Related to this, clean up FGRunway further - remove some public
members, and fix a dumb bug of mine, where we create reciprocal entries for
taxiways.
This should make startup (slightly) quicker, and shrinks FGRunway somewhat.
- updates how filtering is done on the various FGPositioned query functions - both spatial and ident-based.
- updates the KLN-89b / DCLGPS code to use FGPositioned for all Navaid/Airport queries.
me:
Add few include directives in globals.cxx to avoid such MSVC warning messages :
deletion of pointer to incomplete type 'FGAirportList'; no destructor called
deletion of pointer to incomplete type 'FGNavList'; no destructor called
deletion of pointer to incomplete type 'FGTACANList'; no destructor called
deletion of pointer to incomplete type 'FGFixList'; no destructor called
Attached patch updates the route-manager to use FGPositioned to search
for waypoints, instead of a manual airport / fix / navaid search. This
is good because it's now using the 'strictly closest' match, rather
than arbitrarily picking a distant fix over a nearby navaid. In my
case, the TLA VOR is significant to several EGPH procedures, but also
happens to be the ident of a fix a long, long way away.
Also updates the FGPositioned class to stop using Point3D, partly
because it's deprecated and partly because I had misunderstood the
interface and was using it wrong. For now, all FGPositioned distance
checks use SGGeodesy::inverse, which is accurate but inefficient. Once
FGPositioned queries are used for something on a hot path, I'll
probably store the cartesian position as well as the geodetic, to make
these checks fast.
Convert FGNavRecord to inherit FGPositioned. This is much more self-contained than the FGRunway change, since FGNavRecord already had good encapsulation of its state. However, it's a large diff due to moving around two nasty pieces of code - the 'align navaid with extended runway centerline' logic and the 'penalise transmitters at the opposite runway end' logic.
In general things are more readable because I've replaced the Navaid type enum, and the use of Robin's integer type codes, with switches on the FGPositioned::Type code - no more trying to recall that '6' is an outer marker in Robin's data. The creation code path is also pushed down from navdb into navrecord itself.
Convert FGRunway to be heap-based, and inherit FGPositioned. This is a large, ugly change, since FGRunway was essentially a plain struct, with no accessors or abstraction. This change adds various helpers and accessors to FGRunway, but doesn't change many places to use them - that will be a follow up series of patches. It's still a large patch, but outside of FGAirport and FGRunway, mostly mechanical search-and-replace.
An interesting part of this change is that reciprocal runways now exist as independent objects, rather than being created on the fly by the search methods. This simplifies some pieces of code that search for and iterate runways. For users who only want one 'end' of a runway, the new 'isReciprocal' predicate allows them to ignore the 'other' end. Current the only user of this is the 'ground-radar' ATC feature. If we had data on which runways are truly 'single-ended', it would now be trivial to use this in the airport loader to *not* create the reciprocal.
Here's part 2 - converting FGFix (the simplest one) to be both heap-based and inherit FGPositioned. One minor benefit from this is replacing some dangerous code in FGFixList which used to return the address of an iterator member ('&it->second'). To keep the diff a sensible size, I'm not updating the callers to use the richer FGPositioned types - i.e replacing separate lat/lon handling with SGGeod. I will make those cleanups, but in future patches.
Small patch fixing bugs I've encountered while getting the current CVS to build in MSVC.
* std::lower_bound was used with the key-type of a map, but lower_bound expects the value-type of the collection it works on, with is std::pair. MSVC seems to be more strict about this.
* Added an missing include statement.
* Replaced an rint() call with floor() (MSVC does not offer rint).
This is a little intrusive on the KLN89 code, but avoids the wasteful cloning of the airports, runways and navaids which current happens, and also combines the ugly string ordering code.
- Runways are now part of an airport, instead of a separate list
- Runways are no longer represented as a boring struct, but as a class
of their own.
-Improved runway access to unify various runway access methods.
Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w
hich allows all the parameters to be supplied. Along the way I also cleaned up t
he navrecord.hxx header, lots more header pollution has been killed.
Some long methods are no longer inline, but were all suspiciously long to meet c
ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or
mandatory in this situation) - I don't expect this to affect performance in any
way whatsoever.
The constructor addition is to support some hacking I'm doing improving the star
tup performance of the navDB by lazily loading the data, and caching it in a mor
e efficient format than text. I'm submitting this change (and probably some othe
r small tweaks in the future) since they are worthwhile as cleanups regardless o
f how my current experiments work out.
* experimental clean-up / reduction on two of the FG headers:
(I'm going to await feedback on the developers list before doing more of
these, to avoiding going over files multiple times, but in principle it
seems pretty straightforward.)
* final fixes for SG_USING_STD removal
- this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in
extensions.hxx was pulling in all of Carbon to the global namespace
- very scary. As a result, I now need to explicitly include CoreFoundation
in fg_init.cxx.
- change SG_USING_STD(x) to using std::x
SimGear change. It changes all the SG_xxxx to be the 'real' includes, and gets
rid of many #ifdef SG_HAVE_STD_INCLUDES. As an added bonus, rather than
replacing 'SG_USING_NAMESPACE(std)' with 'using namespace std', I just fixed
the small number of places to use std:: explicitly. So we're no longer polluting
the global namespace with the entire contents of std, in many cases.
There is one more 'mechanical' change to come - getting rid of SG_USING_STD(X),
but I want to keep that separate from everything else. (There's another
mechnical change, replacing <math.h> with <cmath> and so on *everywhere*, but
one step at a time)
PLETE_FUNCTIONAL from SimGear and FlightGear.
As a result, SG_HAVE_STD_INCLUDES is now *always* set, so I will get the boring
fixes for that done, but separately. I'm still auditing the other things in comp
ilers.h - there's a lot that can die now BORLAND is gone.
Attached patch adds support for multiple FIXes with the same name.
Applies to both branches.
New functionality is in query_and_offset, which now returns the FIX
closest to the passed in location.
Updated route manager to take advantage of this.
Otherwise, query functions return an unspecified member from the set
of identically named FIXes. (This was previously the one occurring
last in the database file, but I don't think anybody counted on that.)
version
* Delete ai list objects in ~ATC/AIMgr.cxx:AIMgr::~AIMgr()
* Delete colors in GUI/new_gui.cxx: NewGui::~NewGui.cxx
* Delete memory allocated to the class member "route" in
Instrumentation/gps.cxx
* Delete all globals (except a few "unsafe" ones that still cause segfaults
and need further examination.
* Use an SGShared pointer for navaid memory allocation, so that pointers to
individual navaid objects can be included safely in multiple navaid lists
AMIBO 34.973889 021.658056 ARLOS 34.625278 023.000000 1 095 195 M871-MT E-MT W-N4
... where unexpected ids follow (here E-MT W-N4). The loader didn't skipeol.
The additional values are for a first quick&dirty fix just dropped.
remove all those 41 hacks if possible. Metrowerks is under category
"Defunct software companies" in Wikipedia, its compiler was known to
work on PowerPC (which we don't support, anway, right?) and on some
Unices. The hacks are in CVS since the first commit 2002/9/10 (old
repository!) and probably were in the code long before that. Any
platform where such a broken compiler is still used, will hardly
be suitable to run fgfs at all.
I tried to make sure accessor functions which return by reference act
on const objects. also replaced some iterators with const_iterator
and a few return/pass by reference that were missed the first time
around.
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
I found that all the current users of the companion
function, findByFreq() actually did assume radians despite the misleading
comment in the .hxx and .cxx saying it's degrees. I've fixed the
comment now, and no longer change the Navaids code. The new Navaids user
in NewWaypoint() is now passing radians to the findByIdent().
Note that along with fixing the comments in the navlist.hxx, I removed
an obsolete method findByLoc() declaration (there is no definition
anywhere).
This adds a TACAN instrument to the inventory. Range and bearing are calculated
to the TACAN or VORTAC beacon selected by means of the Channel Selector in the E
quipment/Radio pull-down menu.
A TACAN beacon has also been added to the aircraft carrier Nimitz (channel #029Y
).
Attached is a patch to the airport data storage that I would like committed
after review if acceptable. Currently the storage of airports mapped by ID
is by locally created objects - about 12 Meg or so created on the stack if
I am not mistaken. I've changed this to creating the airports on the heap,
and storing pointers to them - see FGAirportList.add(...) in
src/Airports/simple.cxx. I believe that this is probably better practice,
and it's certainly cured some strange problems I was seeing when accessing
the airport data with some gps unit code. Changes resulting from this have
cascaded through a few files which access the data - 11 files are modified
in all. Melchior and Durk - you might want to test this and shout if there
are problems since the metar and traffic code are probably the biggest
users of the airport data. I've also added a fuzzy search function that
returns the next matching airport code in ASCII sequence in order to
support gps units that have autocompletion of partially entered codes.
More generally, the simple airport class seems to have grown a lot with the
fairly recent addition of the parking, runway preference and schedule time
code. It is no longer just an encapsulation of the global airport data
file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!).
My personal opinion is that we should look to just store the basic data in
apt.dat for all global airports in a simple airport class, plus globally
needed data (metar available?), and then have the traffic, AI and ATC
subsystems create more advanced airports for themselves as needed in the
area of interest. Once a significant number of airports worldwide have
ground networks and parking defined, it will be impractical and unnecessary
to store them all in memory. That's just a thought for the future though.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
for localizers. I further hacked this to support GS and DME transmitters
(although Robin's DME transmitter data doesn't convey orientation
unfortunately.)
A good elevation is critical for proper glide slope modeling. This patch
assigns the average field elevation to any ILS component that doesn't have
a valid elevation.
Also, for an ILS approach, use the GS transmitter elevation for glide slope
calculations rather than the localizer elevation, in some cases this can
make a big difference.
These change add some code that at initialization time will snap all
localizers into perfect alignment with their runways. It's my experience
that the DAFIF/FAA data reports runway and localizer headings to a level
of precision that is great for making charts, or adjusting your OBS, etc.
But the level of precision of this data can be far enough off to make you
visibly *un*aligned with the runway when the CDI needle is centered.
There are probably cases where the localizer isn't really perfectly
aligned with the runway, or intentionally misaligned to avoid obstacles
or terrain. So I have made this configurable for those that trust the
data more than I do. Just set "/sim/navdb/auto-align-localizers" to
true/false in the preferences file to turn this feature on or off in the
code.
- FG now directly supports Robin's native nav database file format.
- His latest data now separates out dme, gs, loc, and marker beacon
transmitters rather than lumping them all into a single "ILS" record.
- These new data structure changes prompted me to do some code restructuring
so that internally these different types of navaids are all kept as
separate lists and searched and handled separately.
- This structural change had a cascading affect on any code that
references or uses the nav databases. I've gone and "touched" a lot of
nav related code in a lot of places.
- As an added bonus, the new data (and code) adds DME bias so these will
all now read as they do in real life.
- Added Navaids/navdb.cxx and Navaids/navdb.hxx which provide a front
end loaders for the nav data.
- Added Navaids/navrecord.hxx which is a new "generic" nav data record.
- Removed Navaids/ils.hxx, Navaids/ilslist.cxx, Navaids/ilslist.hxx,
Navaids/mkrbeacons.cxx, and Navaids/mkrbeacons.hxx which are all now
depricated.
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.
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.
