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.
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).
rwyprefs.xml sometimes specify runways without a leading '0', which
confuses the ident lookup. Print a message, and fix up such idents at
load time, so '8' -> '08', '3L' -> '03L' which matches our internal
scheme.
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.
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.
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).
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.
to avoid repeating identical NavCache/SQL queries. Also ensures we're
not using multiple FGAirport instances for an airport - each triggering
identical queries to pull in airport data.
Airports by ICAO ID are requested very frequently at run-time, so caching
significantly boosts performance.
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.
- 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)
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.
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).
