- Declare 'datTypeStr' and 'defaultDatFile' as public member variables
of NavDataCache ('defaultDatFile' is not *required* for this commit,
it just seems to make sense to treat both members the same way/keep
them together in the source code).
- New keys under "navigation data" in the JSON report: "fix.dat files"
and "nav.dat files".
The frequency field is always an integer, so reading it as a float to
convert it to int doesn't make sense. I've probably been confused by
field indices when I introduced this in commit a2bf424118.
This clarifies things, but shouldn't change the code behavior in any
way (unless with bogus nav.dat files, of course).
This allows using NavXP1100-formatted nav.dat from gateway.x-plane.com.
The skipped field types are:
14 Final approach path alignment point of an SBAS or GBAS approach path
15 GBAS differential ground station of a GLS
16 Landing threshold point or fictitious threshold point of an SBAS/GBAS
approach
We don't have SBAS/GBAS in Flightgear.
This change also includes duplicate detection for multiple nav.dat files
support.
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
Uses TTF fonts, and displays more information textually including
the application version and current aircraft.
Also rename FGRenderer::splashinit to preinit, as was suggested
a long time ago.
On Mac it was visible as random strings displayed in the route manager
dialog for selected SIDs and STARs.
Depends on a SimGear change which introduces SGStringValueMethods.
Based on the comments in the list I think it is better to keep the type that was originally provided as a reference, take the address of it, and store that in a ref_ptr.
Possibly the problem was never compiler related rather OSG related; I'm using 3.5.x and it appears that there are better built in type conversions compared to the target version of 3.2 that we are currently using.
Whilst debugging I had a cannot increment nextIt - because it was at end(). No idea if this could ever happen in flight but it still seems sensible to protect against it.
Use pointers to allow compilation on Linux/Mac until this is fixed properly as OSG elements should always be accessed via the reference counting mechanism.
