User:Johan G/Howto:Create an aircraft

From FlightGear wiki
< User:Johan G
Revision as of 14:09, 28 April 2019 by Johan G (talk | contribs) (Johan G moved page Creating an aircraft to Howto:Create an aircraft: Better suited name)
Jump to navigation Jump to search

When creating a new aircraft in FlightGear there is really only a few things needed to make it "work", but to make it work well there is a lot of things that can be done and some things that need consideration even before starting.

Creating a really, really good aircraft can take many months if not years and often the commitment of more than one author. In addition to make it last it needs maintenance.

Tip  As with many things it is often a good idea to look at existing work to see how other people have done things and perhaps comparing different ways to get various problems solved.
Note  This article also relates to other controllable craft, like for example cars and ships.

Before starting

Unless you are going to make a very simple aircraft for your own use there is some things to consider before starting development.


What is the purpose of the new aircraft?

  • Just getting the basics of creating an aircraft with the least amount of work?
  • Make something that looks and behave somewhat like a certain aircraft?
  • Make a "study level" aircraft that might need the pilot to read manuals?

Depending on how much data you have and how much time you (and any team mates) are willing to spend the approach will be quite different.

Maintenance, distribution and licensing

If you work on your aircraft over time or might later work on the aircraft in a group, using some revision control software will help immensely, both when developing on your copy of the repository, together with other, and when trying to narrow down when and where bugs got introduced. One of the more popular ones in the FlightGear community currently (2019) is Git This is a link to a Wikipedia article. Hosting it as a repository on a hosting site like for example GitHub, SourceForge or GitLab will also be of help (and it does not hurt to have a backup).

As FlightGear evolves over time your aircraft have to be maintained over time as there will be made changes in FlightGear that may make your aircraft incompatible. There is also new features added over time that might be nice to have added to your aircraft.

If you are going to add the aircraft to FlightGear's official aircraft repository, FGAddon you will need to have it licensed as GNU General Public License, version 2 or later (commonly abbreviated as GPLv2+). If you are going to use it it is highly recommendable that you skim through the full license as there are some common misconceptions (yes, you will copyright your work, and yes, people can copy and sell your work, and no, people who have copied and added to your work is not obligated to contribute upstream to your copy). You will also need to make sure that all the content of your aircraft is compatible with that license, for example by either making it yourself or using GPLv2, CC0 or public domain This is a link to a Wikipedia article content. Kep in mind that sometimes it pays off to ask an author, modeler or photographer if you can use his work under GLPv2+.

If you absolutely do not want it to be reused commercially you should not use GPL, but then you could also not add it to the official repository. If you use a too restricted license, for example only allowing you to make changes, it will over time be incompatible with FlightGear unless you maintain it. In contrast there are aircraft in the official repository still being maintained even though previous maintainers have passed away.

Main parts

A FlightGear aircraft consists of several parts. The bare minimum is probably exemplified by the UFO, though it has some features that are not required to make it functional (one can for example use it to place models in the scenery).

Typically is an aircraft is collection of files and directories. Commonly there is at least:

  • The aircraft-set.xml file which sets up most of the aircraft for FlightGear.
  • 3D models and XML files that defines any animations and what will animate them.
  • One or more flight dynamics model (FDM) XML files defining how the aircraft will act due to control input and the environment around it. (To add to the confusion the part of FlightGear that handles that data is also called an FDM.)

In addition to that there are usually:

  • XML files defining what your aircraft will sound like
  • Nasal modules, scripts written in FlightGear's embedded interpreted language Nasal.
  • XML files defining systems though for some of the FDMs that can be defined and greatly expanded as a part of the FDM files.

The property tree

1rightarrow.png See Property tree for the main article about this subject.

Before we get any further the property tree need to be mentioned. It is backbone to how FlightGear and its aircraft is configured and run is how it passes information between different parts of the software and aircraft.

FlightGear uses numerous key-value pair properties arranged in a tree. When you for example increase the throttle lever on your joystick, FlightGear read that change through the joystick, the driver, and through the joystick configuration file assign the change on the throttle axis to a certain property in the property tree. That property is then read by the FDM and increases the engine throttle, which depending on the propulsion of the aircraft in the FDM add wind over the aircraft and due to the FDM changes the airflow and pressures on and around the aircraft, as well as changes engine and environment properties that drives instrument properties. In essence most of the communication is done through the property tree.

When you configure your aircraft you will mainly do that through PropertyList XML files, which is properties "serialized" to an XML format that FlightGear use to read in and set up properties with.

While you develop your aircraft you might want to check the Property browser dialog in FlightGear to see what properties you want to read and what properties you want to affect. It is also very useful for debugging.

Note  If you will be using the JSBSim FDM, keep in mind that while those configuration files also are serialized XML files, they are not compatible with the PropertyList XML files.

The aircraft-set.xml file

1rightarrow.png See aircraft-set.xml for the main article about this subject.

When FlightGear starts up, the aircraft-set.xml file (or rather <aircraft-name>-set.xml file) is the main source from which FlightGear read all the other other files of the aircraft. It is also where a lot of properties are configured (in essence those that are not st up by other files).

In that file, or linked files, you can for example set up:

3D Models, liveries, shaders and animations

1rightarrow.png See Modeling - Getting Started for the main article about this subject.

FlightGear uses a combination of 3D models in AC3D (*.ac) format and PropertyList XML animation files for binding animations of objects in the AC3D files to properties in the property tree.

FlightGear uses liveries to paint the aircraft, which also can be spiced up using shaders.

When you encounter another pilot in multiplayer FlightGear among other information get a name of a model or animation PropertyList XML file and a fallback model if the other aircraft has that defined. To visualize the other aircraft FlightGear looks for that model in this order:

  1. The full aircraft if you have that installed, in essence: $FG_ROOT/Aircraft/Aircraft-name/Models/Model-and-animation-configuration.xml
  2. An AI aircraft if there is one with the same name in the AI directory, in essence: $FG_ROOT/AI/Aircraft/Aircraft-name/Models/Model-and-animation-configuration.xml
  3. A fallback model if the other aircraft have one defined
  4. The default model is used (the infamous yellow and blue glider, unless another model is used)

Flight dynamics model

1rightarrow.png See Flight dynamics model for the main article about this subject.

Currently (2019) FlightGear uses two FDMs (three if we include the UFO FDM), YASim and JSBSim. If you have a full set of wind tunnel and flight test data (and the time to implement all that data in full) JSBSim is the one to use. If you only have some data, like dimensions and basic performance data, YASim have typically been used. These days one can make a basic JSBSim from such limited data using the Aeromatic tool.

If using JSBSim, rather complex systems can be built and be tightly integrated with the FDM.


1rightarrow.png See Howto:Add sound effects to aircraft for the main article about this subject.

Nasal scripting

1rightarrow.png See Nasal for the main article about this subject.

Nasal is a interpreted garbage collecting scripting languages that both can be embedded in PropertyList XML files and be used separately in Nasal modules. It can access the property tree both for reading and writing and can be used for pretty much anything you can imagine and that your computer can run at a reasonable speed.

Unfortunately everything in FlightGear is run in a big loop, so larger computations might need to be spread out in time. However there are lots of things you can do to improve the performance of your nasal code.

If you need things to manipulate properties continuously, consider using property rules or JSBSim systems instead.

Related content


Readme files

Source code