Category:Aircraft TODO

From wiki.flightgear.org

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

This category lists all the aircraft that are currently under development in Flightgear. The individual aircraft page lists the completion status of the aircraft, as well as things that are still missing, have bugs or could need some more work to do.

When editing the TODO section of an aircraft page, please use the term 'missing' for any element an aircraft is lacking, such as 'missing flap control lever" so it is easy to see what is missing in the bullet points. It is also a good idea to divide points between 'fixes' and 'improvements' or things that are nice but not necessary. Please form the improvements as a polite request for others to contribute like "requesting volunteers to make virtual cockpit."

Please consult Template:Aircraft should you wish to create a new page for a new aircraft.

Contents 1 Standard Aircraft Folder Structure 2 Recommended set of Standard Files to be provided 3 Usability recommendations concerning high-fidelity contributions of complex aircraft 4 Modeling IFR Aircraft & Cockpits

Standard Aircraft Folder Structure

The majority of cleanly structured aircraft share (more or less) a pretty similar folder layout.

While the suggested structure may seem overly verbose, using this or a similar structure for your own work ensures that your aircraft is pretty intuitively organized and that key components are kept in distinct places (and can be easily identified), so that future maintenance is simplified because of the self-documenting nature of the underlying file hierarchy.

Please note: While the following folder layout has merely advisory character, it can be considered a product of "convention by evolution": As aircraft emulations in FlightGear are getting more and more complex, it is also getting more complicated to maintain an overview of aircraft components and their implementation files, including their mutual relationships and purposes.

Furthermore, having aircraft authors organize their aircraft this way, also ensures that future contributors can more easily find, borrow and understand certain code snippets from existing work, so that they don't have to waste time trying to understand the purpose of the various files included.

• FDMs - for various FDM configs that are supported
• Engines - for various different engines supported by the FDMs (possibly beneath FDM folder?)
• Models - for 3D models
• Textures - for aircraft-specific general Textures
• Liveries - for aircraft-specific livery textures
• Splashs - for aircraft-specific splash screens
• Panels (or cockpits) - for 2D/3D cockpit panels (maybe categorized into 2D/3D?)
• Huds - for aircraft-specific HUDs
• Views - for aircraft-specific custom views
• Instruments - for aircraft specific instruments (possibly with its own Textures subfolder, and if necessary differentiating between 2D/3D)
• Sounds - for aircraft-specific sounds
• Materials - aircraft-specific material definitions
• Autopilot - Autopilot configuration
• Systems - for aircraft-specific system modelling files (such as the electrical system)
• Dialogs - for aircraft-specific dialog resources
• Help - for aircraft-specific help resources
• Checklists - aircraft-specific XML checklists
• Situations - aircraft-specific startup situations (i.e. cold, idle, in-air, approach)
• Keybindings - aircraft-specific key bindings
• Nasal - for aircraft-specific Nasal scripts
• Docs - for aircraft-specific documentation
• XMLs - for aircraft specific XML files.
• Translations - translation mapping of aircraft-specific texts
• Resources - for all sorts of aircraft specific development resources that may be required by other developers to continue development of an aircraft (i.e. data, images, artwork etc) but that isn't officially included in any of the other folders because it isn't yet used. That is, such "resource" folders could/should be automatically excluded from the script that is currently used to create the default base package for distribution.

Recommended set of Standard Files to be provided

Additionally, all aircraft are recommended to have files such as the following included (possibly in a directory named "contrib"?):

• limits.xml - XML file configuring aircraft specific flight regime limits, i.e. to provide crash detection parameters
• AUTHORS.txt - list original authors and contributors, including their work
• CHANGELOG.txt - list recent changes to the aircraft
• README.txt - general information about aircraft
• HELP.txt - Help-related information
• FEATURES.txt - summary of supported features in plaintext
• TODO.txt - things that yet need to be done
• FILES.txt - a description of all relevant files and their purposes
• LICENSE.txt - detailing licensing and distribution
• LAYOUT.txt - file detailing layout of folder (i.e. contents of this paragraph)
• thumbnail.jpg - thumbnail image of aircraft for use by GUI/web frontends (standard size 171x128 for fgfs thumbnails )
• thumbnail.txt - optional file containing description being displayed on the web as the thumbnail's caption

Also, providing such a set of standard files describing your work in detail, makes it possible for arbitrary web and gui frontends to optionally provide very detailed information about the progress of your work, so that automated scripts could be used to compile comprehensive summaries for all base package aircraft providing such files.

Usability recommendations concerning high-fidelity contributions of complex aircraft

Please note: as FlightGear has gained a certain momentum, starting to attract an increasing number of contributers dedicated to developing more and more realistic aircraft (featuring very high fidelity simulations of complex aircraft systems) the required learning curve to master these very contributions has recently become increasingly steep.

In fact, there is now a number of aircraft in FlightGear/CVS that cannot be easily started up, taxied or flown without properly following procedures that are often heavily based on real life procedures.

While this high level of realism illustrates the capabilities of FlightGear and its community and is thus very desirable and evidence of FlightGear's success, it is also important to keep in mind that this level of realism may make FlightGear less appealing to new users without the corresponding background knowledge or without the direct willingness to dedicate the time required to actually be able to use these contributions. Obviously, realism in FlightGear is highly desirable, however nonetheless there are ways to enable new users to more easily make use of such contributions as well.

For such complex aircraft, it is therefore recommended to continue to provide supporting infrastructure in the form of:

• different default (startup) scenarios (cold, hot)
• scripted facilities to help changing the aircraft's configuration more easily at runtime (i.e. scripted autostart)
• scripted interactive Tutorials to help familiarize new users with that particular aircraft and relevant procedures
• integrated aircraft checklists detailing relevant data (i.e. V speeds) and procedures (i.e. in the form of XML dialogs: pre-start,pre-taxi,takeoff,landing etc)
• other relevant documentation
• aircraft-specific configuration files for the generic autopilot, implementing basic modes to control the a/c (only applicable if the corresponding aircraft doesn't already provide an autopilot)

Good examples for pretty realistic complex aircraft following this line of thought are among others:

• PA34-200T Seneca II

...

Modeling IFR Aircraft & Cockpits

If you are interested in modeling aircraft that feature realistic IFR cockpit panels, you'll probably want to check out http://wiki.flightgear.org/index.php/Category:IFR_Aircraft