580
edits
Route Manager internals: Difference between revisions
Jump to navigation
Jump to search
no edit summary
mNo edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
Since most real navigation systems deal in ''legs'', not waypoints, the active leg is defined as that between <tt>waypoints[currentWpt - 1]</tt> and <tt>waypoints[currentWpt]</tt>. This is why current waypoint property is initialised to '1' on activating a route, and why activating a route adds the current location (usually the departure runway) as waypoint 0 - taken together, the user and GPS see the expected first leg from the runway to the first waypoint they entered. | Since most real navigation systems deal in ''legs'', not waypoints, the active leg is defined as that between <tt>waypoints[currentWpt - 1]</tt> and <tt>waypoints[currentWpt]</tt>. This is why current waypoint property is initialised to '1' on activating a route, and why activating a route adds the current location (usually the departure runway) as waypoint 0 - taken together, the user and GPS see the expected first leg from the runway to the first waypoint they entered. | ||
=== Activation === | |||
Activating a route currently validates any supplied data, and fills out missing data (where possible). There is the potential to hook into Nasal callbacks in this area, if people request that as a feature. As the route-manager evolves into a general flight-plan manager, activation will probably be associated with other functions as well - most importantly, with filing a flight plan with ATC system, and hence making it available over the multi-player network to human or AI ATC providers. | |||
=== Enroute data === | |||
At present, the route manager records and computes some standard data related to a 'flight' (and in the future, could generate a logbook based upon this). Notably it maintains an 'airborne' flag, and uses this to provide elapsed time enroute. Once the waypoint format is updated to store speeds better, the potential exists (in C++ or Nasal) to compute an accurate time remaining enroute value, and to estimate real progress relative to the flight plan. | |||
(This area is very much unfinished, since there's no clear benefit to doing the computations in C++, and it depends heavily on aircraft-specific performance data) | |||
=== Compatibility === | === Compatibility === | ||
To keep older aircraft and instruments work, the properties <tt>wp[0]</tt>, <tt>wp[1]</tt> and <tt>wp-last</tt> are maintained, implicitly updated to refer to the current waypoint, the next waypoint and the final waypoint. | To keep older aircraft and instruments work, the properties <tt>wp[0]</tt>, <tt>wp[1]</tt> and <tt>wp-last</tt> are maintained, implicitly updated to refer to the current waypoint, the next waypoint and the final waypoint. | ||