When the scenery paths change, we need to rebuild the nab-cache, since Airports/ data may have changed - e.g. someone installing custom scenery with updated ILS / thresholds.
When multiple processes (right now, multiple copies of fgfs, but potentially other users in the future) access the navcache, it can cause SQLite to return a 'locked' error, so the request should be re-tried. Add code to do this.
ThorstenB identified some cases where mod-times changing could lead to corrupted ground-cache data in the DB - handle both of these. What's still unclear is why the mod-times changes; hopefully the additional debug info will reveal this.
Tolerate Octree leaf children which have been moved outside their leaf's BBox. This is necessary since lazy-loading of ILS and threshold files can cause re-locations even during child traversal, where updating the hierarchy is very complex. Instead, simply tolerate this case, and rely on the real position data (which is correct).
When a position is modified for an in-cache FGPositioned, we need to update the runtime information too, or the Octree code may (rightly) complain that it's seeing inconsistent data. Also make the Octree check an exception throw, and verbose, so this is easier to detect in the future.
Make landings and takeoffs look more correct; tweak climb-out and touchdown phases in particular, so the turn to destination heading occurs earlier on climb out, and touchdown occurs close the GS transmitter / some distance down the runway from the beginning.
Apparently most filters are only filtering on type - we weren't running the filter body for navaid or comm-station lookups, causing weird ATIS bugs. Ensure that we actually run the filter at the point we have an FGPositioned* result.
- kHz/mHz conversion needs factor 1000 not 100
- Correctly read name for CommStations from NavCache
- Fix parsing CommStation names from apt.dat (Name
can contain spaces)
Avoid the application becoming unresponsive during nav-cache rebuilds. We still have to wait for the rebuild, but perform it on a helper thread so the main GUI thread stays responsive and hence doesn't trigger a beach-ball / 'not responding' alert. Also ensures there's some feedback (the spinner) during the rebuild operation, so users don't think we've hung.
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).
