Feature Requests / Proposals / Ideas
|This article may require cleanup to meet the quality standards of the wiki. Please|
Occasionally, people join the FlightGear mailing lists offering to contribute to FlightGear and asking where they might start contributing, apparently often hoping for some sort of official "TODO" list or at least some sort of semi-official roadmap. Unfortunately, nothing like this exists so far for FlightGear and the closest thing to a "TODO" page, the "Goals page", has apparently not really been updated for several years.
So it is understandably hard for new community members to get a good grasp of the current development status and -progress, as well as to identify areas where FlightGear might use some improvement if they have not followed the recent mailing list discussions. In addition, many developers find it often hard to come up with suggestions for "mini projects", not because there are not any such opportunities, but rather because there does not exist any sort of general schedule or development plan. However, FlightGear itself does indeed offer a very broad range of often exciting contribution possibilities, this page is dedicated to providing a collection of such ideas that were discussed on the mailing lists. Not all of these ideas are necessarily "mini projects", rather some of these can be quite complex efforts that were simply not pursued because of the very complexity.
Also, as this is a static page and no searchable bug tracking system, we have decided to categorize these "mini projects" into groups ranging from "minor", "intermediate", "major" and "huge" to give new developers an impression of the estimated complexity of the various ideas.
Update:As of 04/2009, this page is being updated and items are moved to dedicated pages specific to the relevant FlightGear components, you may want to check out Code Cleanup to view this new category.
Please note: while this list is only meant to provide an overview of desirable short- and long-term features for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects, that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole, for example:
- atlas-FlightGear Moving Map (Atlas)
- TaxiDraw-Taxiway Layouting (TaxiDraw)
- fgsd-FlightGear Scenery Designer (FlightGear Scenery Designer)
- FlightGear Multiplayer Server (FlightGear Multiplayer Server)
- FlightGear Multiplayer Map
- TerraGear-FlightGear Scenery Compiler Suite (TerraGear)
- fgrun-FlightGear GUI Launch Wizard (Fgrun)
- FlightGear World Custom Scenery Project
- FlightGear GIS/Map Server)(MPmap)
- SimGear-FlightGear simulation kernel libs (SimGear)
- FG Live CD
- FGCOM - FlightGear Radio Comms (FGCOM)
- see also FlightGear related projects
IMPORTANT: before you actually start working on any of these efforts, it is important to subscribe to the FlightGear Developer's mailing list to discuss your plans (additionally you may also want to check out the FlightGear IRC channel ), this is extremely important in order to avoid duplicate code/efforts and a lack of coordination with regard to relevant implementation details. In addition, it's worth pointing out that this wiki page may not necessarily be "up2date" with the latest developments in FlightGear.
So please make sure to talk about your plans with other contributors and especially with the maintainer !! of the respective FlightGear component or affiliated project before starting your work, because ideas listed on this page don't necessarily match the intended/planned direction of development.
User Perceived Improvements
This is meant to provide an overview of things that users perceive as insufficient or simply inconvenient in FG, so that the developers can get an impression of issues that users would like to see eventually addressed in FlightGear. Among others, inspired by- and based on references to discussions posted by Melchior Franz to the developer's mailing list, on 02-11-2006:
- The future for Flight Gear
Evaluating the merits of such discussions should eventually enable us to determine which areas in FlightGear need to be specifically addressed in order to make FlightGear appeal to more users. Please feel free to add new entries.
The FlightGear forums are another place where users frequently come up with "wishlists" of features that they'd like to see in FlightGear:
- "Wishlist for FlightGear" Thread on FlightGear forums - 03/2009
- "Unlimited Wishlist" Thread on FlightGear forums - 02/2009
Comments related to fgfs usage for IFR flying:
(None of these threads have so far been evaluated or incorporated here)
- no version information available within GUI
- no licensing information available within GUI
- no detailed build information available within GUI (compiler, date, cflags/ldflags etc)
- no information about versions of linked dependencies within GUI
- significant initial download (>200MB) - might be a good idea to try to reduce the base package size where possible (as of 11/2008 this is being addressed by replacing rgb textures with png textures)
insufficient mac support(as of 11/2008 mac support has significantly improved, see the macflightgear project at sourceforge)
- lacking documentation (as of 11/2008 quality of up to date documentation has been significantly improved, especially due to the wiki but also due to the FlightGear forums (also see  from 06/2009).
- webpage appearance (as of 11/2008 this is still being brought up regularly in various discussions, on both the mailing lists and the forums)
- outdated FAQ
- non-intuitive joystick configuration (it has been repeatedly suggested to make joystick configuration more intuitive by providing a built-in GUI mode based on dialogs & script within FlightGear)  
- GUI does not yet expose many of FlightGear's features that are available via command line, i.e. FG isn't fully runtime configurable - many changes require a simulator restart.
no multi screen support(as of 11/2008, this is no longer true given the latest additions of multi view/camera support, see Howto: Configure Camera View Windows, however multi-screen support still needs to be configured at startup time, it cannot be set up dynamically or modified at runtime (as requested here).
- non-integrated startup wizard (requires fgrun)
significant startup times- according to forum discussions in 03/2009, this really isn't the case anymore: FlightGear can generally be expected to start up in less than 30 seconds on current hardware, even in graphically complex areas
- hardly localized UI: GUI, command line, error messages
- no localized help dialogs (basic commands, keys...)
- lacking performance: as of 03/2009 FG OSG is generally still frequently reported as being significantly slower on systems that were previously able to run fgfs with much better framerates
- does not work well on lower end hardware, this boils down to a lack of dynamic feature-scaling support as discussed on the forums on 03/2009 (also see: )
starting FG takes a whileand FG may seems to have crashed, the window (splash screen) is not redrawn-unresponsive until finally started up
- warnings and error messages are only rarely informative, i.e. "unknown exception in the mainloop"
- excessive logging (console output) may severely affect simulator performance, up to an unusable state: this is due to logging being executed in the main loop  (also frequently discussed on the forums due to the recent issues with Qnan/triangleIntersect warning messages flooding the console)- this has been brought up several times already and the effect of logging on overall simulator performance was recently (03/2009) also discussed on the jsbsim mailing list  where it lead to a discussion about potential alternatives for implementing logging support 
no realistic helicopter support(no longer true: FlightGear features now pretty realistic support for helicopter flight)
- hardly realistic scenery-missing/inappropriate textures, objects, landmarks. (this changed WRT textures already some time ago)
- not very advanced AI ATC
- no flight planning facility integrated/available (several 3rd party options)
- no support for weight & balance (and fuel) for aircraft (not true of YASim)
- currently not a suitable VFR simulator (basic vegetation modeling has been added in 2008)
- few buildings have proper night textures (this situation is somewhat improving since 01/2008)
- not fully animated 3D models (this depends on the aircraft being used)
- insufficient weather modeling and -effects (as of 11/2008, shader-based 3D clouds were added to Git/HEAD)
- non-standard GUI, not too appealing to many users
- no realistic water modelling (improving in OSG branch as of 11/2007, in fact there's very promising work going on since 01/2008)
- no moving map directly integrated in FlightGear (separate program available: atlas)
- no water effects for ocean and rivers (waves/streams)
- no nice passage of taxiways at airports (the textures aren't abound in each other)
- no integrated tutorial/ground school or learning mode (No longer true: depends on aircraft being used, tutorials are available on an aircraft-specific basis)
- no real interactive mission (scenario/adventure) support (lack of evaluation facilities to assess user's performance)
- no combat support
- no Voice ATC
- no ATC facilities for real life controllers (VATSIM like)
- no scripted demo flights that users could "play" to see a simple flight (pattern) including landing
- currently no glass cockpit support
- no support for advanced avionics that would require drawing complex images (i.e. charts) to instrument screens
- non-intuitive scenery modification and installation
- non-intuitve aircraft modification and installation
- non-intuitive aircraft panel creation (lack of GUI frontend)
- airports/runways cannot easily be modified/re-created
- non-configurable approach lighting for runways
- no blade element FDM
Create or modify existing DTDs/Schemas for the various PropertyList encoded XML file formats that FlightGear currently supports (FDM, Aircraft, GUI, Sounds etc.), so that such DTDs or Schemas can be used by XML editors and validators.Work in progress as of 03/2009  Add support for an optional framerate limiting mode (configurable, default i.e. 60-70fps), this can safe CPU cycles on many platforms (no useless idling/sleep() )available: /sim/frame-rate-throttle-hz
- Add new nimitz carrier view
- add support for non-rectangular hotspots (2D panels)
- currently, hotspots don't seem to work properly if you tilt the panel-we should try to fix this soon
switch completely to SDL (or OpenProducer?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)Git/HEAD is now based on osgviewer
- support additional transformation type to allow cropping and cutting off of textures, useful for example for things like a rose vs. arc mode HSI representation
it might be a good idea to add another routine to SimGear that can optionally check textures to match the 'power of two' requirement and emit a console warning if that's not the case. This will make it easier for developers to track down texture size related problems.also now handled by OSG
- add new command to nasal interpreter to allow playing of sound files (see mailing list discussions)
implement a "failure/crash" (limits?) subsystem that can be XML-configured with tailored values and limits for specific aircraft (i.e. max allowable speeds in various configurations, max allowable pitch up/down, roll angle, g load etc.). That way, it would be up to aircraft authors to provide such limits for their aircraft in some sort of easily modifiable XML file and FlightGear could optionally honor these values at runtime (currently, it is no problem to extend the gear or flaps at ridiculously high speeds, or crash-land an airliner and keep flying afterwards-this would certainly add a good portion of realism to FlightGear and could still be kept entirely optional).this has been basically implemented via the the limits Nasal module, see Howto: Define speed limits (there's now also failures.nas in Git) add openGL wrapper commands to the Nasal interpreter, so that users can make use of basic OpenGL calls (the primitives at least) from their scripts, optionally allow to render to a texture rather than directly to the screen, i.e. useful for things like a scripted display (CDU/moving map)Don't try to bypass the SceneGraph, instead, use proper interfaces/modelling..
- add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft (what is this supposed to mean?)
extend nasal interpreter to provide functions for loading and saving XML files directlyDONE, preferably also wrapping the functions from props_io.cxx for nasal provide support for optional use of VoIP (voice over IP) clients within FlightGear, so that such clients can be used for ATC-specific purposes (there were various discussions with plenty of good ideas mentioned on the mailing list)there's FGCOM
- add support for flight path visualization within FlightGear, possibly so that it can optionally be enabled for external or replay views ( http://www.flightgear.org/Projects/SynthVision/ http://www.cobbin.com/synthetic-vision.htm )
expose the nasal interpreter via network/telnet, so that scripts can be remotely inserted and executed.this can be basically done already by writing new code to properties and executing the code in the property
- there is a great number of aircraft in FlightGear that cannot yet be reliably reset due to problems relating to tied properties that cannot properly be untied, obviously there are various parts in FlightGear that still do not make proper use of the property tree, we should get rid of such problems eventually
Currently, TerraSync (the automatic scenery tile downloader) is a separate program, that users need to get separately, explicitly install and set up in order to be able to use it. Even more so, due to TerraSync's dependency to rsync, TerraSync users are mostly Unix/Linux users right now. However, FlightGear being a cross platform project should whenever possible try to target a maximally broad audience. That's why it would probably make sense to port the TerraSync functionality over to FG, so that scenery paging can become a native part of FlightGear itself, preferably an SGSubsystem based service that's runtime configurable via property tree variables. At http://www.samba.org/rsync/ there is a small C library available that exposes most of the rsync features, we could make the library either an additional dependency or simply make it a part of FlightGear/SimGear, so that it's automatically available to all FG users.:: Please note that this (similar to other proposals on this Wiki page) is likely just the opinion of an individual user, not much involved with the actual proceedings on this topic.Depreciated: TerraSync is now based on svn
- After each FlightGear session there are often many OpenAL related warnings displayed in the console, we should try to get rid of these wherever possible
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
provide support for cockpit light sources, so that we can realistically illuminate the cockpit as a wholethis is usually handled by specific night textures
- 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.
extend multiplayer code to add support for helicoptersit's been working for quite a while already
- it would be nice if we could port the current PID controller code over to Nasal, so that we can automatically equip AI traffic instances with nasal based autopilots (AI aircraft do no currently use FDMs)
- texture cropping support for 2D panels (see mailing list archives for discussions)
- add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details)
- Extend VRML/X3D or XGL support, so that proprietary formats such as *.ac can be entirely replaced using open standards http://en.wikipedia.org/wiki/COLLADA https://collada.org/public_forum/welcome.php (search the archives for COLLADA)
Helicopter FDM: either extend current FDM engines (i.e. yasim) to provide better support for helicopter flight dynamics, or come up with an entirely new dedicated helicopter FDM engine altogether-Support for helicopter flight simulation has been significantly improved meanwhile, and is still being worked on
- add support for integration with TTS (text to speech) engines to FlightGear (i.e. Festival), so that voice ATC becomes possible. There were various discussions about this topic on the mailing list, so you may want to search the archives if you are interested in this feature. (Note - Festival support has already been added)
Also, there is a free multi platform TTS engine called sphinx that is siginificantly more lightweight than festival, so that it may be worth considering this to make it an optional dependency for SimGear?Note 2: Sphinx is actually a speech recognizer, not a text-to-speech engine, AFAIK. --Josh 20:06, 9 May 2008 (EDT).
- add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear
- the current (2D/3D) cockpit panel code is not yet particularly efficient, would be good if someone could optimize it some more
- add support for tutorials/lessons (think, flight school) to FlightGear (see earlier mailing list discussions for details) (Note - tutorials have already been added; check the Help menu in the default C172 or Lightning)