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)
Replace many lingering calls to exit() from the code,
replacing most with exception throws, which can be
caught by the existing mechanisms.
Update the option-parsing code to return an explicit
value indicating what to do (e.g., exit status to return
to the shell).
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.
This logic was only ever causing bad values, all callers which care
about an altitude restriction were setting one explicitly. Thanks to
Curt for spotting it.
Route-manager was explicitly deleting its FP, which was incorrect.
Switch to correct use of SGSharedPtr to refer to flight plans.
Thanks to Roland Haeder for catching this.
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.
For now it is available in the positioned Nasal
module. FGAirport is fully ported, but especially
procedures/navaids and free functions are still
missing.
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.
KATL -> KLAX looks correct now. Great-circles that span the 180-meridian are still rendered wrong, but that's a map projection issues, which I will fix in the next few days.
This allows delegates to take action when the flightlan is cleared, and especially, for the default delegate in the route-manager to deactivate itself, and hence the GPS LEG mode - which fixes bug 940 I hope.
When leg spans more than a threshold (currently 0.5 degrees) of longitude, interpolate the actual path flown by the GPS/RM, which is a true great-circle. Previous we rendered a Rhumb line which does not agree at all. (Especially noticeable in the MapWidget and NavDisplay code, both of which use RoutePath to tesselate the route before rendering)
At large search ranges (320 or 640NM range on the 777), the search time can blow up, especially if distant airports are being loaded. Add a time-bounded spatial query, and use it, so performance stays tolerable.
When the from and to points are not on the enroute structure, check the initial and final legs for large turns (more than 90-degrees) from the overall route course. If found, kill the leg, to generate more natural route and avoid very sharp turns in the terminal area.
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).
As an opt-in API, allow clients to request partial results, with a time-bounded cutoff. Use this to keep the MapWidget responsive even when many airports are being added to the cache (e.g., zooming out or panning rapidly when zoomed out)
Disable elevation mixup for naiads, since it is introducing inconsistencies between the navdata and the scenery. (Actually it's exposing inconsistencies between the airport and navaid data, but that can't be fixed right now)
This bug was caused by the code not tolerating missing navaids / waypoints. Update logic so missing navaids degenerate to basic waypoints without problem. Also tolerate present, but empty, runway properties - don't throw an exception by looking up empty identifiers.
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).
Durk reminded me of this - when we're missing procedures data (the common case), synthesise a plausible (but possibly dangerously unrealistic) departure and approach. Will work fine for airports in gentle terrain, and likely kill you at challenging airports. You have been warned.
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)
The Flight-plan leg data computation was omitting certain data for the final waypoint, which in turn made some of the route-manager data bogus when flying the final leg. Fill in some sensible values which we can compute.
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.
In preparation for caching the groundnet in the NavCache, make taxi-nodes and parkings inherit from FGPositioned. As part of this, make them heap (as opposed to value) classes, disable their copy-constructors, remove many mutating operations, and give them real constructors.
