From wiki.flightgear.org

This article is a stub. You can help the wiki by expanding it..

This article may require cleanup to meet the wiki's quality standards. Please improve this article if you can..

This list is meant to summarize all feature requests that are in one way or another related to improving the usability of FlightGear, this is largely based on Feature Requests / Proposals / Ideas and FGFS Todo. Note that this list is work and progress and many items have not yet been added here. Your help in maintaining this page is appreciated.

Contents 1 Provide detailed version and hardware information 2 Incompatible Parameters 3 New Command Line Parameters 4 GUI 5 Internationalization 6 Misc

Provide detailed version and hardware information

All of the following suggestions could be implemented by writing the data to the property tree, so that it can be easily shown by using an XML dialog so that users can more easily provide useful problem reports, also see Backwards Compatibility Initiative.

• make version information available via GUI, for fgfs binary and base package
• make OpenGL information (extensions) available via GUI
• make detailed build information available via GUI (compiler, date, cflags/ldflags etc)
• make information about versions of linked in dependencies available via GUI
• make licensing information available via GUI, for FlightGear and the active aircraft
• add support for texture based OpenGL cursors, so that we can specify arbitrary textures to be displayed as cursors. Currently, we support both, GLUT as well as SDL, so we should try to maintain compatibility with both libraries.

Incompatible Parameters

• Identify conflicting command line parameters, currently there are some situations where FlightGear can be easily crashed using either various incompatible command line parameters together or by simply ommitting required parameters. The most sensible way to approach this issue might be to add additional logics to options.xml in order to mark those parameter combinations that may be used together and those that may not (this bug can be considered to be critical because it can be easily triggered by having novice users use fgrun to start FG).

New Command Line Parameters

• Add an additional command line parameter --log-startup=file.log to automatically log all startup messages at maximum log (bulk) level until main loop is running, this will make it easier for users to provide useful debug information

GUI

• allow airports and navaids to be searched for based on country/region (state)-this would probably require some shapefile information to be added to FG, so that we can look up countries/states for lon/lat pairs.
• Provide a GUI dialog to allow users to view and select panels available for an aircraft

Internationalization

• Try to bring localizations under $FG_ROOT/Translations up to date for non-English speaking users

Misc

• double right clicking the mouse in 2D panel view mode may make more sense to scroll the panel horizontally/vertically rather than looking around in non-existent 3D cockpit, which would currently result in the 2D panel becoming invisible and unusable.

• Add startup option to completely disable OpenAL (sound) code altogether to facilitate debugging of sound related issues, should become much easier to track down sound issues that way (also see [1]).
• Either fix, or comment out non-working command line parameters from options.xml
• Possibly default to 24bpp automatically if any of the new features (i.e. 3D clouds, shadows) are enabled during startup, otherwise the new features will either not work or not look as convincingly as in 24bpp mode
• The "aircraft keys" help dialog added in 0.9.9 is a very helpful improvement for users that are new to FlightGear in general or new to a particular aircraft, however often users are also not familiar with the steps required to actually use an aircraft (how to start/fly/land it etc). Thus, it might be a good idea to extend the original idea even somewhat more and optionally allow aircraft maintainers to provide additional information about their aircraft at runtime (think about checklists). This could be a simple entry like <checklist>filename.xml</checklist> in a *-set.xml file to allow authors to refer to such an checklist that can be automatically provided at runtime (hotkeys or menu entry). Aircraft maintainers could then provide arbitrary depth of information, i.e. pre-taxiing, departure, flight/cruise, approach etc. - (already possible from the aircraft help menu, see spitfire, lightning etc, etc)