| IMPORTANT: Some, and possibly most, of the features/ideas discussed here are likely to be affected, and possibly even deprecated, by the ongoing work on providing a property tree-based 2D drawing API accessible from Nasal using the new Canvas system available since FlightGear 2.80 (08/2012). Please see: Unifying the 2D rendering backend via canvas for further information
You are advised not to start working on anything directly related to this without first discussing/coordinating your ideas with other FlightGear contributors using the FlightGear developers mailing list or the Canvas subforum  . Anything related to Canvas Core Development should be discussed first of all with TheTom and Zakalawe. Nasal-space frameworks are being maintained by Philosopher and Hooray currently. talk page.
|
|
This is meant to become a summarized list of all feature requests/suggestions related to the FlightGear Instrumentation system, it is largely based on Feature Requests / Proposals / Ideas (where all related items were deleted) and may not be up to date with the most recent developments in CVS, your help in updating and maintaining this list is appreciated!
- Make the weather radar aware of 3D clouds [1]
- Add support for <tooltip></tooltip> tags for instrument files, so that hotspots can get assigned explanatory help strings that may be displayed at runtime (if enabled), also consider to automatically change the default cursor in order to inidicate hotspots (clickable regions) on mouse over event. Instruments that do not yet feature such tooltip sections, could simply have the action's associated name displayed
- there should also be an option to reload the aircraft's instrumentation system file (currently usually $FG_ROOT/Aircraft/Generic/generic-instrumentation.xml), also errors in these files are not properly dealt with-there are not even warnings or error messages.
- provide a GUI dialog that automatically enumerates all available instrumentation systems, so that users can easily enable/disable individual systems
- allow instrument update interval to be configurable (export to property tree)
- allow nasal code to be specified in instrument files
- Allow panel (instrument) textures to be re-loaded at runtime, mainly useful for aircraft designers
- when the aircraft's position is changed/reset, instrumentation subsystems should be suspended-slower machines (where repositioning may take several seconds) show occasionally undefined behaviour due to running (and confused) instrumentation systems
- Add support for instruments to become "zooamable", so that users can double click on an instrument in order to bring up a magnified version of the instrument for improved readability, provide crucial instrument information as tooltips, i.e. "heading 320", "IAS: 120kt", "500 fpm" etc-so that users can easily get relevant information from each instrument.
- the property tree could benefit from some restructuring, particular the properties related to /instrumentation should eventually provide input/output attributes, so that we can easily rewire them dynamically, without hardwiring any code (i.e. in order to drive a VOR/HSI from multiple sources, such as a NavCom or GPS), this is something that David Megginson proposed already 3 years ago.
- add support for vector images (SVG) to FlightGear, so that FlightGear can use vector images natively (should also reduce the base package size) SVG RESOURCES
allow to create/modify and save instruments hotspot regions directly from within FG, so that the process of creating 2D panels becomes less complicated most cockpits today are 3D?
Support for new instrument types
- add support for a TCAS implementation that honors multiplayer as well as AI traffic
- add an IRS/INS emulation for airliner-type aircraft [2]
- add a LORAN emulation for long range flight
- add a new instrumentation system to emulate a MLS (microwave landing system) (actually MLS is close to being depreciated, apart for space shuttle use)
- add support for decoding ESRI shapefiles, so that we can later on render them to a texture to be displayed on certain instruments, Dave Luff recently mentioned that he would need similar functionality for his KLN89, too.
implement a flight director (using the current PID controller code) FDs are meanwhile available in several aircraftadd support for decoding ESRI shapefiles, so that we can later on render them to a texture to be displayed on certain instruments, Dave Luff recently mentioned that he would need similar functionality for his KLN89, too. This would probably also be useful for scenery creation in general and in order to modify scenery appearance according to region specific information http://freshmeat.net/projects/shapelib/ http://sourceforge.net/projects/shpread/
- NOTE: The Scenery generation process is already several steps ahead of this proposal and uses a PostgreSQL/PostGIS database which, as an additional feature, offers Shapefiles to be exported on-the-fly. Visit: Landcover-DB Shapefile download
This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.