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).
Convert the route-manager to use a flight-plan internally, and expose
flightplan, leg and procedure data to Nasal. Move the Level-D parser
into its own file.
* Pregenerating taxiroutes could interfere with runway assignments by ATC, when conditions changed, resulting in a taxi to one runway and a takeoff from another
* A simpler solution for the "Error in Traffic record bug". This still needs some more testing, but I haven't seen any error message anymore, since changing to the current code.
* Initialize AI traffic at speed zero, this should prevent some weirdness observed under boundary conditions.
* Don't activate groundnetwork proximity detection for pushback traffic until the "ready for startup message is transmitted. this should allow sufficient time for them to reserve a route, but a little more testing still needs to be done.
* Use aircraft specific time-stamps for blocking taxiways
* Issue a stop instruction well-ahead of moving onto a blocked taxiway. This still needs some more braking power.
* Improved groundnetwork routing algorithm. Don't uncesscarily block taxiways. Instead, use a "just-in-time" blocking system. The unblocking algorithm still needs some work, but the current version is already a major improvement over the previous version.
* Some tweaks to the handover from ground to tower controller. Aircraft could refuse to take-off of even refuse to taxi onto the runway. This now seems to be solved.
* Landing AIAircraft now land properly!!!
* Fixed problems with takeoff scheduling.
* Untangled several vertical speed calculation algorithms.
* No more bent-over-backwards and jump-in-the-air AI aircraft initializations.
* Fixed intermixed target speed and target altitude during climb phase.
* Implemented beginnings of a "line up and wait" procedure.
* Tried to use actual runway elevation for calculating the decent profile.
