From FlightGear wiki
Revision as of 08:32, 25 June 2010 by Martin.spott (Point at those who did the work ;-) .... feel free to revert)
Short term plans
- Bug 119
- Ensure ICAO codes longer than four digits are accepted and tolerated by all areas of the code (requested by
Martinvarious airfield layout contributors - like Gijs, Heiko, Yves)
- Add the initial version of the CDI instrument
- Add comments to the flight-plan format
- Add callsign to the flight-plan format
- Update one GA aircraft to use the CDI - eg the Seneca or Aerostar
- Create generic GPS panel switch(es) and annunciators
- Nav/GPS toggle switch and annunciator
- waypoint alert annunciator
- GPS message annunciator
- Create KLN89 instrument
- Basic physical model, with buttons, pick animations, etc
- Extend text support to allow inverted and flashing text
- Extend text support to allow hiding chunks
- Create NAV pages (except NAV4)
- Create FP0 page
- Create 'nearest' page
- Setup message manager layer
General areas I'm working on, or planning to work on
- Investigate if caching cartesian positions on FGPositioned is a good space versus time tradeoff
- Remove the _list classes as they become obsolete.
- Many of the list classes are gone now - the major remaining piece is the nav_list, which is used to support frequency-based lookups of radio navaids.
GPS / FMS / Route-planning
- Extend the GPS code to support more flight-plan functions and en-route information
- Climb/descent computations, based on some aircraft performance data
- Add proper support for special leg types, ideally equivalent to ARINC-424 path-terminators. This implies support for DME arc, heading to fix, heading until crossing radial, holding pattern and assorted other special leg behaviours.
- Create a new generic 3D instrument for the KLN89b, using Nasal and the updated GPS code
- Create a generic 3D instrument modelling a Delco Carousel INS, using the GPS as the backend
- Investigate creating a special camera/view mode and input context so a GPS, FMS or other 3D instrument can occupy most of the screen, and intercept key presses. GUI dialogs must solve the keyboard input issue already. Imagining that a click on the instrument animates the camera to a 'face on' view, and click outside the instrument returns to the previous view point.
- Add GPS precision approach support
- Define an on-disk format for defining approaches. This will likely be similar to the navdata.org / PIC-767 XML format
- Add approach and missed-approach modes to the GPS code
- Extend the route manager to allow basic flight-planning
- Generate a route using a search: VOR-VOR, airways or GPS direct.
- Thomas Forster has generic routing code for this
- Allow performance data to be specific per-aircraft
- Initially, basic information such as cruise speed, best climb rates, and so on
- Weight/balance tables
- Vspeeds computations
- Prototype a Nasal canvas API (similar to HTML5 canvas), but with support for retained primitives.
- Get primitives rendering into the existing scene
- Write a nasal driver, with appropriate C++ glue, to query waypoints
- Add realistic Mach computation to the airspeed indicator, so it can be used as Mach-meter too, and avoid panels reading /velocities/mach directly.