== Google Summer of Code 2011==

We missed the deadline for Google Summer of Code 2010 so preparations begin '''now''' to get projects, mentors and students in place for 2011.

= Instructions common to Students, Mentors, Support Staff =

All participants should take a look at the [http://socghop.appspot.com/ Summer of Code Program] every now and then to be informed about updates and advices. It is also important to read the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs Summer of Code FAQ], as it contains useful information.

All participants will need a Google account in order to join the program. You'll save some time if you create one now.

= Project Application =
Mentor projects need to provide a minimum level of info about the project as detailed at http://code.google.com/soc/2008/org_signup.html
This section is meant to provide copy/paste text that may be pasted into the aforementioned application form, please feel free to populate with contents.

== Describe your Organization ==

* http://www.flightgear.org/introduction.html
* Open Source flight simulator framework
* written in C++
* multi-platform simulator
* has been in development for over a decade now
* licensed under GNU GPL
* framework used for various efforts (science, educational etc)
* recently released version 2.0
* goals of the project: [[Long Term Goals]]
* developed by contributors from all over the world
* many contributors have a professional background in aviation, sciences, maths etc.
* has created a wealth of related sub projects
* major features (property tree, highly configurable, XML-based configuration files, fully exposed internals)
* link to good reviews

== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ==
* increase awareness of the project
* get new contributors interested in the flightgear project
* recruit additional manpower
* achieve specific project goals that require full-time effort

== Did your organization participate in previous GSoC years? If so, please summarize your involvement and the successes and failures of your student projects. (optional) ==

No, the FlightGear project has not previously participated in GSoC.

== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? (optional) ==
No, there have been no previous applications.

== What license does your project use? ==
The GNU GPL

== URL for your ideas page ==
[[GSoC: Candidate_Projects]]

== What is the main development mailing list for your organization? ==
flightgear-devel@lists.sourceforge.net

== Where is the main IRC channel for your organization? ==
# #flightgear irc.flightgear.org
# #FG-GSoC on irc.flightgear.org to co-ordinate our GSoC participation

== Does your organization have an application template you would like to see students use? If so, please provide it now. (optional) ==
Not yet, still needs to be created - can be done on this wiki page, and then be linked to directly.

== Who will be your backup organization administrator? Please enter their Google Account address. We will email them to confirm, your organization will not become active until they respond. (optional) ==

== Mentors ==
=== What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===

=== Who will your mentors be? Please enter their Google Account address separated by commas. If your organization is accepted we will email each mentor to invite them to take part. (optional) ===

== About the Program ==

=== What is your plan for dealing with disappearing students? ===

=== What is your plan for dealing with disappearing mentors? ===

We intend to have multiple mentors for each student so that a disappearing mentor, while unfortunate, is not necessarily critical

=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===

=== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===

= Related Pages =
[[GSoC: Candidate_Projects]]

[[GSoC: Mentors]]

[[GSoC: Student_Applications]]

= [[Useful Links]] =
GSoC User Guide 2010 [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/userguide]
The BZFlag GSoC Post Motem report 2007 [http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]

{{stub}}

2010-03-23T20:50:49Z

Willie: moved Google Summer of Code 2011 to GSoC: 2011: use a rational namespace for related pages

== Google Summer of Code 2011==

We missed the deadline for Google Summer of Code 2010 so preparations begin '''now''' to get projects, mentors and students in place for 2011.

[[Google_Summer_of_Code_Candidate_Projects]]

[[Google_Summer_of_Code_Mentors]]

[[Google_Summer_of_Code_Student_Applications]]

'''Instructions common to Students, Mentors, Support Staff'''

All participants should take a look at the [http://socghop.appspot.com/ Summer of Code Program] every now and then to be informed about updates and advices. It is also important to read the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs Summer of Code FAQ], as it contains useful information.

All participants will need a Google account in order to join the program. You'll save some time if you create one now.

Talk:GSoC: 2012

2010-03-23T20:49:24Z

Willie: initial page creation

GSoC: Candidate Projects

2010-03-23T15:13:36Z

Willie: /* Related Wiki Pages */

{{Stub}}

TODO: copy/paste feature requests and mini projects from other wiki pages that might make for good candidate projects, for a possible application/participation. Update this page to show that we will be applying for participation in '''2011'''

= Related Wiki Pages =
* [[Google Summer of Code 2011]]
* [[Google_Summer_of_Code_Mentors]]
* [[Google_Summer_of_Code_Student_Applications]]

Wiki pages containing possible inspirations for candidate projects:
* [[Feature Requests / Proposals / Ideas]]
* [[FGFS Todo]]
* [[Bugs]]

= Project Application =
Mentor projects need to provide a minimum level of info about the project as detailed at http://code.google.com/soc/2008/org_signup.html
This section is meant to provide copy/paste text that may be pasted into the aforementioned application form, please feel free to populate with contents.

== Describe your Organization ==

* http://www.flightgear.org/introduction.html
* Open Source flight simulator framework
* written in C++
* multi-platform simulator
* has been in development for over a decade now
* licensed under GNU GPL
* framework used for various efforts (science, educational etc)
* recently released version 2.0
* goals of the project: [[Long Term Goals]]
* developed by contributors from all over the world
* many contributors have a professional background in aviation, sciences, maths etc.
* has created a wealth of related sub projects
* major features (property tree, highly configurable, XML-based configuration files, fully exposed internals)
* link to good reviews

== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ==
* increase awareness of the project
* get new contributors interested in the flightgear project
* recruit additional manpower
* achieve specific project goals that require full-time effort

== Did your organization participate in previous GSoC years? If so, please summarize your involvement and the successes and failures of your student projects. (optional) ==

No, the FlightGear project has not previously participated in GSoC.

== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? (optional) ==
No, there have been no previous applications.

== What license does your project use? ==
The GNU GPL

== URL for your ideas page ==
Link to this wiki page and appropriate subsection

== What is the main development mailing list for your organization? ==
flightgear-devel@lists.sourceforge.net

== Where is the main IRC channel for your organization? ==
#flightgear irc.flightgear.org

also the very new #FG-GSoC on irc.flightgear.org to co-ordinate our GSoC participation

== Does your organization have an application template you would like to see students use? If so, please provide it now. (optional) ==
Not yet, still needs to be created - can be done on this wiki page, and then be linked to directly.

== Who will be your backup organization administrator? Please enter their Google Account address. We will email them to confirm, your organization will not become active until they respond. (optional) ==

== Mentors ==
=== What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===

=== Who will your mentors be? Please enter their Google Account address separated by commas. If your organization is accepted we will email each mentor to invite them to take part. (optional) ===

== About the Program ==

=== What is your plan for dealing with disappearing students? ===

=== What is your plan for dealing with disappearing mentors? ===

=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===

=== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===

= People supporting a possible application & participation =
'''Add your name here to join the committee'''

Curt Olson -- BDFL

Willie Fleming -- willing to assist with organising mentors, students and projects. Ensure correct documentation is completed and submitted in a timely fashion.

= Eligible community members who would like to participate as students =
= Volunteer Mentors =
People who'd be willing to mentor a possible project:

= Template for Student Applications =
TODO: revamp, modify/add questions for possible students applications.

Please provide answers to the following questions:

* Have you previously contributed to open source projects?
** If so, which ones?

* Please provide some information about your programming background?

* What are your main interests in computers, aviation, flight simulation?

* Please state which of the following technologies you are familiar with and how proficient you consider yourself:
** C++ programming
** XML
** OpenGL
** TCP/IP networking
** cross-platform programming

* Have you previously contributed to the FlightGear project or any of its affiliated projects?
** If so, which ones and how exactly?

* How familiar do you consider yourself with the FlightGear project? (0-10)

* Do you have experience working with CVS?

* Why are you interested in contributing to FlightGear?

* What would be your preferred working area in FlightGear?

* Have you previously interacted with the FlightGear community? If so, how?

* Are you currently subscribed to the FlightGear Devel mailing list?

= FlightGear Candidate Projects =

TODO: put here suitable ideas for projects

== [[FlightGear Multiplayer Server]] ==
== FlightGear [[TerraGear]] - Scenery Compiler ==
== [[FlightGear Scenery Designer]] ==
== [[FlightGear Launch Control]] ==
== FlightGear [[TaxiDraw]] ==
== FlightGear [[JSBsim]] ==

= [[Useful Links]] =

GSoC User Guide 2010 [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/userguide]

What the BZFlag project learned a couple of years back [http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]

Willie: /* Useful Links */

GSoC: Candidate Projects

2010-03-19T21:46:44Z

Willie:

GSoC: Candidate Projects

2010-03-19T21:02:35Z

Willie: /* Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? */

GSoC: Candidate Projects

2010-03-19T20:08:51Z

Willie: /* Where is the main IRC channel for your organization? */

{{Stub}}

TODO: copy/paste feature requests and mini projects from other wiki pages that might make for good candidate projects, for a possible application/participation.

= Related Wiki Pages =
Wiki pages containing possible inspirations for candidate projects:
* [[Feature Requests / Proposals / Ideas]]
* [[FGFS Todo]]
* [[Bugs]]

= Project Application =
Mentor projects need to provide a minimum level of info about the project as detailed at http://code.google.com/soc/2008/org_signup.html
This section is meant to provide copy/paste text that may be pasted into the aforementioned application form, please feel free to populate with contents.

== Describe your Organization ==

* http://www.flightgear.org/introduction.html
* Open Source flight simulator framework
* written in C++
* multi-platform simulator
* has been in development for over a decade now
* licensed under GNU GPL
* framework used for various efforts (science, educational etc)
* recently released version 1.0
* goals of the project: [[Long Term Goals]]
* developed by contributors from all over the world
* many contributors have a professional background in aviation, sciences, maths etc.
* has created a wealth of related sub projects
* major features (property tree, highly configurable, XML-based configuration files, fully exposed internals)
* link to good reviews

== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? ==
* increase awareness of the project
* get new contributors interested in the flightgear project
* recruit additional manpower

== Did your organization participate in previous GSoC years? If so, please summarize your involvement and the successes and failures of your student projects. (optional) ==

No, the FlightGear project has not previously participated in GSoC.

== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? (optional) ==
No, there have been no previous applications.

== What license does your project use? ==
The GNU GPL

== URL for your ideas page ==
Link to this wiki page and appropriate subsection

== What is the main development mailing list for your organization? ==
flightgear-devel@lists.sourceforge.net

== Where is the main IRC channel for your organization? ==
#flightgear irc.flightgear.org

also the very new #FG-GSoC on irc.flightgear.org to co-ordinate our GSoC participation

== Does your organization have an application template you would like to see students use? If so, please provide it now. (optional) ==
Not yet, still needs to be created - can be done on this wiki page, and then be linked to directly.

== Who will be your backup organization administrator? Please enter their Google Account address. We will email them to confirm, your organization will not become active until they respond. (optional) ==

== Mentors ==
=== What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===

=== Who will your mentors be? Please enter their Google Account address separated by commas. If your organization is accepted we will email each mentor to invite them to take part. (optional) ===

== About the Program ==

=== What is your plan for dealing with disappearing students? ===

=== What is your plan for dealing with disappearing mentors? ===

=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===

=== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===

= People supporting a possible application & participation =
Willie Fleming -- willing to assist with organising mentors, students and projects. Ensure correct documentation is completed and submitted in a timely fashion.

= Eligible community members who would like to participate as students =
= Volunteer Mentors =
People who'd be willing to mentor a possible project:

= Template for Student Applications =
TODO: revamp, modify/add questions for possible students applications.

Please provide answers to the following questions:

* Have you previously contributed to open source projects?
** If so, which ones?

* Please provide some information about your programming background?

* What are your main interests in computers, aviation, flight simulation?

* Please state which of the following technologies you are familiar with and how proficient you consider yourself:
** C++ programming
** XML
** OpenGL
** TCP/IP networking
** cross-platform programming

* Have you previously contributed to the FlightGear project or any of its affiliated projects?
** If so, which ones and how exactly?

* How familiar do you consider yourself with the FlightGear project? (0-10)

* Do you have experience working with CVS?

* Why are you interested in contributing to FlightGear?

* What would be your preferred working area in FlightGear?

* Have you previously interacted with the FlightGear community? If so, how?

* Are you currently subscribed to the FlightGear Devel mailing list?

= FlightGear Candidate Projects =

TODO: put here suitable ideas for projects

== [[FlightGear Multiplayer Server]] ==
== FlightGear [[TerraGear]] - Scenery Compiler ==
== [[FlightGear Scenery Designer]] ==
== [[FlightGear Launch Control]] ==
== FlightGear [[TaxiDraw]] ==
== FlightGear [[JSBsim]] ==

GSoC: Candidate Projects

2010-03-19T19:50:26Z

Willie: /* People supporting a possible application & participation */

{{Stub}}

TODO: copy/paste feature requests and mini projects from other wiki pages that might make for good candidate projects, for a possible application/participation.

= Related Wiki Pages =
Wiki pages containing possible inspirations for candidate projects:
* [[Feature Requests / Proposals / Ideas]]
* [[FGFS Todo]]
* [[Bugs]]

= Project Application =
Mentor projects need to provide a minimum level of info about the project as detailed at http://code.google.com/soc/2008/org_signup.html
This section is meant to provide copy/paste text that may be pasted into the aforementioned application form, please feel free to populate with contents.

== Describe your Organization ==

* http://www.flightgear.org/introduction.html
* Open Source flight simulator framework
* written in C++
* multi-platform simulator
* has been in development for over a decade now
* licensed under GNU GPL
* framework used for various efforts (science, educational etc)
* recently released version 1.0
* goals of the project: [[Long Term Goals]]
* developed by contributors from all over the world
* many contributors have a professional background in aviation, sciences, maths etc.
* has created a wealth of related sub projects
* major features (property tree, highly configurable, XML-based configuration files, fully exposed internals)
* link to good reviews

== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? ==
* increase awareness of the project
* get new contributors interested in the flightgear project
* recruit additional manpower

== Did your organization participate in previous GSoC years? If so, please summarize your involvement and the successes and failures of your student projects. (optional) ==

No, the FlightGear project has not previously participated in GSoC.

== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? (optional) ==
No, there have been no previous applications.

== What license does your project use? ==
The GNU GPL

== URL for your ideas page ==
Link to this wiki page and appropriate subsection

== What is the main development mailing list for your organization? ==
flightgear-devel@lists.sourceforge.net

== Where is the main IRC channel for your organization? ==
#flightgear irc.freenode.net

== Does your organization have an application template you would like to see students use? If so, please provide it now. (optional) ==
Not yet, still needs to be created - can be done on this wiki page, and then be linked to directly.

== Who will be your backup organization administrator? Please enter their Google Account address. We will email them to confirm, your organization will not become active until they respond. (optional) ==

== Mentors ==
=== What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===

=== Who will your mentors be? Please enter their Google Account address separated by commas. If your organization is accepted we will email each mentor to invite them to take part. (optional) ===

== About the Program ==

=== What is your plan for dealing with disappearing students? ===

=== What is your plan for dealing with disappearing mentors? ===

=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===

=== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===

= People supporting a possible application & participation =
Willie Fleming -- willing to assist with organising mentors, students and projects. Ensure correct documentation is completed and submitted in a timely fashion.

= Eligible community members who would like to participate as students =
= Volunteer Mentors =
People who'd be willing to mentor a possible project:

= Template for Student Applications =
TODO: revamp, modify/add questions for possible students applications.

Please provide answers to the following questions:

* Have you previously contributed to open source projects?
** If so, which ones?

* Please provide some information about your programming background?

* What are your main interests in computers, aviation, flight simulation?

* Please state which of the following technologies you are familiar with and how proficient you consider yourself:
** C++ programming
** XML
** OpenGL
** TCP/IP networking
** cross-platform programming

* Have you previously contributed to the FlightGear project or any of its affiliated projects?
** If so, which ones and how exactly?

* How familiar do you consider yourself with the FlightGear project? (0-10)

* Do you have experience working with CVS?

* Why are you interested in contributing to FlightGear?

* What would be your preferred working area in FlightGear?

* Have you previously interacted with the FlightGear community? If so, how?

* Are you currently subscribed to the FlightGear Devel mailing list?

= FlightGear Candidate Projects =

TODO: put here suitable ideas for projects

== [[FlightGear Multiplayer Server]] ==
== FlightGear [[TerraGear]] - Scenery Compiler ==
== [[FlightGear Scenery Designer]] ==
== [[FlightGear Launch Control]] ==
== FlightGear [[TaxiDraw]] ==
== FlightGear [[JSBsim]] ==

Feature Requests / Proposals / Ideas

2008-03-18T23:21:52Z

Willie: added info and link to SourceForge, minor spelling corrections

: ''See also [[Bugs]]''

'''Please note:''' We now have a a tracker on SourceForge at [http://sourceforge.net/tracker/?group_id=583]. Please list your bug/feature request/enhancement/idea on SourceForge as well as here.

Occasionally, people join the FlightGear mailing lists offering to contribute to FlightGear and asking where they might start contributing, apparently often hoping for some sort of official "TODO" list or at least some sort of semi-official roadmap. Unfortunately, nothing like this exists so far for FlightGear and the closest thing to a "TODO" page, the "Goals page", has apparently not really been updated for several years.

So it is understandably hard for new community members to get a good grasp of the current development status and -progress, as well as to identify areas where FlightGear might use some improvement if they have not followed the recent mailing list discussions.
In addition, many developers find it often hard to come up with suggestions for "mini projects", not because there are not any such opportunities, but rather because there does not exist any sort of general schedule or development plan. However, FlightGear itself does indeed offer a very broad range of often exciting contribution possibilities, this page is dedicated to providing a collection of such ideas that were discussed on the mailing lists. Not all of these ideas are necessarily "mini projects", rather some of these can be quite complex efforts that were simply not pursued because of the very complexity.

Also, as this is a static page <strike>and no searchable bug tracking system,</strike> '''no longer true - see above re SourceForge tracker''' 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 features for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects, that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole, for example:

* [http://sourceforge.net/projects/taxidraw TaxiDraw-Taxiway Layouting]
* [http://sourceforge.net/projects/fgsd fgsd-FlightGear Scenery Designer]
* [http://sourceforge.net/projects/fgms FlightGear Multiplayer Server]
* [http://pigeond.net/flightgear/fgmap.html FlightGear Multiplayer Map]
* [http://www.terragear.org TerraGear-FlightGear Scenery Compiler Suite]
* [http://sourceforge.net/projects/fgrun fgrun-FlightGear GUI Launch Wizard]
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery Project]
* [http://mapserver.flightgear.org/ FlightGear GIS/Map Server])
* [http://www.simgear.org SimGear-FlightGear simulation kernel libs]
* [http://pigeond.net/flightgear/fglive.html FG Live CD]
* [http://squonk.abacab.org/dokuwiki/fgcom FGCOM - FlightGear Radio Comms]

'''IMPORTANT:''' before you actually start working on any of these efforts, it is important to subscribe to the [https://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear Developer's mailing list] to discuss your plans (alternatively you may also want to check out the FlightGear IRC channel: irc.flightgear.org #flightgear
), 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 and especially '''with the maintainer !!''' of the respective project before starting your work, because ideas listed on this page don't necessarily match the intended/planned direction of development.

{|
|__TOC__
|}

== 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
* [http://forums.avsim.net/dcboard.php?az=show_topic&forum=198&topic_id=260&mode=full The future for Flight Gear]
* http://simflyer.blogspot.com/2008/01/flightgear-10-mini-review.html
* http://linux.wordpress.com/2007/12/20/gaming-flightgear-100-released/

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.

=== General ===
* no version information available within GUI
* no licensing information available within GUI
* no detailed build information available within GUI (compiler, date, cflags/ldflags etc)
* no information about versions of linked dependencies within GUI

=== Platform Support/Misc ===
* significant initial download (>100MB) - might be a good idea to try to reduce the base package size where possible
* insufficient mac support
* lacking documentation
* webpage appearance
* outdated FAQ

=== Setup/Hardware Support ===
* non-intuitive joystick configuration
* GUI does not yet expose many of FlightGear's features that are available via command line
* no multi screen support

=== Startup ===
* non-integrated startup wizard (requires fgrun)
* significant startup times

=== Usage ===
* hardly localized UI: GUI, command line, error messages
* no localized help dialogs (basic commands, keys...)

=== Running ===
* lacking performance
* 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
* warnings and error messages are only rarely informative

=== Realism ===
* <strike>no realistic helicopter support</strike> (no longer true)
* hardly realistic scenery-missing/inappropriate textures, objects, landmarks. (this changed WRT textures already some time ago)
* not very advanced AI ATC
* no flight planning facility integrated/available (several 3rd party options)
* no support for weight & balance (and fuel) for aircraft (not true of YASim)
* currently not a suitable VFR simulator
* few buildings have proper night textures

=== Visuals ===
* not fully animated 3D models
* insufficient weather modelling and -effects
* non-standard GUI, not too appealing to many users
* no realistic water modelling (improving in OSG branch as of 11/2007)
* no moving map directly integrated in FlightGear
* no water effects for ocean and rivers (waves/streams)
* no nice passage of taxiways at airports (the textures aren't abound in each other)

=== Interactivity ===
* no integrated tutorial/ground school or learning mode (No longer true)
* no real interactive mission (scenario/adventure) support (lack of evaluation facilities to assess user's performance)
* no combat support
* no Voice ATC
* no ATC facilities for real life controllers (VATSIM like)
* no scripted demo flights that users could "play" to see a simple flight (pattern) including landing

=== Avionics ===
* currently no glass cockpit support
* no support for advanced avionics that would require drawing complex images (i.e. charts) to instrument screens

=== Modding ===
* non-intuitive scenery modification and installation
* non-intuitve aircraft modification and installation
* non-intuitive aircraft panel creation (lack of GUI frontend)
* airports/runways cannot easily be modified/re-created
* non-configurable approach lighting for runways
* no blade element FDM

== 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.
* <del>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() )</del> available: /sim/frame-rate-throttle-hz
* 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
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13570.html Currently, aircraft featuring multiple different startup configurations (i.e. cold/idle) have to be implemented using separate *-set.xml files for each individual situation], however it would make sense to consider a more flexible approach, where all available startup-situations are simply enumerated in the aircraft *-set.xml (i.e. as referenced separate PropertyList-encoded XML files, saved within a corresponding "situation"), so that a "loadxml" command or Nasal script could eventually overwrite the default state with the state from the desired startup situation; later on possibly with an option, allowing users to view all available startup situations and switch at runtime.

=== 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
* <strike>extend nasal interpreter to provide functions for loading and saving XML files directly</strike> '''DONE''', 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 )
* <strike>expose the nasal interpreter via network/telnet, so that scripts can be remotely inserted and executed.</strike> this can be basically done already by writing new code to properties and executing the code in the property
* 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 simgear/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 more so, due to TerraSync's dependency to rsync, TerraSync users are mostly Unix/Linux users right now. However, FlightGear being a cross platform project should whenever possible try to target a maximally broad audience. That's why it would probably make sense to port the TerraSync functionality over to FG, so that 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
* given the fact that an increasing number of more complex components in FlightGear is being implemented using the Nasal scripting subsystem (which happens also to be the first choice for non-programmers for obvious reasons), and due to the possible [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13017.html challenges] (when implementing low-level systems) resulting from the way the interpreter is currently integrated/run in FlightGear (i.e. sequentially, framerate-limited: difficult to provide reliable low-latency timing/update rates), it might be worth to consider providing an additional, alternative/separate interpreter context for FlightGear-related efforts that do not necessarily have to be run directly within the native interpreter context (because they may not need to access internals beyond what the PropertyTree already provides), that way it should become possible to run more sophisticated "scripts" in a semi-standalone fashion while also providing decent and reliable update intervals. This could for example be achieved, by either running one interpreter in a different thread (that would only communicate with the main thread/FG core using the property tree as IPC mechanism (i.e. deemed to be only a provider/consumer of PropertTree nodes) or possibly even by using a separate process for such a different interpreter instance, where the communications could likewise be handled using the PropertyTree exclusively, in that case however making use of the networking facilities already provided by FlightGear, to enable getting/setting properties across process boundaries. Eventually, such a facility might support additional efforts, where users/non-programmers want to implement time-critical components in FG, using FG means but to whom implementing such projects in C/C++ may not be a viable option, or even a showstopper-because they may lack the required familiarity with the core source code, C/C++ programming experience or both. In such a scenario, even a "stripped down" interpreter, be it run separately as a thread or process, would still be a much more feasible option than going the C/C++ route for most users.

=== 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)
* <strike>add support for enhanced water modeling, so that we can start implementing water aircraft with floats etc.</strike>-'''in progress as of 11/2007'''
* 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. (NOTE: [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15388.html this is currently (01/2008) being tackled])
* 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 (FWIW, threaded PropertyTree implementations are provided by these two open source libraries: [http://pocoproject.org/poco/info/index.html poco] [http://www.boost.org boost])
* 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 and in order to modify scenery appearance [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15699.html according to region specific information] 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)
* <strike>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</strike>-'''Support for helicopter flight simulation has been significantly improved meanwhile, and is still being worked on'''
* 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 ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13205.html related mailing list discussion from nov/2007]).
* 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16047.html]
* 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 [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15761.html 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. '''NOTE: FlightGear has been branched and the main branch is based on OSG'''
* factor out scenery system to allow integration with other scenery systems (see mailing list discussions) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13125.html Demeter discussion]
* 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/ )

== See also ==

: ''Some ideas are at [[Project Infrastructure Enhancements]]''

Feature Requests / Proposals / Ideas

2008-03-18T23:18:05Z

Willie: spelling

: ''See also [[Bugs]]''

Occasionally, people join the FlightGear mailing lists offering to contribute to FlightGear and asking where they might start contributing, apparently often hoping for some sort of official "TODO" list or at least some sort of semi-official roadmap. Unfortunately, nothing like this exists so far for FlightGear and the closest thing to a "TODO" page, the "Goals page", has apparently not really been updated for several years.

So it is understandably hard for new community members to get a good grasp of the current development status and -progress, as well as to identify areas where FlightGear might use some improvement if they have not followed the recent mailing list discussions.
In addition, many developers find it often hard to come up with suggestions for "mini projects", not because there are not any such opportunities, but rather because there does not exist any sort of general schedule or development plan. However, FlightGear itself does indeed offer a very broad range of often exciting contribution possibilities, this page is dedicated to providing a collection of such ideas that were discussed on the mailing lists. Not all of these ideas are necessarily "mini projects", rather some of these can be quite complex efforts that were simply not pursued because of the very complexity.

Also, as this is a static page and no searchable bug tracking system, we have decided to categorize these "mini projects" into groups ranging from "minor", "intermediate", "major" and "huge" to give new developers an impression of the estimated complexity of the various ideas.

Please note: while this list is only meant to provide an overview of desirable short- and long-term features for FlightGear itself, there are meanwhile various interesting FlightGear-related co-projects, that you might want to check out for other interesting possibilities to contribute to the FlightGear community as a whole, for example:

* [http://sourceforge.net/projects/taxidraw TaxiDraw-Taxiway Layouting]
* [http://sourceforge.net/projects/fgsd fgsd-FlightGear Scenery Designer]
* [http://sourceforge.net/projects/fgms FlightGear Multiplayer Server]
* [http://pigeond.net/flightgear/fgmap.html FlightGear Multiplayer Map]
* [http://www.terragear.org TerraGear-FlightGear Scenery Compiler Suite]
* [http://sourceforge.net/projects/fgrun fgrun-FlightGear GUI Launch Wizard]
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery Project]
* [http://mapserver.flightgear.org/ FlightGear GIS/Map Server])
* [http://www.simgear.org SimGear-FlightGear simulation kernel libs]
* [http://pigeond.net/flightgear/fglive.html FG Live CD]
* [http://squonk.abacab.org/dokuwiki/fgcom FGCOM - FlightGear Radio Comms]

'''IMPORTANT:''' before you actually start working on any of these efforts, it is important to subscribe to the [https://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear Developer's mailing list] to discuss your plans (alternatively you may also want to check out the FlightGear IRC channel: irc.flightgear.org #flightgear
), 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 and especially '''with the maintainer !!''' of the respective project before starting your work, because ideas listed on this page don't necessarily match the intended/planned direction of development.

{|
|__TOC__
|}

== 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
* [http://forums.avsim.net/dcboard.php?az=show_topic&forum=198&topic_id=260&mode=full The future for Flight Gear]
* http://simflyer.blogspot.com/2008/01/flightgear-10-mini-review.html
* http://linux.wordpress.com/2007/12/20/gaming-flightgear-100-released/

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.

=== General ===
* no version information available within GUI
* no licensing information available within GUI
* no detailed build information available within GUI (compiler, date, cflags/ldflags etc)
* no information about versions of linked dependencies within GUI

=== Platform Support/Misc ===
* significant initial download (>100MB) - might be a good idea to try to reduce the base package size where possible
* insufficient mac support
* lacking documentation
* webpage appearance
* outdated FAQ

=== Setup/Hardware Support ===
* non-intuitive joystick configuration
* GUI does not yet expose many of FlightGear's features that are available via command line
* no multi screen support

=== Startup ===
* non-integrated startup wizard (requires fgrun)
* significant startup times

=== Usage ===
* hardly localized UI: GUI, command line, error messages
* no localized help dialogs (basic commands, keys...)

=== Running ===
* lacking performance
* 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
* warnings and error messages are only rarely informative

=== Realism ===
* <strike>no realistic helicopter support</strike> (no longer true)
* hardly realistic scenery-missing/inappropriate textures, objects, landmarks. (this changed WRT textures already some time ago)
* not very advanced AI ATC
* no flight planning facility integrated/available (several 3rd party options)
* no support for weight & balance (and fuel) for aircraft (not true of YASim)
* currently not a suitable VFR simulator
* few buildings have proper night textures

=== Visuals ===
* not fully animated 3D models
* insufficient weather modelling and -effects
* non-standard GUI, not too appealing to many users
* no realistic water modelling (improving in OSG branch as of 11/2007)
* no moving map directly integrated in FlightGear
* no water effects for ocean and rivers (waves/streams)
* no nice passage of taxiways at airports (the textures aren't abound in each other)

=== Interactivity ===
* no integrated tutorial/ground school or learning mode (No longer true)
* no real interactive mission (scenario/adventure) support (lack of evaluation facilities to assess user's performance)
* no combat support
* no Voice ATC
* no ATC facilities for real life controllers (VATSIM like)
* no scripted demo flights that users could "play" to see a simple flight (pattern) including landing

=== Avionics ===
* currently no glass cockpit support
* no support for advanced avionics that would require drawing complex images (i.e. charts) to instrument screens

=== Modding ===
* non-intuitive scenery modification and installation
* non-intuitve aircraft modification and installation
* non-intuitive aircraft panel creation (lack of GUI frontend)
* airports/runways cannot easily be modified/re-created
* non-configurable approach lighting for runways
* no blade element FDM

== 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.
* <del>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() )</del> available: /sim/frame-rate-throttle-hz
* 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
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13570.html Currently, aircraft featuring multiple different startup configurations (i.e. cold/idle) have to be implemented using separate *-set.xml files for each individual situation], however it would make sense to consider a more flexible approach, where all available startup-situations are simply enumerated in the aircraft *-set.xml (i.e. as referenced separate PropertyList-encoded XML files, saved within a corresponding "situation"), so that a "loadxml" command or Nasal script could eventually overwrite the default state with the state from the desired startup situation; later on possibly with an option, allowing users to view all available startup situations and switch at runtime.

=== 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
* <strike>extend nasal interpreter to provide functions for loading and saving XML files directly</strike> '''DONE''', 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 )
* <strike>expose the nasal interpreter via network/telnet, so that scripts can be remotely inserted and executed.</strike> this can be basically done already by writing new code to properties and executing the code in the property
* 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 simgear/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
* given the fact that an increasing number of more complex components in FlightGear is being implemented using the Nasal scripting subsystem (which happens also to be the first choice for non-programmers for obvious reasons), and due to the possible [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13017.html challenges] (when implementing low-level systems) resulting from the way the interpreter is currently integrated/run in FlightGear (i.e. sequentially, framerate-limited: difficult to provide reliable low-latency timing/update rates), it might be worth to consider providing an additional, alternative/separate interpreter context for FlightGear-related efforts that do not necessarily have to be run directly within the native interpreter context (because they may not need to access internals beyond what the PropertyTree already provides), that way it should become possible to run more sophisticated "scripts" in a semi-standalone fashion while also providing decent and reliable update intervals. This could for example be achieved, by either running one interpreter in a different thread (that would only communicate with the main thread/FG core using the property tree as IPC mechanism (i.e. deemed to be only a provider/consumer of PropertTree nodes) or possibly even by using a separate process for such a different interpreter instance, where the communications could likewise be handled using the PropertyTree exclusively, in that case however making use of the networking facilities already provided by FlightGear, to enable getting/setting properties across process boundaries. Eventually, such a facility might support additional efforts, where users/non-programmers want to implement time-critical components in FG, using FG means but to whom implementing such projects in C/C++ may not be a viable option, or even a showstopper-because they may lack the required familiarity with the core source code, C/C++ programming experience or both. In such a scenario, even a "stripped down" interpreter, be it run separately as a thread or process, would still be a much more feasible option than going the C/C++ route for most users.

=== 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)
* <strike>add support for enhanced water modeling, so that we can start implementing water aircraft with floats etc.</strike>-'''in progress as of 11/2007'''
* 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. (NOTE: [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15388.html this is currently (01/2008) being tackled])
* 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 (FWIW, threaded PropertyTree implementations are provided by these two open source libraries: [http://pocoproject.org/poco/info/index.html poco] [http://www.boost.org boost])
* 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 and in order to modify scenery appearance [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15699.html according to region specific information] 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)
* <strike>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</strike>-'''Support for helicopter flight simulation has been significantly improved meanwhile, and is still being worked on'''
* 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 ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13205.html related mailing list discussion from nov/2007]).
* 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16047.html]
* 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 [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15761.html 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. '''NOTE: FlightGear has been branched and the main branch is based on OSG'''
* factor out scenery system to allow integration with other scenery systems (see mailing list discussions) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13125.html Demeter discussion]
* 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/ )

== See also ==

: ''Some ideas are at [[Project Infrastructure Enhancements]]''

Bugs

2008-03-18T21:40:05Z

Willie: added reminder to use SouceForge tracker

: ''See also [[Feature Requests / Proposals / Ideas]]''

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

'''Please note:''' We now have a a tracker on SourceForge at [http://sourceforge.net/tracker/?group_id=583]. Please list your bug/feature request/enhancement/idea on SourceForge as well as here.

'''Please note:''' if you intend to work on any of these items, please make sure to first subscribe to the [https://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear Devel mailing list] to discuss your plans in detail, alternatively you may also want to check out the FlightGear IRC channel: irc.flightgear.org #flightgear

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Airport lighting in poor weather. ====

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during conditions of low visibility and/or low ceiling, and also turned on if requested by the pilot. For details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

The code to turn lights on and off is in simgear/scene/tgdb/obj.cxx. (Formerly it was in tileentry.cxx)
* All along, runway and taxiway lights have been on during the hours of darkness, as determined from the angle of the sun.
* As of version 0.9.10, runway lights and taxiway lights are turned on automatically if visibility less than 5000 meters, day or night. Apparently this is based on flight visibility, not on surface visibility (which would be more appropriate). Consequently, as you descend through a haze layer into improving visibility you can watch as the lights turn themselves off (which is not appropriate). Also: apparently the code treats a subset of approach lights as part of the runway lights, so that subset comes on also. The remaining approach lights appear to be permanently off.
* There is still no code to turn on the lights depending on ceiling.

At non-towered airports, the lights are usually pilot-controlled,
via radio, no matter what the weather. Presently the code treats them the same as towered airports. (Arguably this should be considered a wish-list item rather than a bug. [[User:Alfozavr|Alfozavr]])

It is important to get the lighting right, because it affects both the
legality and the practicality of performing instrument approaches
in marginal conditions.

==== Holes in the ground. ====

<del>Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes (missing scenery tiles) in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.</del>

This problem has disappeared in the latest FlightGear CVS version as of 2007-07-31, using OSG 2.0.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://scenemodels.flightgear.org/ Scenery Objects Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the respective [http://scenemodels.flightgear.org/download/ download page] in a central position...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and prints a bogus Date.

The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.

== Fixed Bugs ==

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
* When parked, the ball was pegged to one side.
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi. In a real aircraft, a pilot who found the
inclinometer pegged would cancel the flight before even starting
the engine.

Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:

*velocities/vdot-fps
*velocities/a-pilot-y-ft sec2
*velocities/n-pilot-y-norm

* '''This bug has been fixed in 0.9.11.'''

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout. This made both the log and the console record hard to interpret.

* '''This bug has been fixed.'''

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].