Proposals:Usability related

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

This is meant to become a summarized list of all feature requests/suggestions related to improving FlightGear's usability, 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!

  • add additional updates to the splash screen during startup, so that it is more responsive, possibly using some sort of progress bar
  • Currently, aircraft featuring multiple different startup configurations (i.e. cold/idle) have to be implemented using separate *-set.xml files for each individual situation, however it would make sense to consider a more flexible approach, where all available startup-situations are simply enumerated in the aircraft *-set.xml (i.e. as referenced separate PropertyList-encoded XML files, saved within a corresponding "situation"), so that a "loadxml" command or Nasal script could eventually overwrite the default state with the state from the desired startup situation; later on possibly with an option, allowing users to view all available startup situations and switch at runtime.
  • allow aircraft to be reloadable at runtime (could be a first big step towards making aircraft switchable at runtime!)
  • Make HUDs completely XML-configurable, so that users can easily create their own customized HUDs using arbitrary values from the property tree and generic OpenGL primitives as well as animations
  • allow placing of objects/models directly from within FG, saving coordinates
  • add support to metar code, to run update on demand (i.e. when user requests an update)
  • saving/loading flights is not very convenient, currently loading a flight requires the user to remember its path and filename, a better way would be some sort of file picker dialog, so that the user can actually browse his file system and view all files. Also, we will probably want to have some sort of standard location for saved flights, possibly in the ~/.fgfs home directory? Additionally, it may be desirable to save additional meta information with each flight (i.e. a description) so that we could show this information as some sort of preview for all flights that were saved.
  • provide a property in order to allow users to enable/disable scenery rendering at runtime, in particular this could also be useful for debugging sessions (draw-otw?)
  • aircraft (FDM & 3D model) should be re-loadable at runtime
  • it would be useful if we could add support for transformation to panel actions, so that certain actions could trigger a conditional transformation, affecting the displayed panel textures. This could for example be used in order to simulate "key presses", simply by reducing the texture's dimensions while the key is pressed.
  • add support for adding, placing and modifying scenery objects within the scenery dynamically at runtime-possibly using the property tree to enumerate all active scenery objects, so that attributes can be changed at runtime
  • add a native flight planning facility to FlightGear, so that VFR/IFR flights can be planned (loaded and saved) and optionally be passed on (filed) to the AI/ATC subsystems, this will probably require the base package to be extended with terminal approach/departure data.