The old Mac launcher doesn’t work on Yosemite, add a tiny
Qt-based launcher inside the main process (no need to fork /
exec) which runs before the OSG window is created.
Will be merged for 3.4, hopefully with no impact on other
platforms.
Unfortunately we can’t drop loaded ones, since the in-memory structures don’t have ref-counting, and we don’t
know what AI plans may be referencing them.
- Calculate line of sight distance instead of distance over
ground
- Do a nav cache update if carrier_nav.dat.gz timestamp has
changed
- Allow comments in carrier_nav.dat.gz
- "Fix" range calculations (still does not take terrain/weather
and other influences into account)
Fix error "no known conversion for argument 1 from ‘sqlite3_int64
{aka long long int}’ to ‘PositionedID& {aka long int&}’"
(Both those types are int64, but that evidently isn't enough)
Write PID file to FG_HOME, use this to detect multiple launches.
When this situation is detected, set a marker property and place various
objects into read-only mode, such as the NavCache and TerraSync.
PID file is created using open+unlink semantics on POSIX, and
DELETE_ON_CLOSE on Windows, so it will be removed when fgfs exits,
even if killed or crashes.
- restore-defaults kills the nav cache, terra-sync cache
- new ignore-autosave option bypasses autosave.xml and leaves it
untouched (does not over-write on exit)
Move sqlite source to a separate location, and build with
an intermediate library target. This permits us to set compile options
easier, including an important one, NDEBUG, which improves performance.
Sqlite 3.8.0.2 also includes an updated query planner which may improve
some queries, to be tested.
Avoid horrible startup times for Windows users. It would be good
if someone with a Windows box, debug environment and some time could
investigate further.
Ensure all FGPositioned related functions return SGSharedPtr
instead of raw pointers to allow automatic conversion to
nasal ghosts without custom helper functions.
In preparation for adding POI data, extend the FGPositioned type enum, and the cache code to handle arbitrary POI types. (Adding more in the future is straightforward now)
Also support removing user waypoints, which was requested by the Garmin G196 developers.
This was a bogus concept, either runways have a reciprocal or not (if singled-ended), really this was simply exposing an artefact of the apt.dat encoding. Change to an API which gives what is actually wanted - the ability to extract an airport's runways without any reciprocals included.
This eliminates many conversations between ft and m and gives us runway start/end
points that are needed for many calculations. Also, this prepares the internals for
the upcoming apt.dat 850+ format that uses the metric system as well as start/end points.
When calling setILS, in-memory runways did not get updated. This showed up in the map, but also affecting a few other places. Will port this to 2.10.1 when that process starts.
Instead of deleting all table contents, actually remove the entire file on disk and re-create. This is fractionally more work, but removes any possibility of stale indices or missing deletes causing clutter after rebuilds. My suspicion is, this is cause the erratic performance some people have seen with the airports search dialog, so will back-port to 2.10.
AndersG noticed an issue when a ground-net file is edited. The DROP commands prior to the reload were wrong, fixed now to delete all ground-net entries before the file is read.
Use a RAII object to manage cache transactions, and reset queries immediately after they are done, to avoid auto-commit transactions lasting long periods of time. Re-write the commit and step logic to handle SQLITE_BUSY, with progressively increasing waits when there is DB contention (multiple processes accessing the DB).
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.
