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.
