FlightGear wiki - User contributions [en]

Feature Requests / Proposals / Ideas

2006-11-29T17:49:51Z

AJ: /* Intermediate Requests */

Occassionally, 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.

Please note: while this list is only meant to provide an overview of desirable short- and long-term goals for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects (i.e. [http://sourceforge.net/projects/fgrun fgrun], [http://sourceforge.net/projects/fgsd fgsd], [http://sourceforge.net/projects/taxidraw taxidraw], [http://www.terragear.org terragear], [http://www.simgear.org simgear]), that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole.

'''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, this is extremely important in order to avoid duplicate code/efforts and a lack of coordination with regard to relevant implementation details, so please make sure to talk about your plans with other contributors before starting your work!'''

{|
|__TOC__
|}

== General Ideas ==

* Set up a wiki at FlightGear.org, so that regular backups can be easily done. Also, the wiki could possibly write/export its pages directly into the CVS directory of $FG_ROOT/Docs
* set up a full set of automatically created DoxyGen documentation at FlightGear.org, possibly using a monthly/weekly update cycle for the CVS version, this would require approx. 500MB of webspace, could be done using a cron job
* consider distributing the FlightGear CD/DVD as a linux boot cd/dvd (i.e. knoppix), so that users can optionally try to easily boot easily into linux in order to start FG
* consider setting up a non-profit organization for FlightGear, so that donations may become tax-deductible
* consider setting up a subversion server, so that we can stop using CVS-subversion can easily import an entire repository, preserving all revision history etc.
* http://scan.coverity.com/ - offers free code checks to open source projects
* At http://freshmeat.net/projects/installbase/ or more specifically at http://installbase.sourceforge.net/main.shtml there's an open source cross platform GUI installer available that may be an interesting option for creating binary FlightGear installers. The whole thing is based on TK and works with statically precompiled interpreters that serve as stub for an ASCII config file that contains all relevant information for cross platform setups,including a tarball of installation specific files for each platform. The installbase installer is very convenient and works entirely with a very powerful GUI frontend that allows you to set up, test and export installer packages. Given that the final config file is ASCII, it would probably be quite possible to simply put all this into some sort of Makefile, so that the whole package creation could be handled automatically, i.e. by doing something like "make win32-package" or "make macos-package". The [http://installbase.sourceforge.net/screenshots.shtml screenshots] look very convincing. That way, all FlightGear binaries could easily use an identical installer and configuration wizard.
* Set up a cross compiler version of gcc at flightgear.org to automatically create binary packages (releases) of FlightGear for platforms such as Win32 or MacOS. FYI: all registered sourceforge developers can access the so-called "compile farm" which is comprised of a number of different hosts/platforms including various compilers, on the AMD64 Opteron machines there are also various Win32 cross-compilers installed under /var/scratch/tools/bin -if you are interested in using the sourceforge services to create FlightGear binaries, check out the [http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1 sourceforge docs] --[[User:FlightZilla|FlightZilla]] 07:53, 18 June 2006 (EDT)
* import the complete DAFIF data into an SQL database, including Robin Peel's database, this would offer the possibility to provide a web based interface to the corresponding data, i.e. in order to allow users to easily provide corrections or augmentations for existing data. Eventually, this could probably also be useful for the landcover DB anyway?--[[User:82.83.154.229|82.83.154.229]] 09:31, 18 June 2006 (EDT)

== 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:

* http://digg.com/software/Awesome_Free_Flight_Sim
* http://www.macupdate.com/info.php/id/16997
* http://happypenguin.org/show?Flight%20Gear%20Flight%20Sim
* http://www.winfuture.de/news,23149.html
* http://nickles.softonic.de/ie/47000/Flightgear

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.

* non-intuitive scenery modification and installation
* non-intuitve aircraft modification and installation
* non-intuitive joystick configuration
* non-intuitive aircraft panel creation (lack of GUI frontend)
* non-integrated startup wizard (requires fgrun)
* lacking performance
* significant startup times
* currently no glass cockpit support
* lacking documentation
* insufficient mac support
* webpage appearance
* not fully animated 3D models
* insufficient weather modelling and -effects
* non-standard GUI, not too appealing to many users
* outdated FAQ
* no integrated tutorial/ground school or learning mode (No longer true)
* no realistic helicopter support (no longer true)
* no multi screen support
* airports/runways cannot easily be modified/re-created
* non-configurable approach lighting for runways
* no blade element FDM
* GUI does not yet expose many of FlightGear's features that are available via command line
* no real scenario/adventure support
* no combat support
* hardly realistic scenery-missing/inappropriate textures, objects, landmarks.
* no realistic water modelling
* hardly localized UI: GUI, command line, error messages
* no localized help dialogs (basic commands, keys...)
* no Voice ATC
* not very advanced AI ATC
* no moving map directly integrated in FlightGear
* warnings and error messages are only rarely informative
* no flight planning facility integrated/available (several 3rd party options)
* no scripted demo flights that users could "play" to see a simple flight (pattern) including landing
* no ATC facilities for real life controllers (VATSIM like)
* does not work well on lower end hardware
* starting FG takes a while and FG seems to have crashed, the window (splash screen) is not redrawn-unresponsive until finally started up
* no water effects for ocean and rivers (waves/streams)
* no support for weight & balance (and fuel) for aircraft (not true of YASim)
* currenlty not a suitable VFR simulator
* few buildings have proper night textures
* significant initial download (>100MB) - might be a good idea to try to reduce the base package size where possible

== Feature Requests ==
=== Minor Requests ===

* 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.
* 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() )
* Add new nimitz carrier view
* the menubar should be reloadable
* 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.
* 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 additional pitch mode to autopilot dialog for climb/descent gradients, so that users can specify a gradient that is automatically maintained (i.e. a glidepath)
* 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

=== Intermediate Requests ===
* switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)
* 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.
* add new command to nasal interpreter to allow playing of sound files (see mailing list discussions)
* add possibility to re-init the nasal interpreter, so that it reloads any modified script files
* there are still plenty of old "pseudo-subsystems" that do not yet make use of SGSubsystem, it would be good if subsystems such as the GUI subsystem could be ported to become native SGSubsystems
* 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).
* provide a GUI dialog that automatically enumerates all available instrumentation systems, so that users can easily enable/disable individual systems
* 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.
* provide runtime configurable friction coefficients for runways to simulate contaminated runways (dirt, water, snow/ice) at runtime and export corresponding properties to property tree
* extend weather modelling subsystem to simulate weather features such as thermals, gusts or windshear more extensively and realistically. This would also come in very handy for sailplane/gilder modelling which is currently not yet satisfactorily simulated.
* 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)
* add support for registration labels to be drawn at runtime to an aircraft's tail-possibly using ImageMagick (or maybe just PLIB's FNT library) and rendering the text to a texture, so that airplanes can optionally show proper registrations (taken form the property tree) in multiplayer or AI traffic scenarios
* 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
* extend sgsubsystem class to optionally publish each subsystem's actual update interval (determined at runtime) to a specific property, this will allow simple nasal scripts to deal with any issues (i.e. show warnings) if a certain subsystem is not, or cannot be run at a certain update interval. As more and more complex subsystems are getting added to FlightGear this would add the possibility for automatic detection of subsystems that cannot be run at proper update intervals, i.e. due to old/slow hardware. Ultimately, this could also make it easier to add auto-scaling support to FlightGear.
* 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]]
* add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft
* extend nasal interpreter to provide functions for loading and saving XML files directly, 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)
* merge AI and ATC code so that both work properly with each other
* add support for a TCAS implementation that honors multiplayer as well as AI traffic
* 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.
* implement a flight director (using the current PID controller code)
* provide support for force-feedback input hardware and/or motion platforms
* for the development of more advanced avionics we will require a terminal procedures database (i.e. SIDs & STARs), this should be added to the base package, so that we can provide the corresponding data within FlightGear, its availability (memory consumption!) could be made optional using a corresponding property or new special instrument type.
* allow nasal code to be specified in instrument files
* allow nasal scripts in AI object XM files, so that nasal code can move AI objects along predefined routes
* allow instrument update interval to be configurable (export to property tree)
* strictly enforce usage of enum fg_nav_types in all FG code to isolate/protect other code from changes in the underlying navdb format
* add additional updates to the splash screen during startup, so that it is more responsive, possibly using some sort of progress bar
* allow aircraft to be reloadable at runtime (could be a first big step towards making aircraft switchable at runtime!)
* 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)
* the replay system is very nice, but it is not very convenient to use: improve usability
* add texture paging support to singear/flighgear
* allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
* implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
* 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.
* 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, explicitly install and set up in order to be able to use it. Even moreso, 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 it 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.
* 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
* 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.
* 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
* 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 whole
* add an IRS/INS emulation for airliner-type aircraft
* add a LORAN emulation for long range flight
* 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.
* 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.
* allow to create/modify and save instruments hotspot regions directly from within FG, so that the process of creating 2D panels becomes less complicated
* add a new instrumentation system to emulate a MLS (microwave landing system)
* extend multiplayer code to add support for helicopters
* multiplayer: maintain a serverside list of aircraft that may connect to the server, this could be useful to prevent certain types of aircraft (i.e. UFO, santa, ogel etc) from appearing in more serious settings, likewise we could disallow certain aircraft with unfinished fdm
* maintain FDM "plausibility" values for all legitimate aircraft, so that the server can determine if a specific aircraft is able to achieve a certain performance (i.e. climb/descent,airspeed). This could be based on 10-20 figures for each aircraft, so that the server can interpolate between different situations and determine if the provided data is still accurate or not. Eventually this would also allow server admins to run certain 3D models only with certain FDMs.
* 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
* add support for pilot-controlled runway lighting
* 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.
* add support for particle animations (i.e. smoke, sparks etc)
* improve visual weather effects (fog, rain, snow etc)
* currently, the replay system doesn't take animations, sub models and sounds into account
* add support to allow multiple views to be rendered simulatenously, so that we display arbitrary views within other views
* extend the multiplayer subsystem to support the DIS protocol
* consider adding VBO support
* allow replay flights to be resumed manually (this would be useful for instruction-like scenarios)
* use imposter objects for sky & distant scenery
* add support for multitexturing/texture blending
* allow custom views to be specified based on positions taken from scenery objects or the navaids db, i.e. to create scripted views that are situated at apron/taxiway/runway XX using configurable offset YY, at altitude ZZ

=== Major Requests ===
* Replace current PLIB/PUI based GUI bindings with bindings for a more feature-rich GUI (possibly SDL based) [[OpenGL_GUI_RESOURCES]]
* http://chromium.sourceforge.net/
* texture cropping support for 2D panels (see mailing list archives for discussions)
* add support for enhanced water modeling, so that we can start implementing water aircraft with floats etc.
* when aircraft are very low, the terrain/scenery looks only rarely convincing due to the fact that flat textures are applied to surfaces in order to illustrate vegetation, however this works only properly for higher altitudes, so it would be desirable if we could add support for dynamic vegetation modeling, so that grass, trees and other plants are dynamically created within a certain proximity.
* the navdb should eventually become a true SGSubsystem, it needs some serious revamping.
* basically all subsystems should be fully "suspend-able" and "reinit-able" at runtime, there are currently various subsystems that will consume CPU cycles even though they are not in fact necessarily required, affecting FlightGear's performance negatively. This is particularly the case for non-SGSubsystem based systems.
* the navdb & airports wrappers should eventually be moved to simgear, there are meanwhile various programs (i.e. atlas,taxidraw,fgsd,fgrun) relying on the very same code-using the copy&paste approach. It would be much cleaner and better if simgear coul provide the corresponding functionality. That way, we would also only have to fix any issues (i.e. changes in Robin Peel's db format) on ONE central place.
* add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details)
* The current Property Tree code is not thread safe, sooner or later it may come in handy if this feature was added
* Meanwhile, FlightGear has become a pretty monolothic piece of software, in the long run it would be desirable if the code could become somewhat more modularized and structured, eventually this should also make it easier for new contributors to get started.
* 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. This would probably also be useful for scenery creation in general. http://freshmeat.net/projects/shapelib/ http://sourceforge.net/projects/shpread/
* 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
* factor out weather subsystem, so that weather can be set up for specific locations (initially mainly airports and navaids (using radials, distances), later on possibly also landmarks and towns/areas), i.e. to provide weather for departure airport, enroute, destination and alternate. A good approach might be to simply convert the current weather subsystem into a METAR server, that way FlightGear could optionally provide its own local METAR server that can be easily set up using some sort of GUI (or the property tree) and still be easily polled for current weather using the METAR code that is already in place. This approach would also make it very feasible to interoperate with a multiplayer server.
* 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?
* add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear
* 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
* eventually, it may become desirable to add unit testing support to those FlightGear subsystems/components that can be considered stable and that are thus unlikely to change significantly anytime soon, that way it should become much easier to track development problems early.
* implement support for dynamic LOD customization for aircraft at runtime, so that the detail level of aircraft models can be dynamically reduced/increases (the poly count, that is) on demand, currently multiplayer aircraft need to have their own separate (reduced) 3D model, so it would probably make sense to think about implementhing some sort of runtime configurable LOD algorithm that can return any 3D model with a customized detail level. This has been discussed various times on the mailing list (and is currently being discussed again).
* 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)'''
* Factor out AI traffic code in order to make it work with the multiplayer client code: incorporate the AI traffic system with the multiplayer system so that the AI traffic system becomes a special multi-aircraft client and can thus sort of 'inject' AI aircraft/traffic instances into multiplayer servers. Next abstract out the current AI traffic system so that it can be run as a standalone executable, that way multiplayer servers could optionally also run their own dedicated AI traffic clients that can connect to a multiplayer server (authentication permitting) in order to inject AI traffic (multiple AI aircraft instances) into a multiplayer server. Eventually, this would address issues concerning the discrepancy between multiplayer clients running with enabled AI traffic scenarios that are currently not yet synchronized. Ultimately, this would add the possibility to have server-side (AI traffic) scenarios for all connected multiplayer clients. Export all AI/multiplayer traffic nodes to local property tree, using a configurable range.
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim) would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily.
* Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view.
* Currently, roads and rivers do not yet have a realistic curvature when their direction changes, rather there are pretty visible corners, it would be nice if someone could look into this in order to come up with a method to smoothen the directional transistion, so that a realistic curve can be rendered
* Extend the RenderTexture class to provide support for Frame Buffer Object based rendering to a texture, this is a relatively new way to support rendering to texture for platforms or OpenGL (driver) implementations that do not offer native RTT support, as it is the case for many older Linux cards: http://openvidia.sourceforge.net/fbo.shtml

=== Huge Requests ===
* factor out current plib based scenegraph to allow integration with other scenegraphs, such as OSG (OpenSceneGraph). Adding support for OpenSceneGraph to FlightGear would also add support for mult-head displays, multiple rendering contexts as well as distributed rendering. If you are interested in this idea please make sure to search the mailing list archives at http://www.flightgear.org for "OpenSceneGraph", "OSG", "SSG" to get an impression of previous discussions about this topic.
* factor out scenery system to allow integration with other scenery systems (see mailing list discussions)
* factor out terrain system to allow integration with alternative terrain engines (see mailing list discussions)
* revamp scenery/terrain system in order to favor a non-tile based approach (see mailing list discussions concerning the use of quadtrees,octrees,kd-trees: http://www.sdss.jhu.edu/htm/index.html
* add support to optionally favor dynamic airport/runway creation at runtime over the pre-tesselated approach that is currently used, this would allow users to easily modify airports, possibly even at runtime-without having to re-create the corresponding scenery tile to make the changes take effect
* implement algorithms to feature dynamically adjustable (C)LOD/resolution for terrain data, as plans are being discussed to increase the resolution depth for upcoming scenery builds (SRTM), this would probably come in handy to allow users to adjust the terrain detail level according to their needs and hardware specs, otherwise we would probably face significant performance hits on lower end hardware, that is why it would make sense to allow users to configure the terrain resolution they'd like to use at runtime (i.e. 70% rather than 100% terrain features)
* Have FlightGear become its own IDE (integrated development environment) by allowing users to create and modify instruments directly within FlightGear, this would probably require a revamped (or more feature-rich) GUI toolkit than PLIB's PUI. Eventually, it would be desirable to allow users to pick instruments from the base package and place them at runtime on panels. For the majority of users this would be an essential steps towards improved usability.
* add support for automatically created scenery objects to populate the scenery dynamically at runtime (autogen-like), this could add quite a portion of realism to FlightGear without having to model scenery manually using fgsd, yet one could still use fgsd for areas where people are willing to contribute. All other scenery should by default be populated using autogen buildings and objects (references: http://www.infinitylab.com.au/research/prototypes.htm and http://vterrain.org/Culture/BldCity/procedural.html and http://pcity.sourceforge.net/ )

Feature Requests / Proposals / Ideas

2006-11-29T17:47:17Z

AJ: /* User Perceived Improvements */

Occassionally, 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.

Please note: while this list is only meant to provide an overview of desirable short- and long-term goals for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects (i.e. [http://sourceforge.net/projects/fgrun fgrun], [http://sourceforge.net/projects/fgsd fgsd], [http://sourceforge.net/projects/taxidraw taxidraw], [http://www.terragear.org terragear], [http://www.simgear.org simgear]), that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole.

'''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, this is extremely important in order to avoid duplicate code/efforts and a lack of coordination with regard to relevant implementation details, so please make sure to talk about your plans with other contributors before starting your work!'''

{|
|__TOC__
|}

== General Ideas ==

* Set up a wiki at FlightGear.org, so that regular backups can be easily done. Also, the wiki could possibly write/export its pages directly into the CVS directory of $FG_ROOT/Docs
* set up a full set of automatically created DoxyGen documentation at FlightGear.org, possibly using a monthly/weekly update cycle for the CVS version, this would require approx. 500MB of webspace, could be done using a cron job
* consider distributing the FlightGear CD/DVD as a linux boot cd/dvd (i.e. knoppix), so that users can optionally try to easily boot easily into linux in order to start FG
* consider setting up a non-profit organization for FlightGear, so that donations may become tax-deductible
* consider setting up a subversion server, so that we can stop using CVS-subversion can easily import an entire repository, preserving all revision history etc.
* http://scan.coverity.com/ - offers free code checks to open source projects
* At http://freshmeat.net/projects/installbase/ or more specifically at http://installbase.sourceforge.net/main.shtml there's an open source cross platform GUI installer available that may be an interesting option for creating binary FlightGear installers. The whole thing is based on TK and works with statically precompiled interpreters that serve as stub for an ASCII config file that contains all relevant information for cross platform setups,including a tarball of installation specific files for each platform. The installbase installer is very convenient and works entirely with a very powerful GUI frontend that allows you to set up, test and export installer packages. Given that the final config file is ASCII, it would probably be quite possible to simply put all this into some sort of Makefile, so that the whole package creation could be handled automatically, i.e. by doing something like "make win32-package" or "make macos-package". The [http://installbase.sourceforge.net/screenshots.shtml screenshots] look very convincing. That way, all FlightGear binaries could easily use an identical installer and configuration wizard.
* Set up a cross compiler version of gcc at flightgear.org to automatically create binary packages (releases) of FlightGear for platforms such as Win32 or MacOS. FYI: all registered sourceforge developers can access the so-called "compile farm" which is comprised of a number of different hosts/platforms including various compilers, on the AMD64 Opteron machines there are also various Win32 cross-compilers installed under /var/scratch/tools/bin -if you are interested in using the sourceforge services to create FlightGear binaries, check out the [http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1 sourceforge docs] --[[User:FlightZilla|FlightZilla]] 07:53, 18 June 2006 (EDT)
* import the complete DAFIF data into an SQL database, including Robin Peel's database, this would offer the possibility to provide a web based interface to the corresponding data, i.e. in order to allow users to easily provide corrections or augmentations for existing data. Eventually, this could probably also be useful for the landcover DB anyway?--[[User:82.83.154.229|82.83.154.229]] 09:31, 18 June 2006 (EDT)

== 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:

* http://digg.com/software/Awesome_Free_Flight_Sim
* http://www.macupdate.com/info.php/id/16997
* http://happypenguin.org/show?Flight%20Gear%20Flight%20Sim
* http://www.winfuture.de/news,23149.html
* http://nickles.softonic.de/ie/47000/Flightgear

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.

* non-intuitive scenery modification and installation
* non-intuitve aircraft modification and installation
* non-intuitive joystick configuration
* non-intuitive aircraft panel creation (lack of GUI frontend)
* non-integrated startup wizard (requires fgrun)
* lacking performance
* significant startup times
* currently no glass cockpit support
* lacking documentation
* insufficient mac support
* webpage appearance
* not fully animated 3D models
* insufficient weather modelling and -effects
* non-standard GUI, not too appealing to many users
* outdated FAQ
* no integrated tutorial/ground school or learning mode (No longer true)
* no realistic helicopter support (no longer true)
* no multi screen support
* airports/runways cannot easily be modified/re-created
* non-configurable approach lighting for runways
* no blade element FDM
* GUI does not yet expose many of FlightGear's features that are available via command line
* no real scenario/adventure support
* no combat support
* hardly realistic scenery-missing/inappropriate textures, objects, landmarks.
* no realistic water modelling
* hardly localized UI: GUI, command line, error messages
* no localized help dialogs (basic commands, keys...)
* no Voice ATC
* not very advanced AI ATC
* no moving map directly integrated in FlightGear
* warnings and error messages are only rarely informative
* no flight planning facility integrated/available (several 3rd party options)
* no scripted demo flights that users could "play" to see a simple flight (pattern) including landing
* no ATC facilities for real life controllers (VATSIM like)
* does not work well on lower end hardware
* starting FG takes a while and FG seems to have crashed, the window (splash screen) is not redrawn-unresponsive until finally started up
* no water effects for ocean and rivers (waves/streams)
* no support for weight & balance (and fuel) for aircraft (not true of YASim)
* currenlty not a suitable VFR simulator
* few buildings have proper night textures
* significant initial download (>100MB) - might be a good idea to try to reduce the base package size where possible

== Feature Requests ==
=== Minor Requests ===

* 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.
* 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() )
* Add new nimitz carrier view
* the menubar should be reloadable
* 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.
* 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 additional pitch mode to autopilot dialog for climb/descent gradients, so that users can specify a gradient that is automatically maintained (i.e. a glidepath)
* 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

=== Intermediate Requests ===
* switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)
* 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.
* add new command to nasal interpreter to allow playing of sound files (see mailing list discussions)
* add possibility to re-init the nasal interpreter, so that it reloads any modified script files
* there are still plenty of old "pseudo-subsystems" that do not yet make use of SGSubsystem, it would be good if subsystems such as the GUI subsystem could be ported to become native SGSubsystems
* 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).
* provide a GUI dialog that automatically enumerates all available instrumentation systems, so that users can easily enable/disable individual systems
* 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.
* provide runtime configurable friction coefficients for runways to simulate contaminated runways (dirt, water, snow/ice) at runtime and export corresponding properties to property tree
* extend weather modelling subsystem to simulate weather features such as thermals, gusts or windshear more extensively and realistically. This would also come in very handy for sailplane/gilder modelling which is currently not yet satisfactorily simulated.
* 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)
* add support for registration labels to be drawn at runtime to an aircraft's tail-possibly using ImageMagick (or maybe just PLIB's FNT library) and rendering the text to a texture, so that airplanes can optionally show proper registrations (taken form the property tree) in multiplayer or AI traffic scenarios
* 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
* extend sgsubsystem class to optionally publish each subsystem's actual update interval (determined at runtime) to a specific property, this will allow simple nasal scripts to deal with any issues (i.e. show warnings) if a certain subsystem is not, or cannot be run at a certain update interval. As more and more complex subsystems are getting added to FlightGear this would add the possibility for automatic detection of subsystems that cannot be run at proper update intervals, i.e. due to old/slow hardware. Ultimately, this could also make it easier to add auto-scaling support to FlightGear.
* 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]]
* add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft
* extend nasal interpreter to provide functions for loading and saving XML files directly, 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)
* merge AI and ATC code so that both work properly with each other
* add support for a TCAS implementation that honors multiplayer as well as AI traffic
* 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.
* implement a flight director (using the current PID controller code)
* provide support for force-feedback input hardware and/or motion platforms
* for the development of more advanced avionics we will require a terminal procedures database (i.e. SIDs & STARs), this should be added to the base package, so that we can provide the corresponding data within FlightGear, its availability (memory consumption!) could be made optional using a corresponding property or new special instrument type.
* allow nasal code to be specified in instrument files
* allow nasal scripts in AI object XM files, so that nasal code can move AI objects along predefined routes
* allow instrument update interval to be configurable (export to property tree)
* strictly enforce usage of enum fg_nav_types in all FG code to isolate/protect other code from changes in the underlying navdb format
* add additional updates to the splash screen during startup, so that it is more responsive, possibly using some sort of progress bar
* allow aircraft to be reloadable at runtime (could be a first big step towards making aircraft switchable at runtime!)
* 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)
* the replay system is very nice, but it is not very convenient to use: improve usability
* add texture paging support to singear/flighgear
* allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
* implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
* 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.
* 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, explicitly install and set up in order to be able to use it. Even moreso, 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 it 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.
* 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
* 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.
* 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
* aircraft (FDM & 3D model) should be re-loadable at runtime
* provide support for an instrument transformation that emulates instrument illumination
* provide support for cockpit light sources, so that we can realistically illuminate the cockpit as a whole
* add an IRS/INS emulation for airliner-type aircraft
* add a LORAN emulation for long range flight
* 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.
* 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.
* allow to create/modify and save instruments hotspot regions directly from within FG, so that the process of creating 2D panels becomes less complicated
* add a new instrumentation system to emulate a MLS (microwave landing system)
* extend multiplayer code to add support for helicopters
* multiplayer: maintain a serverside list of aircraft that may connect to the server, this could be useful to prevent certain types of aircraft (i.e. UFO, santa, ogel etc) from appearing in more serious settings, likewise we could disallow certain aircraft with unfinished fdm
* maintain FDM "plausibility" values for all legitimate aircraft, so that the server can determine if a specific aircraft is able to achieve a certain performance (i.e. climb/descent,airspeed). This could be based on 10-20 figures for each aircraft, so that the server can interpolate between different situations and determine if the provided data is still accurate or not. Eventually this would also allow server admins to run certain 3D models only with certain FDMs.
* 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
* add support for pilot-controlled runway lighting
* 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.
* add support for particle animations (i.e. smoke, sparks etc)
* improve visual weather effects (fog, rain, snow etc)
* currently, the replay system doesn't take animations, sub models and sounds into account
* add support to allow multiple views to be rendered simulatenously, so that we display arbitrary views within other views
* extend the multiplayer subsystem to support the DIS protocol
* consider adding VBO support
* allow replay flights to be resumed manually (this would be useful for instruction-like scenarios)
* use imposter objects for sky & distant scenery
* add support for multitexturing/texture blending
* allow custom views to be specified based on positions taken from scenery objects or the navaids db, i.e. to create scripted views that are situated at apron/taxiway/runway XX using configurable offset YY, at altitude ZZ

=== Major Requests ===
* Replace current PLIB/PUI based GUI bindings with bindings for a more feature-rich GUI (possibly SDL based) [[OpenGL_GUI_RESOURCES]]
* http://chromium.sourceforge.net/
* texture cropping support for 2D panels (see mailing list archives for discussions)
* add support for enhanced water modeling, so that we can start implementing water aircraft with floats etc.
* when aircraft are very low, the terrain/scenery looks only rarely convincing due to the fact that flat textures are applied to surfaces in order to illustrate vegetation, however this works only properly for higher altitudes, so it would be desirable if we could add support for dynamic vegetation modeling, so that grass, trees and other plants are dynamically created within a certain proximity.
* the navdb should eventually become a true SGSubsystem, it needs some serious revamping.
* basically all subsystems should be fully "suspend-able" and "reinit-able" at runtime, there are currently various subsystems that will consume CPU cycles even though they are not in fact necessarily required, affecting FlightGear's performance negatively. This is particularly the case for non-SGSubsystem based systems.
* the navdb & airports wrappers should eventually be moved to simgear, there are meanwhile various programs (i.e. atlas,taxidraw,fgsd,fgrun) relying on the very same code-using the copy&paste approach. It would be much cleaner and better if simgear coul provide the corresponding functionality. That way, we would also only have to fix any issues (i.e. changes in Robin Peel's db format) on ONE central place.
* add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details)
* The current Property Tree code is not thread safe, sooner or later it may come in handy if this feature was added
* Meanwhile, FlightGear has become a pretty monolothic piece of software, in the long run it would be desirable if the code could become somewhat more modularized and structured, eventually this should also make it easier for new contributors to get started.
* 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. This would probably also be useful for scenery creation in general. http://freshmeat.net/projects/shapelib/ http://sourceforge.net/projects/shpread/
* 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
* factor out weather subsystem, so that weather can be set up for specific locations (initially mainly airports and navaids (using radials, distances), later on possibly also landmarks and towns/areas), i.e. to provide weather for departure airport, enroute, destination and alternate. A good approach might be to simply convert the current weather subsystem into a METAR server, that way FlightGear could optionally provide its own local METAR server that can be easily set up using some sort of GUI (or the property tree) and still be easily polled for current weather using the METAR code that is already in place. This approach would also make it very feasible to interoperate with a multiplayer server.
* 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?
* add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear
* 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
* eventually, it may become desirable to add unit testing support to those FlightGear subsystems/components that can be considered stable and that are thus unlikely to change significantly anytime soon, that way it should become much easier to track development problems early.
* implement support for dynamic LOD customization for aircraft at runtime, so that the detail level of aircraft models can be dynamically reduced/increases (the poly count, that is) on demand, currently multiplayer aircraft need to have their own separate (reduced) 3D model, so it would probably make sense to think about implementhing some sort of runtime configurable LOD algorithm that can return any 3D model with a customized detail level. This has been discussed various times on the mailing list (and is currently being discussed again).
* 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)'''
* Factor out AI traffic code in order to make it work with the multiplayer client code: incorporate the AI traffic system with the multiplayer system so that the AI traffic system becomes a special multi-aircraft client and can thus sort of 'inject' AI aircraft/traffic instances into multiplayer servers. Next abstract out the current AI traffic system so that it can be run as a standalone executable, that way multiplayer servers could optionally also run their own dedicated AI traffic clients that can connect to a multiplayer server (authentication permitting) in order to inject AI traffic (multiple AI aircraft instances) into a multiplayer server. Eventually, this would address issues concerning the discrepancy between multiplayer clients running with enabled AI traffic scenarios that are currently not yet synchronized. Ultimately, this would add the possibility to have server-side (AI traffic) scenarios for all connected multiplayer clients. Export all AI/multiplayer traffic nodes to local property tree, using a configurable range.
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim) would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily.
* Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view.
* Currently, roads and rivers do not yet have a realistic curvature when their direction changes, rather there are pretty visible corners, it would be nice if someone could look into this in order to come up with a method to smoothen the directional transistion, so that a realistic curve can be rendered
* Extend the RenderTexture class to provide support for Frame Buffer Object based rendering to a texture, this is a relatively new way to support rendering to texture for platforms or OpenGL (driver) implementations that do not offer native RTT support, as it is the case for many older Linux cards: http://openvidia.sourceforge.net/fbo.shtml

=== Huge Requests ===
* factor out current plib based scenegraph to allow integration with other scenegraphs, such as OSG (OpenSceneGraph). Adding support for OpenSceneGraph to FlightGear would also add support for mult-head displays, multiple rendering contexts as well as distributed rendering. If you are interested in this idea please make sure to search the mailing list archives at http://www.flightgear.org for "OpenSceneGraph", "OSG", "SSG" to get an impression of previous discussions about this topic.
* factor out scenery system to allow integration with other scenery systems (see mailing list discussions)
* factor out terrain system to allow integration with alternative terrain engines (see mailing list discussions)
* revamp scenery/terrain system in order to favor a non-tile based approach (see mailing list discussions concerning the use of quadtrees,octrees,kd-trees: http://www.sdss.jhu.edu/htm/index.html
* add support to optionally favor dynamic airport/runway creation at runtime over the pre-tesselated approach that is currently used, this would allow users to easily modify airports, possibly even at runtime-without having to re-create the corresponding scenery tile to make the changes take effect
* implement algorithms to feature dynamically adjustable (C)LOD/resolution for terrain data, as plans are being discussed to increase the resolution depth for upcoming scenery builds (SRTM), this would probably come in handy to allow users to adjust the terrain detail level according to their needs and hardware specs, otherwise we would probably face significant performance hits on lower end hardware, that is why it would make sense to allow users to configure the terrain resolution they'd like to use at runtime (i.e. 70% rather than 100% terrain features)
* Have FlightGear become its own IDE (integrated development environment) by allowing users to create and modify instruments directly within FlightGear, this would probably require a revamped (or more feature-rich) GUI toolkit than PLIB's PUI. Eventually, it would be desirable to allow users to pick instruments from the base package and place them at runtime on panels. For the majority of users this would be an essential steps towards improved usability.
* add support for automatically created scenery objects to populate the scenery dynamically at runtime (autogen-like), this could add quite a portion of realism to FlightGear without having to model scenery manually using fgsd, yet one could still use fgsd for areas where people are willing to contribute. All other scenery should by default be populated using autogen buildings and objects (references: http://www.infinitylab.com.au/research/prototypes.htm and http://vterrain.org/Culture/BldCity/procedural.html and http://pcity.sourceforge.net/ )

Feature Requests / Proposals / Ideas

2006-11-29T17:37:22Z

AJ: /* Major Requests */

Occassionally, 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.

Please note: while this list is only meant to provide an overview of desirable short- and long-term goals for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects (i.e. [http://sourceforge.net/projects/fgrun fgrun], [http://sourceforge.net/projects/fgsd fgsd], [http://sourceforge.net/projects/taxidraw taxidraw], [http://www.terragear.org terragear], [http://www.simgear.org simgear]), that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole.

'''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, this is extremely important in order to avoid duplicate code/efforts and a lack of coordination with regard to relevant implementation details, so please make sure to talk about your plans with other contributors before starting your work!'''

{|
|__TOC__
|}

== General Ideas ==

* Set up a wiki at FlightGear.org, so that regular backups can be easily done. Also, the wiki could possibly write/export its pages directly into the CVS directory of $FG_ROOT/Docs
* set up a full set of automatically created DoxyGen documentation at FlightGear.org, possibly using a monthly/weekly update cycle for the CVS version, this would require approx. 500MB of webspace, could be done using a cron job
* consider distributing the FlightGear CD/DVD as a linux boot cd/dvd (i.e. knoppix), so that users can optionally try to easily boot easily into linux in order to start FG
* consider setting up a non-profit organization for FlightGear, so that donations may become tax-deductible
* consider setting up a subversion server, so that we can stop using CVS-subversion can easily import an entire repository, preserving all revision history etc.
* http://scan.coverity.com/ - offers free code checks to open source projects
* At http://freshmeat.net/projects/installbase/ or more specifically at http://installbase.sourceforge.net/main.shtml there's an open source cross platform GUI installer available that may be an interesting option for creating binary FlightGear installers. The whole thing is based on TK and works with statically precompiled interpreters that serve as stub for an ASCII config file that contains all relevant information for cross platform setups,including a tarball of installation specific files for each platform. The installbase installer is very convenient and works entirely with a very powerful GUI frontend that allows you to set up, test and export installer packages. Given that the final config file is ASCII, it would probably be quite possible to simply put all this into some sort of Makefile, so that the whole package creation could be handled automatically, i.e. by doing something like "make win32-package" or "make macos-package". The [http://installbase.sourceforge.net/screenshots.shtml screenshots] look very convincing. That way, all FlightGear binaries could easily use an identical installer and configuration wizard.
* Set up a cross compiler version of gcc at flightgear.org to automatically create binary packages (releases) of FlightGear for platforms such as Win32 or MacOS. FYI: all registered sourceforge developers can access the so-called "compile farm" which is comprised of a number of different hosts/platforms including various compilers, on the AMD64 Opteron machines there are also various Win32 cross-compilers installed under /var/scratch/tools/bin -if you are interested in using the sourceforge services to create FlightGear binaries, check out the [http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1 sourceforge docs] --[[User:FlightZilla|FlightZilla]] 07:53, 18 June 2006 (EDT)
* import the complete DAFIF data into an SQL database, including Robin Peel's database, this would offer the possibility to provide a web based interface to the corresponding data, i.e. in order to allow users to easily provide corrections or augmentations for existing data. Eventually, this could probably also be useful for the landcover DB anyway?--[[User:82.83.154.229|82.83.154.229]] 09:31, 18 June 2006 (EDT)

== 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:

* http://digg.com/software/Awesome_Free_Flight_Sim
* http://www.macupdate.com/info.php/id/16997
* http://happypenguin.org/show?Flight%20Gear%20Flight%20Sim
* http://www.winfuture.de/news,23149.html
* http://nickles.softonic.de/ie/47000/Flightgear

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.

* non-intuitive scenery modification and installation
* non-intuitve aircraft modification and installation
* non-intuitive joystick configuration
* non-intuitive aircraft panel creation (lack of GUI frontend)
* non-integrated startup wizard (requires fgrun)
* lacking performance
* significant startup times
* currently no glass cockpit support
* lacking documentation
* insufficient mac support
* webpage appearance
* FDMs partially not very convincing
* not fully animated 3D models
* insufficient weather modelling and -effects
* multiplayer not yet too playable
* non-standard GUI, not too appealing to many users
* outdated FAQ
* no integrated tutorial/ground school or learning mode
* no realistic helicopter support
* no multi screen support
* airports/runways cannot easily be modified/re-created
* non-configurable approach lighting for runways
* no blade element FDM
* GUI does not yet expose many of FlightGear's features that are available via command line
* no real scenario/adventure support
* no combat support
* hardly realistic scenery-missing/inappropriate textures, objects, landmarks.
* no realistic water modelling
* no ground traffic modelling
* hardly localized UI: GUI, command line, error messages
* no localized help dialogs (basic commands, keys...)
* no Voice ATC
* not very advanced AI ATC
* no moving map directly integrated in FlightGear
* warnings and error messages are only rarely informative
* no flight planning facility integrated/available
* no support for sailgliders, hanggliders - unpowered flight
* no scripted demo flights that users could "play" to see a simple flight (pattern) including landing
* no ATC facilities for real life controllers (VATSIM like)
* does not work well on lower end hardware
* starting FG takes a while and FG seems to have crashed, the window (splash screen) is not redrawn-unresponsive until finally started up
* no water effects for ocean and rivers (waves/streams)
* no support for weight & balance (and fuel) for aircraft
* currenlty not a suitable VFR simulator
* few buildings have proper night textures
* significant initial download (>100MB) - might be a good idea to try to reduce the base package size where possible

== Feature Requests ==
=== Minor Requests ===

* 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.
* 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() )
* Add new nimitz carrier view
* the menubar should be reloadable
* 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.
* 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 additional pitch mode to autopilot dialog for climb/descent gradients, so that users can specify a gradient that is automatically maintained (i.e. a glidepath)
* 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

=== Intermediate Requests ===
* switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)
* 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.
* add new command to nasal interpreter to allow playing of sound files (see mailing list discussions)
* add possibility to re-init the nasal interpreter, so that it reloads any modified script files
* there are still plenty of old "pseudo-subsystems" that do not yet make use of SGSubsystem, it would be good if subsystems such as the GUI subsystem could be ported to become native SGSubsystems
* 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).
* provide a GUI dialog that automatically enumerates all available instrumentation systems, so that users can easily enable/disable individual systems
* 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.
* provide runtime configurable friction coefficients for runways to simulate contaminated runways (dirt, water, snow/ice) at runtime and export corresponding properties to property tree
* extend weather modelling subsystem to simulate weather features such as thermals, gusts or windshear more extensively and realistically. This would also come in very handy for sailplane/gilder modelling which is currently not yet satisfactorily simulated.
* 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)
* add support for registration labels to be drawn at runtime to an aircraft's tail-possibly using ImageMagick (or maybe just PLIB's FNT library) and rendering the text to a texture, so that airplanes can optionally show proper registrations (taken form the property tree) in multiplayer or AI traffic scenarios
* 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
* extend sgsubsystem class to optionally publish each subsystem's actual update interval (determined at runtime) to a specific property, this will allow simple nasal scripts to deal with any issues (i.e. show warnings) if a certain subsystem is not, or cannot be run at a certain update interval. As more and more complex subsystems are getting added to FlightGear this would add the possibility for automatic detection of subsystems that cannot be run at proper update intervals, i.e. due to old/slow hardware. Ultimately, this could also make it easier to add auto-scaling support to FlightGear.
* 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]]
* add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft
* extend nasal interpreter to provide functions for loading and saving XML files directly, 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)
* merge AI and ATC code so that both work properly with each other
* add support for a TCAS implementation that honors multiplayer as well as AI traffic
* 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.
* implement a flight director (using the current PID controller code)
* provide support for force-feedback input hardware and/or motion platforms
* for the development of more advanced avionics we will require a terminal procedures database (i.e. SIDs & STARs), this should be added to the base package, so that we can provide the corresponding data within FlightGear, its availability (memory consumption!) could be made optional using a corresponding property or new special instrument type.
* allow nasal code to be specified in instrument files
* allow nasal scripts in AI object XM files, so that nasal code can move AI objects along predefined routes
* allow instrument update interval to be configurable (export to property tree)
* strictly enforce usage of enum fg_nav_types in all FG code to isolate/protect other code from changes in the underlying navdb format
* add additional updates to the splash screen during startup, so that it is more responsive, possibly using some sort of progress bar
* allow aircraft to be reloadable at runtime (could be a first big step towards making aircraft switchable at runtime!)
* 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)
* the replay system is very nice, but it is not very convenient to use: improve usability
* add texture paging support to singear/flighgear
* allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
* implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
* 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.
* 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, explicitly install and set up in order to be able to use it. Even moreso, 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 it 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.
* 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
* 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.
* 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
* aircraft (FDM & 3D model) should be re-loadable at runtime
* provide support for an instrument transformation that emulates instrument illumination
* provide support for cockpit light sources, so that we can realistically illuminate the cockpit as a whole
* add an IRS/INS emulation for airliner-type aircraft
* add a LORAN emulation for long range flight
* 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.
* 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.
* allow to create/modify and save instruments hotspot regions directly from within FG, so that the process of creating 2D panels becomes less complicated
* add a new instrumentation system to emulate a MLS (microwave landing system)
* extend multiplayer code to add support for helicopters
* multiplayer: maintain a serverside list of aircraft that may connect to the server, this could be useful to prevent certain types of aircraft (i.e. UFO, santa, ogel etc) from appearing in more serious settings, likewise we could disallow certain aircraft with unfinished fdm
* maintain FDM "plausibility" values for all legitimate aircraft, so that the server can determine if a specific aircraft is able to achieve a certain performance (i.e. climb/descent,airspeed). This could be based on 10-20 figures for each aircraft, so that the server can interpolate between different situations and determine if the provided data is still accurate or not. Eventually this would also allow server admins to run certain 3D models only with certain FDMs.
* 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
* add support for pilot-controlled runway lighting
* 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.
* add support for particle animations (i.e. smoke, sparks etc)
* improve visual weather effects (fog, rain, snow etc)
* currently, the replay system doesn't take animations, sub models and sounds into account
* add support to allow multiple views to be rendered simulatenously, so that we display arbitrary views within other views
* extend the multiplayer subsystem to support the DIS protocol
* consider adding VBO support
* allow replay flights to be resumed manually (this would be useful for instruction-like scenarios)
* use imposter objects for sky & distant scenery
* add support for multitexturing/texture blending
* allow custom views to be specified based on positions taken from scenery objects or the navaids db, i.e. to create scripted views that are situated at apron/taxiway/runway XX using configurable offset YY, at altitude ZZ

=== Major Requests ===
* Replace current PLIB/PUI based GUI bindings with bindings for a more feature-rich GUI (possibly SDL based) [[OpenGL_GUI_RESOURCES]]
* http://chromium.sourceforge.net/
* texture cropping support for 2D panels (see mailing list archives for discussions)
* add support for enhanced water modeling, so that we can start implementing water aircraft with floats etc.
* when aircraft are very low, the terrain/scenery looks only rarely convincing due to the fact that flat textures are applied to surfaces in order to illustrate vegetation, however this works only properly for higher altitudes, so it would be desirable if we could add support for dynamic vegetation modeling, so that grass, trees and other plants are dynamically created within a certain proximity.
* the navdb should eventually become a true SGSubsystem, it needs some serious revamping.
* basically all subsystems should be fully "suspend-able" and "reinit-able" at runtime, there are currently various subsystems that will consume CPU cycles even though they are not in fact necessarily required, affecting FlightGear's performance negatively. This is particularly the case for non-SGSubsystem based systems.
* the navdb & airports wrappers should eventually be moved to simgear, there are meanwhile various programs (i.e. atlas,taxidraw,fgsd,fgrun) relying on the very same code-using the copy&paste approach. It would be much cleaner and better if simgear coul provide the corresponding functionality. That way, we would also only have to fix any issues (i.e. changes in Robin Peel's db format) on ONE central place.
* add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details)
* The current Property Tree code is not thread safe, sooner or later it may come in handy if this feature was added
* Meanwhile, FlightGear has become a pretty monolothic piece of software, in the long run it would be desirable if the code could become somewhat more modularized and structured, eventually this should also make it easier for new contributors to get started.
* 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. This would probably also be useful for scenery creation in general. http://freshmeat.net/projects/shapelib/ http://sourceforge.net/projects/shpread/
* 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
* factor out weather subsystem, so that weather can be set up for specific locations (initially mainly airports and navaids (using radials, distances), later on possibly also landmarks and towns/areas), i.e. to provide weather for departure airport, enroute, destination and alternate. A good approach might be to simply convert the current weather subsystem into a METAR server, that way FlightGear could optionally provide its own local METAR server that can be easily set up using some sort of GUI (or the property tree) and still be easily polled for current weather using the METAR code that is already in place. This approach would also make it very feasible to interoperate with a multiplayer server.
* 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?
* add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear
* 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
* eventually, it may become desirable to add unit testing support to those FlightGear subsystems/components that can be considered stable and that are thus unlikely to change significantly anytime soon, that way it should become much easier to track development problems early.
* implement support for dynamic LOD customization for aircraft at runtime, so that the detail level of aircraft models can be dynamically reduced/increases (the poly count, that is) on demand, currently multiplayer aircraft need to have their own separate (reduced) 3D model, so it would probably make sense to think about implementhing some sort of runtime configurable LOD algorithm that can return any 3D model with a customized detail level. This has been discussed various times on the mailing list (and is currently being discussed again).
* 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)'''
* Factor out AI traffic code in order to make it work with the multiplayer client code: incorporate the AI traffic system with the multiplayer system so that the AI traffic system becomes a special multi-aircraft client and can thus sort of 'inject' AI aircraft/traffic instances into multiplayer servers. Next abstract out the current AI traffic system so that it can be run as a standalone executable, that way multiplayer servers could optionally also run their own dedicated AI traffic clients that can connect to a multiplayer server (authentication permitting) in order to inject AI traffic (multiple AI aircraft instances) into a multiplayer server. Eventually, this would address issues concerning the discrepancy between multiplayer clients running with enabled AI traffic scenarios that are currently not yet synchronized. Ultimately, this would add the possibility to have server-side (AI traffic) scenarios for all connected multiplayer clients. Export all AI/multiplayer traffic nodes to local property tree, using a configurable range.
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim) would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily.
* Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view.
* Currently, roads and rivers do not yet have a realistic curvature when their direction changes, rather there are pretty visible corners, it would be nice if someone could look into this in order to come up with a method to smoothen the directional transistion, so that a realistic curve can be rendered
* Extend the RenderTexture class to provide support for Frame Buffer Object based rendering to a texture, this is a relatively new way to support rendering to texture for platforms or OpenGL (driver) implementations that do not offer native RTT support, as it is the case for many older Linux cards: http://openvidia.sourceforge.net/fbo.shtml

=== Huge Requests ===
* factor out current plib based scenegraph to allow integration with other scenegraphs, such as OSG (OpenSceneGraph). Adding support for OpenSceneGraph to FlightGear would also add support for mult-head displays, multiple rendering contexts as well as distributed rendering. If you are interested in this idea please make sure to search the mailing list archives at http://www.flightgear.org for "OpenSceneGraph", "OSG", "SSG" to get an impression of previous discussions about this topic.
* factor out scenery system to allow integration with other scenery systems (see mailing list discussions)
* factor out terrain system to allow integration with alternative terrain engines (see mailing list discussions)
* revamp scenery/terrain system in order to favor a non-tile based approach (see mailing list discussions concerning the use of quadtrees,octrees,kd-trees: http://www.sdss.jhu.edu/htm/index.html
* add support to optionally favor dynamic airport/runway creation at runtime over the pre-tesselated approach that is currently used, this would allow users to easily modify airports, possibly even at runtime-without having to re-create the corresponding scenery tile to make the changes take effect
* implement algorithms to feature dynamically adjustable (C)LOD/resolution for terrain data, as plans are being discussed to increase the resolution depth for upcoming scenery builds (SRTM), this would probably come in handy to allow users to adjust the terrain detail level according to their needs and hardware specs, otherwise we would probably face significant performance hits on lower end hardware, that is why it would make sense to allow users to configure the terrain resolution they'd like to use at runtime (i.e. 70% rather than 100% terrain features)
* Have FlightGear become its own IDE (integrated development environment) by allowing users to create and modify instruments directly within FlightGear, this would probably require a revamped (or more feature-rich) GUI toolkit than PLIB's PUI. Eventually, it would be desirable to allow users to pick instruments from the base package and place them at runtime on panels. For the majority of users this would be an essential steps towards improved usability.
* add support for automatically created scenery objects to populate the scenery dynamically at runtime (autogen-like), this could add quite a portion of realism to FlightGear without having to model scenery manually using fgsd, yet one could still use fgsd for areas where people are willing to contribute. All other scenery should by default be populated using autogen buildings and objects (references: http://www.infinitylab.com.au/research/prototypes.htm and http://vterrain.org/Culture/BldCity/procedural.html and http://pcity.sourceforge.net/ )

Autopilot PID controller tuning resources

2006-11-28T19:01:25Z

AJ:

Flightgear Autopilot is a modular system based on PID controlers. Here are some tips to help in the tuning of such a controler. There is lot of documentation all over Internet about how to tune the parameters, having this you will have to figure out how works the Flightgear PID controler implementation.

First of all, have a look at the code where you will see the algorythm wich is used for our autopilot. The reading of the existing autopilots in Flightgear aircraft datas will do the rest.

There is actually a doc about filters in Flightgear documentation. Filters can be applied on input or ouput values, in other words, before and after the PID controler.

=== Flightgear PID Controler ===

Knowing the algorythm is mandatory, certain values are forbiden, for exemple they can lead to a division by zero. Then you will have to understand where the parameters apply to act on the choosen correction module. See the schema wich is a good reminder while doing the tests.

[[Image:pid_controler.png|thumb|PID parameter's application]]

You can find good explanations on how to practicaly tune the controler. [http://en.wikipedia.org/wiki/PID_controller Wikipedia's article on the PID Controler]

=== Getting graphs of Controler action ===

While it's possible to tune a PID Controler by testing directly the aircraft behaviour under the autopilot control, it can be really usefull to get everything in graphical view.

[[Image:pid_cotroler_data_graph.png|thumb|Datas of an Auto-trim PID Controler displayed as graphs]]

First of all you'll have to turn the PID Controler's debug mode on. That is in the autopilot.xml you are working on. (I didn't try to turn more than one PID controler's debug at the same time).

Then you will get 6 new values displayed on the console at each FG loop. You will need to catch them and format the values in one line. Here is an exemple of a parser script written in Perl:

<pre>

#!/usr/bin/perl -w
# prints: "input reference P I D output"

while (<STDIN>) {
if ($_ =~ /input\s=\s(-*\d+.*)\sref\s=\s(-*\d+.*)/) {
print STDOUT "$1 $2 ";
} elsif ($_ =~ /P:(-*\d+.*)\sI:(-*\d+.*)\sD:(-*\d+.*)/) {
print STDOUT "$1 $2 $3";
} elsif ($_ =~ /output\s=\s(.*)/) {
print STDOUT " $1\n";
}
}

</pre>

Then you can write them in a file...

<pre>

alexis@linear:~/fgfs$ /usr/local/bin/fgfs 2>&1 | ./PIDcontroler_parser.pl > my_file

</pre>

If you use Linux, You can run Kst simultaneously to read the datas on the fly and watch them displayed together in real time while testing the aircraft.

[http://kst.kde.org/ Kst, real-time large-dataset viewing and plotting tool]

Howto:Fly a helicopter

2006-11-18T21:52:39Z

AJ: /* Preface */

Very first: I would be very thankful, if one could correct this introduction to correct English!

== Preface ==

First: in principle everything that applies to real helicopters, applies also to Flightgear. Fundamental maneuvers are well described on: http://www.cybercom.net/~copters/pilot/maneuvers.html Some details are simplified in Flightgear, in particular the engine handling and some overstresses are not simulated or are without any consequence. In Flightgear it is (up to now) not possible to damage a helicopter in flight.

[[Image:bo105_cockpit.jpg]]

Since the release of version 0.9.10 some improvements have been made to the helicopter flight model and therefore the CVS version should be used. With these improvements the helicopter flight model of Flightgear should be quite realistic; the only exceptions are “vortex ring conditions”. These occur if you descend without forward speed briskly perpendicularly, the heli can get into its own rotor downwash. The lift is substantially reduced; terminating of this condition is possible only out of large altitude. On the Internet you can find a video of a Seaking helicopter, which got into this condition during a flight demonstration and touched down so hard afterwards that it was completely destroyed.

However, a restriction is that for all Flightgear helicopters the parameters are not completely optimized and thus the performance data between model and original deviate slightly. On the hardware side I recommend the use of a “good” Joysticks. A Joystick without feathers/springs is recommendable (thus it does not center by itself). You can reach this by modifying a normal joystick, or by using a force feedback joystick, with disconnected voltage supply. Further, the Joystick should have a “thrust controller” (throttle). For controlling the tail rotor you should have pedals or at least a twistable joystick, keyboard would be the hard way. (Hint: Flightgear supports more than one joystick attached at the same time.)

== Getting started ==

In Flightgear the number of available helis is still very limited. In my opinion the Bo105 is the easiest to fly, since it reacts substantially more directly than other helicopters. From the flight behavior I can still recommend as350, however there is no 3D-model, it uses the Bo105 3D-model. The As350 reacts clearly more retarded than the Bo.

If Flightgear is loaded and the cockpit of the helicopter is to be seen, move all control functions a bit, so that the positions are recognized by all controls (in particular I find collective most times at maximum). The helicopter is controlled by four functions. The stick=joystick controls two of them, the inclination of the rotor disc (and thus those of the helicopter) to the right/ left and forwards/back. Together these functions are called “cyclic blade control”. Furthermore there is the “collective blade control”, which is controlled by the thrust controller. This causes a change of the thrust produced by the rotor. Since the powering of the main rotor transfers a torque to the fuselage, this must be compensated by the tail rotor. Since the torque is dependent on the collective and on the flight condition as well as wind can add additional torque on the fuselage, the tail rotor is adjustable. This is controlled with the pedals. If you push the right pedal, the helicopter turns to the right (!), the pedals are not a steering wheel. Furthermore you can turn thereby the helicopter around the vertical axis. The number of revolutions of the rotor is kept automatically constant (if possible).

[[Image:bo105_in_the_air.jpg]]

== Lift-Off ==

At first reduce the collective to minimum. To increase the rotor thrust, you have to “pull” the collective. Therefore for minimum collective you have to push the control down (that is the full acceleration position (!) of the thrust controller). Thus: Thrust controller to “full power” what means minimum collective. The engine is started with “}”. After few seconds the rotor starts to turn and accelerates slowly. Hold the stick and the pedals approximately in centered position. Wait until the rotor finish its accelerated (there is an instruments for engine and rotor speed, in the Bo105 on the left in the upper row). Then pull the collective slowly (really slowly!!!). Observe exactly the horizon. If the heli tilts or turns only a little bit, stop increasing the collective and correct the position/movement with stick and pedals. If you are successful, continue pulling the collective (slowly!). If the helicopter flies, increase the collective a little bit more and try to keep the helicopter in a leveled position. The main difficulty is it to react to an inadvertent rotating motion of the helis with the correct measure. Only three things can help you: practice, practice and practice. It is not unusual that the time one needs to get a halfway good looking hovering flight is to be measured not in minutes, but in hours. Note: The stick position in stable hover is not the center position of the joystick.

== In the air ==

In order not to let the frustration win the upper hand, it is recommendable to try occasionally the forward flight. After take off continue pulling the collective a short time and than lower the nose a little bit by a short forward movement of the stick. The heli accelerates forward. With forward speed the tail rotor does not have to be controlled precisely due to the wind flag effect. Altogether the flight behavior in forward flight is quite similar to that of an (bad trimmed) airplane. The “neutral” position of the stick is different depending upon airspeed and collective.

The transition of the forward flight to the hovering flight is at the simplest, if you reduce the speed only slowly by raising the nose of the helicopter only a little bit. Reduce the collective, otherwise the heli would climb. If the heli gets rather slow, the so called “translation lift” is reduced, and you must compensate this by pulling the collective. If the speed is reduced nearly to zero, lower the nose at it was in hovering, otherwise the heli accelerates immediately backwards.

== Back to Earth I ==

To land the helicopter do the same as described before, additionally lower the altitude within. Briefly before hitting the ground reduce the rate of descent slowly. A perfect landing is achieved, if you reduce at the same time altitude, speed and descent rate and all three parameters get zero simultaneously (important: gently). However, such landing are extremely difficult. Most pilots perform a hover more or less near to the ground and than decent slowly to the ground. Also a landing with forward travel speed is easier, however one must assure to touch down without lateral speed to avoid a rollover. Since the ground in Flightgear is free from all unevenness, this kind of landing is simpler than in the reality.

[[Image:bo105_landed.jpg]]

== Back to Earth II ==

I like to mention the autorotation briefly. This is a unpowered flight condition, where alone air flowing by the rotor propels the rotor. In appropriate altitude select a landing point (at first in the size of a larger airfield) and then switch the engine off by pressing "{". Reduce collective to minimum, place the tail rotor to approximately 0 degrees incidence (with the Bo push the right pedal about half , with As350 the left). Approach with approximately 80 knots. The rotor speed may not rise more than a few percent over 100%, otherwise the rotor would be damaged (this is not simulated up to now). In time before reaching the ground reduce the airspeed by lifting the nose. The descent rate will be reduced by this as well, you do not need to pull collective now. However it can be that the rotor speed rises here beyond the permitted range. Avoid this by increasing the collective if needed. Closely over the ground reduce the descent rate by pulling the collective. The goal is it to touch down with very small descent rate and without forward speed. With forward speed it is easier, however the danger of a roll over exists, if the skids are not aligned parallel to the flight direction. During the approach it is not necessary to adjust the tail rotor, since without power there is almost no torque. If you feel (after some practicing), that the autorotation is too simple, considers that only you without any further ballast are in the helicopter. You can adjust this in the menu.

[[Image:bo105_auto.jpg]]

Much fun with the Flightgear helicopters.

Howto:Multiplayer

2006-05-27T22:52:43Z

AJ:

= Using the Windows launcher / fgrun =

Select your aircraft and starting airport as normal. On the next screen, tick the "Multiplayer" box, enter a callsign of your choice, enter mpserver01.flightgear.org in the "Hostname" box and 5000 into both the "in" and "out" boxes. Click run and you're hopefully sorted!

To confirm that it's working, you can go to http://mpmap01.flightgear.org and use the multiplayer map there.

You may wish to use a different server (i.e. "Hostname" entry); currently available are:

mpserver01.flightgear.org (in Germany)
mpserver02.flightgear.org (in Hong Kong)
mpserver03.flightgear.org (East Coast USA)

= Using fgfs from the command line =

First, for those who are very impatient and have a vague idea about what they're doing, the basic arguments to pass to fgfs for multiplayer are these;

--multiplay=out,10,server.ip.address,portnumber

--multiplay=in,10,your.ip.address,portnumber

--callsign=anything

Where portnumber is usually 5000 or 5002 and your.ip.address is the ip address of the network interface being used by FG to connect to the server - even if that's a local 192.168 type address. Please note that although this limitation has been removed in the most recent versions of the FG server; you should still specify a valid (non-loopback, i.e. not 127.0.0.1) IP address to keep the FG client happy.

Port 5000 is usually for the latest stable version of FlightGear. Currently 0.9.10

Port 5002 is mainly used for development, i.e. stable version of FlightGear might not work with this server.

== Now, going more slowly for those who are completely lost... ==

Try the above first, and if it doesn't work, read on.

First of all, you need to know the IP address of the network interface you're going to be running FG multiplayer over. If your Internet connection is via an ADSL modem that plugs directly into your computer with a USB connection, you should be able to find your IP address by visiting http://www.whatismyip.com . Please note that this address may very well change every now and again - if MP stops working, check this first.

Otherwise, your connection is likely via some kind of router that connects to your computer via an RJ-45, or "Ethernet" connector (similar shape to most Western telephone plugs), or by a wireless link. You need to find the IP address of that network interface.

Under linux, this can be found by logging in as root and typing "ifconfig". You may find more than one interface listed, beginning with "lo" - ignore that one. You should have something like "eth0" or "wlan0" also listed - look through this block of text for "inet addr". This will be followed directly by the number you're looking for, e.g. "inet addr:192.168.0.150"

Under Windows XP, click start, run, and type "cmd". In the terminal window which appears, type "ipconfig" This should show you your IP address - note it down.

With Windows 98, click start, run, and type "winipcfg" to get information about your IP address.

This section _ought_ to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

Now, all(!) that remains is to configure your router to forward UDP port 5000 or 5002 to the IP address you've just found. This is not something that can be described in step-by-step detail, because each manufacturer's configuration interfaces differ greatly. Some tips are given here - if you get stuck, ask nicely on the FlightGear IRC channel for help (details on the flightgear website).

You should know how to log on to your router's configuration page, usually via a web browser. You are looking for settings pertaining to "port forwarding" "virtual server" "Forwarding Rules" or similar. When you have found the relevant settings, you need to add a rule that forwards port 5000 or 5002 (depending on which server you wish to join - add both if you like) to the IP address you discovered earlier. If there is a choice given, ensure it is UDP ports that are forwarded. If there is no choice, you may assume that both TCP and UDP are being forwarded. Save your configuration, and most routers will probably then need to be rebooted to apply the changes.

Note: (for BSD users) If you are using a ADSL modem, you might have to put the port forward command into the ppp.conf file rather than firewall. This is because the firewall script will only run each time the machine is booted rather than the ppp line coming back online.

Finally, start FG using the command line given right at the start (if you're using the windows launcher you will find entry boxes for Multiplayer arguments - insert the relevant details there). You will end up with something like this;

fgfs --callsign=MyName --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver02.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter

Choose your own callsign - this is currently limited to seven characters.

Once you have started FG, you should, if others are flying, see messages in the terminal from which FG was started, similar to the following;

Initialising john51a using 'Aircraft/ufo/Models/ufo.xml'
FGMultiplayRxMgr::ProcessRxData - Add new player. IP: 10.0.0.36,
Call: john51a,model: Aircraft/ufo/Models/ufo.xml

You MUST give your local, behind-the-router IP address for MultiPlayer to work. Trust me on this one!

You should check that your firewall is not causing problems - either turn it off _temporarily_ or add an exception to allow incoming connections on port 5000 and 5002.

If it's still just not working for you, ask nicely on the FlightGear IRC channel and someone should be able to assist.
Multiplayer Map
There is a very nice online map which displays the location of online pilots at http://mpmap01.flightgear.org . You will also find this useful to check that you are successfully connecting to the server.

THE FLIGHTGEAR MULTIPLAYER ROUGH HOWTO

2006-05-27