This makes taxiways smaller (important since at present there are so many).
Restructure the apt.dat parsing code to use a helper class instead of one long
function, and to do less work when parsing the file.
Some of these ideas come from Yon Uriarte's patches - thanks Yon.
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.
gone. This is good news, since the old query was implemented as a linear
search, sorted by Manhattan distance, and with a warning not to use the logic
at runtime. Various systems (such as the Mk-VIII) do query such data often,
eg every second.
Also gets Point3D out of Airports/simple.hxx, as a precursor to removing it
completely.
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.
Here's a patch which refactors the 'plain' GPS code into a slightly
more manageable structure - i.e breaks the large update() method into
various sub-functions. I've tested the patch with B1900d, and things
seem to work as expected, but if anyone experiences GPS weirdness
after this is committed, of course please report it.
The motivation for this was helping me learn the code - I've planning
some changes in this area, and splitting up the logic will hopefully
make that task easier.
- 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
or the unit was not serviceable. This search() routine needs to run every
iteration no matter what the power or serviceable state. If power is turned
off or the unit becomes unserviceable while a beacon sound is playing, the
search() routine still needs to be called so the sound effect can be properly
disabled.
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.
Here is a little patch that changes the behaviour of the VOR CDI and OFF-flag
for indicators like the HSI when getting outside the range of the VOR
station.
Currently, when flying at a distance between the effective_range and twice the
effective_range of a VOR station, the in-range property is computed based on
a random value, causing the OFF Flag and the CDI bar to perform an ugly
jitter.
The attached patch introduces a new property signal-quality-norm which is
computed based on the distance to the station and the range. It is 1.0 when
the distance is less than the range and decreases by 1/x^2 for distances
greater than the range leading to a signal-quality-norm of 0.25 for distances
two times the range, 0.125 for three times the range and so on.
The in-range flag is tied to a signal-quality-norm greater than 0.2 (fixed
squelch).
The CDI and GS needle deflection is multiplied with the signal-quality-norm.
The benefit is:
- Ability to animate the OFF-Flag with a smooth transition.
- CDI and GS needle deflection shows correct values when in range
(signal-quality-norm=1.0) and show some wrong indication when the range is
exceeded
- CDI and GS needle start to move, even when the OFF flag is visible
- No more jitter for flag and needles
See the new SenecaII ki525a hsi as an example at
http://www.t3r.de/fg/navpatch.jpg
The numbers on the image are:
(1) the new property signal-quality-norm
(2) distance exceeds the effective-range by 30%
(3) NAV flag has a rotation animation bound to signal-quality-norm and is
partially visible
(4) CDI is partially deflected even with NAV flag shown
This implementation better matches reality - at least, how I observed it ;-)
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)
- don't keep oodles of class member variables public (eek!)
- use ::hasValue() instead of ::getType() != SGPropertyNode::NONE
- consistency fixes and cosmetics
Thanks to Vivian Meazza for debugging this. The output deque for
FGDigitalFilter was not being kept long enough for the
doubleExponential filter. Reads from output[1] could cause a crash.
From Till:
i started the project at the end of february with a simple idea: move all
3d-model loading to the DatabasePager-thread. my first attempts looked
promising, though they were a little too optimistic (or naive?). the patch
has evolved a lot since.
currently it does the following things:
1. revive SGModelLib, move functions for xml-model-loading there
2. replace all calls to sgLoad3dModel with calls to either
SGModelLib::loadModel() or SGModelLib::loadPagedModel()
almost all models will be loaded by the DatabasePager. the few exceptions are:
your own plane, shared models in scenery, random objects, AIBallistic models.
3. simplify mode-loading functions (avoid passing around fg_root)
4. avoid supurious MatrixTransform nodes in loaded models
5. fix some memory leaks
Introduce a convenience member function in wxRadarBg for creating an
SGPropertyNode and initializing it in one step. Use this in
agRadar. This eliminates buggy behavior when the necessary radar
properties aren't defined.
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
the next airport or airport with METAR station, but about any type of
airport
- as a side effect this change makes it also 30 to 50% faster :-)
In the long run this linear search shall be replaced with a spatial
algorithm (like octree), which will be a much bigger performance gain.
Turn OPENSCENEGRAPH_MAJOR_VERSION, OPENSCENEGRAPH_MINOR_VERSION and
OPENSCENEGRAPH_PATCH_VERSION into a single number for comparisons in the
preprocessor.
together -- there's only *one* instrument node now
- don't take "random" tacan, but <tacan-source> from the instrumentation
config (or /instrumentation/tacan[0] by default)
- don't take "random" display-controls from /instrumentation/tacan[0]
- default name is now "radar" (formerly "wxradar")
- re-enable od_gauge ("owner drawn" render-to-texture instruments)
- implement radar in c++ (unlimited number of clouds/ai/mp/... objects,
better performance)
a second tacan may not be likely)
- remove some dead code
- simplify <name>/<number> handling
- let a listener watch over input props and search for new channel/frequency
- allow to set channel number as one number (rather than as single digits),
as some aircraft may prefer this (the ch53 does so); this is to be set
in /instrumentation/tacan[n]/frequencies/selected-channel[0]
