Syd Adams:
I've added an update to dme.cxx /dme.hxx.
It adds a formatted KDI572-574/nm , min and kt string properties meant
for text animations for these instruments.Existing instruments will funtion
as usual, no breaks. The purpose here is to eliminate yet another nasal
workaround which usually needs to repeat some of what the code already does.
The 3 properties are empty when the dme is off (no need to check for power),
dashes when powered up but no source , out of range ,etc.
The are formatted to the KDI-572/573/574 limits ...
0-99.9/100-389 for distance to station,
0-99 minutes for time to station,
groundspeed 0-999 kt.
An upcoming commit will make the sound headers standalone, and no longer include various other headers / using std:: declarations. Prepare for this by making includes and usage of namespaces explicit.
Cache the parsed navigation and airport data in a binary file to reduce
startup times and memory consumption (since only referenced FGPositioned
elements are held in memory).
Data will be reimported when the mod-time of any input file is changed.
If a global file is changed (nav.dat, awy.dat, apt.dat, etc), the cache
will be completely rebuilt, which takes approximately 30 seconds on
moderate hardware. (Future work may reduce this).
Our nav.dat.gz seem to have many bugs regarding paired LOC/DME where
the DME is missing.
A feature has recently been introduced to always use a LOC frequency
as a DME to avoid these issues. However many LOC station do not have
a DME paired at their frequency and this behaviour might be as confusing
as having no DME where one should be.
Before we get new/bugfree navdata, a property can be set to select
the desired behaviour:
if /sim/realism/dme-fallback-to-loc is true or absent, LOC will be
treated as DME (realism is off)
if /sim/realism/dme-fallback-to-loc is false, LOC will be NOT be
treated as DME (realism is on)
- wrap the ident-generating code into a class
- move dme-in-range property into dme.cxx
- move dme-ident generation into dme.cxx
- support ident-button and volume for dme idents
- use globals.get_aircraft_position instead of properties
- some minor cleanup
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.
We have decided that hardcoded initialization of instruments and systems is
bad. So we remove them.
Hardcoded initialization is bad because it can't be overridden from config
files or from the command line. We prefer to do it through config files that
should be, eventually, aircraft specific (*-set.xml), not global
(preferences.xml).
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
Instrumentation and systems are now configureable from xml files. The two
generic configurations generic-systems.xml and generic-instrumentation.xml
configures the systems and instrumentation as it was hardcoded. You can
override the generic configurations in a similar way as you override the
autopilot configuration.
will delay it's reply by 50ms. The ground station can change it's reply delay
to trick the airborn dme unit into reporting a distance that is offset from
the true distance by some constant value. In FG we model this by subtracting
a fixed distance from the actual distance.
It is thus possible in our implimentation for the displayed distance to become
negative. This patch clamp DME distance to a minimum value of 0.00 so it can
never go negative.
- 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.
explicitely. This value has always been feet, but there were a couple places
in the code that assumed this elevation was meters. The result was that you
could park directly over the top of the Black Forest VOR (112.50) NE of KCOS
and get a dme reading of 2.5 or so. This problem is now resolved.
proceed to search for an VOR of that same frequency. On rare occasion
this search could return true with a far distant VOR and cause a small
amount of confusion.
for a little while, since it uses different properties. There are
some improvements, especially with searching and range. It also has
its own serviceable and in-range properties, independent of any
coupled VOR.
