User:Johan G/Howto:Create an aircraft: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Johan G moved page Creating an aircraft to Howto:Create an aircraft: Better suited name)
(Extending)
Line 3: Line 3:
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.
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.}}
{{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.}}
{{note|This article also relates to other controllable craft, like for example cars and ships.}}


== Before starting ==
== Before starting ==
Line 16: Line 16:
* Make a "study level" aircraft that might need the pilot to read manuals?
* 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.
Depending on this and how much data that is available and how much time you (and any team mates) are willing to spend the approach will be quite different.


=== Maintenance, distribution and licensing ===
=== Maintenance, distribution and licensing ===
{{hatnote |If you are just going to make a one-shot "quick" aircraft to just get a hang of how to make an aircraft that you will keep for yourself you can ignore this.}}
{{hatnote |If you are just going to make a one-shot "quick" aircraft to just get a hang of how to make an aircraft that you will keep for yourself you can ignore this.}}


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 {{wikipedia |Git}}.  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).
==== Git and repositories ====
Using version control software will help immensely if you work on your aircraft over time or might later work on the aircraft in a group, 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 {{wikipedia |Git}}.  Hosting your aircraft 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).


==== Adding Your aircraft to the official hangar ====
If you are going to add the aircraft to [[FGAddon]], FlightGear's official aircraft hangar, you will need to have it licensed as "''[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU General Public License, version 2]'' or later" (commonly abbreviated as ''GPLv2+'').  If you are going to use GPLv2 it is highly recommended 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, [https://creativecommons.org/share-your-work/public-domain/cc0/ CC0] or {{wikipedia|public domain}} content.  Kep in mind that sometimes it pays off to ask an author, modeler or photographer if you can use his work under GLPv2+.
==== Maintenance and licenses ====
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.
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 [https://www.gnu.org/licenses/old-licenses/gpl-2.0.html 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, [https://creativecommons.org/share-your-work/public-domain/cc0/ CC0] or {{wikipedia |public domain}} 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 itIn contrast there are aircraft in the official repository still being maintained even though previous maintainers have passed away.
 
<!-- === File structure === -->


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 repositoryIf 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 itIn contrast there are aircraft in the official repository still being maintained even though previous maintainers have passed away.
== The property tree ==
{{main article|Property tree}}
 
Before we get any further the ''property tree'' need to be mentioned.  It is how FlightGear and its aircraft is configured and run is how it passes information withing and 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 assigns 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 propertiesIn 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 affectIt 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.}}


== Main parts ==
== Parts of an aircraft in FlightGear ==
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 [[Howto:Place 3D objects with the UFO|place models in the scenery]]).
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 [[Howto:Place 3D objects with the UFO|place models in the scenery]]).


Line 35: Line 53:


* The '''<code>''aircraft''-set.xml</code>''' file which sets up most of the aircraft for FlightGear.
* The '''<code>''aircraft''-set.xml</code>''' file which sets up most of the aircraft for FlightGear.
* '''3D models''' and XML files that defines any animations and what will animate them.
* '''3D models''' and XML files that defines any pick animations, other animations, and what will animate the 3D models.
* 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.)
* 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.)


Line 41: Line 59:
* XML files defining what your aircraft will sound like
* XML files defining what your aircraft will sound like
* '''Nasal modules''', scripts written in FlightGear's embedded interpreted language Nasal.
* '''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.
* XML files defining '''systems''' though for some of the FDMs that can be defined and greatly expanded as a part of the FDM files. They could for example be
** The [[autopilot]]
** The electrical systems
** The [[FGproperties/Systems/Pitot|pitot-static system]] (that deliver the static and dynamic pressures used for airspeed and altitude instruments)
** [[Howto:Implement a Fly-By-Wire System for Airliners|Fly-by-wire]] (FBW) or conventional flight control system (FCS)


=== The property tree ===
== Parts of a basic aircraft ==
{{main article|Property tree}}
=== Basic aircraft-set.xml file ===
 
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 ===
{{main article|aircraft-set.xml}}
{{main article|aircraft-set.xml}}


When FlightGear starts up, the <code>''aircraft''-set.xml</code> file (or rather <code>''<nowiki><</nowiki>aircraft-name<nowiki>></nowiki>''-set.xml</code> 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).
When FlightGear starts up, the <code>''aircraft''-set.xml</code> file (or rather <code>''<nowiki><</nowiki>aircraft-name<nowiki>></nowiki>''-set.xml</code> 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:
In that file, or linked files, you set up:
* What 3D models and animations to use
* What 3D models and animations to use
* The FDM defining how the aircraft handles
* The FDM defining how the aircraft handles
* A [[FGproperties/Systems/Pitot|pitot-static system]] driving the airspeed and altitude instruments
If you will distribute the aircraft it may also help if you set up:
* A [[Aircraft rating system|rating]] that describes how complete the aircraft is
* A [[Aircraft rating system|rating]] that describes how complete the aircraft is
* What [[MP Fallback models|fallback model]] other users will have loaded on MP if your aircraft is not installed on their computer.
* What [[MP Fallback models|fallback model]] other users will have loaded on MP if your aircraft is not installed on their computer.
* Additional [[Howto:Reassign keyboard bindings|keyboard bindings]]
* [[Catalog metadata|Metadata]] used when creating hangar catalogs for the [[Aircraft Center]]
* [[Catalog metadata|Metadata]] used when creating hangar catalogs for the [[Aircraft Center]].
* [[Walk view]] configuration
* [[Howto:Implement aerial refueling capability|Aerial refueling]]
* [[Canvas]] elements, such as for example a [[Canvas HUD]]
* Systems built with [[Autopilot configuration reference|property rules]]


=== 3D Models, liveries, shaders and animations ===
=== 3D Models and animations ===
{{main article |Modeling - Getting Started}}
{{main article|Modeling - Getting Started}}


FlightGear uses a combination of [[Howto:3D Aircraft Models|3D models in AC3D]] (<code>*.ac</code>) format and [[Howto:Animate models|PropertyList XML animation files]] for binding animations of objects in the AC3D files to properties in the property tree.
FlightGear uses a combination of [[Howto:3D Aircraft Models|3D models in AC3D]] (<code>*.ac</code>) format and [[Howto:Animate models|PropertyList XML animation files]] for binding animations of objects in the AC3D files to properties in the property tree.
FlightGear uses [[Howto:Edit a livery|liveries]] to paint the aircraft, which also can be spiced up using [[shaders]].


When you encounter another pilot in [[Howto:Multiplayer|multiplayer]] FlightGear among other information get a name of a model or animation PropertyList XML file and a [[MP Fall back models|fallback model]] if the other aircraft has that defined.  To visualize the other aircraft FlightGear looks for that model in this order:
When you encounter another pilot in [[Howto:Multiplayer|multiplayer]] FlightGear among other information get a name of a model or animation PropertyList XML file and a [[MP Fall back models|fallback model]] if the other aircraft has that defined.  To visualize the other aircraft FlightGear looks for that model in this order:
Line 87: Line 93:


=== Flight dynamics model ===
=== Flight dynamics model ===
{{main article |Flight dynamics model}}
{{main article|Flight dynamics model}}
 
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, but these days one can make a basic JSBSim from such data using the [[Aeromatic]] tool.
 
== More advanced aircraft parts ==
=== More aircraft-set.xml file items ===
* Additional [[Howto:Reassign keyboard bindings|keyboard bindings]]
* [[Walk view]] configuration
* [[Howto:Implement aerial refueling capability|Aerial refueling]]
* [[Canvas]] elements, such as for example a [[Canvas HUD]]
* Systems built with [[Autopilot configuration reference|property rules]]
* The [[Instant Replay|instant replay]] feature
* What [[Howto:Transmit properties over MP|properties to send over multiplayer]] that are for example used to drive animations etc.
 
=== Spicing up the 3D model ===
You can make [[Howto:Edit a livery|liveries]] to show your aircraft in different paint schemes


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.
Through [[Howto:Animate models#Direct manipulation animations|pick, knob/slider, and touch animations]] you can also use 3D models as interfaces, like for example buttons, switches and levers.


If using JSBSim, rather complex systems can be built and be tightly integrated with the FDM.
In addition [[shader]]s can do a lot for the aircraft's appearance.


=== Sound ===
=== Sound ===
{{main article |Howto:Add sound effects to aircraft}}
{{main article|Howto:Add sound effects to aircraft}}


=== Nasal scripting ===
=== Nasal scripting ===
{{main article |Nasal}}
{{main article|Nasal}}


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.
Nasal is a interpreted garbage collecting scripting language 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.
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 [[Autopilot configuration reference|property rules]] or JSBSim systems instead.  
If you need things to manipulate properties continuously, consider using [[Autopilot configuration reference|property rules]] or JSBSim systems instead.  
=== Autopilot ===
{{main article|Howto:Design an autopilot}}
FlightGear comes with a [[route manager]] and a very basic [[autopilot]].  The autopilot can be disabled if you for example do not want it to be available on a WWI double deck aircraft.
It is pretty much always a good idea to tune an autopilot to your aircraft.
If you are developing a complex aircraft with several flight control laws, for example a fly-by-wire aircraft, you will also need to have a more complex autopilot.
== The model-view-controller concept ==
For better maintainability he model-view-controller concept (MVC) can be of great help. It separates systems, instruments, interfaces etc. into
; Views
: Seen by the user, for example instruments and positions or thrust levers moved in autothrust mode
; Controllers
: That are operated by the user, for example when pressing buttons or operating levers and switches
; Models
: The software and systems that take input from the controllers, compute or filter it and use it in other systems and also drive instruments and levers
This concept also involves having properties that for example drive the movement of a lever as well as a property that is driven by the lever position.
By separation parts of your aircraft like this it can often be easier to maintain and it can also make it more flexible.  If you for example have made a complex panel connected to an even more complicated autopilot, but have made sure to not have any unnecessary encapsulated Nasal code in the pick animations for the buttons and knobs as well as for the displays, someone could later make a panel as for example an app on a smartphone or as real hardware that functions by simply changing the values of the relevant control properties and showing the display properties.


== Related content ==
== Related content ==
=== Wiki articles ===
* [[Howto:Build your own procedure trainer]]
* [[Release:Aircraft Selection Criteria]]
* [[Standard aircraft structure]]
=== Forum ===
=== Forum ===
* [https://forum.flightgear.org/viewforum.php?f=4 Aircraft development subforum]
* [https://forum.flightgear.org/viewforum.php?f=4 Aircraft development subforum]
Line 114: Line 169:


=== Source code ===
=== Source code ===
* {{fgaddon source|text=FGAddon repository}} - All the aircraft in the official repository
* {{fgaddon source |text=FGAddon repository}} - All the aircraft in the official repository
* {{fgdata source |path=Nasal}} - A lot of Nasal files useful when trying to figure out Nasal
* {{fgdata source |path=Nasal}} - A lot of Nasal files useful when trying to figure out Nasal



Revision as of 11:52, 29 April 2019

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.

Purpose

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 this and how much data that is available and how much time you (and any team mates) are willing to spend the approach will be quite different.

Maintenance, distribution and licensing

Git and repositories

Using version control software will help immensely if you work on your aircraft over time or might later work on the aircraft in a group, 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 your aircraft 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).

Adding Your aircraft to the official hangar

If you are going to add the aircraft to FGAddon, FlightGear's official aircraft hangar, 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 GPLv2 it is highly recommended 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+.

Maintenance and licenses

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


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 how FlightGear and its aircraft is configured and run is how it passes information withing and 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 assigns 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.

Parts of an aircraft in FlightGear

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 pick animations, other animations, and what will animate the 3D models.
  • 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. They could for example be
    • The autopilot
    • The electrical systems
    • The pitot-static system (that deliver the static and dynamic pressures used for airspeed and altitude instruments)
    • Fly-by-wire (FBW) or conventional flight control system (FCS)

Parts of a basic aircraft

Basic 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 set up:

  • What 3D models and animations to use
  • The FDM defining how the aircraft handles
  • A pitot-static system driving the airspeed and altitude instruments

If you will distribute the aircraft it may also help if you set up:

  • A rating that describes how complete the aircraft is
  • What fallback model other users will have loaded on MP if your aircraft is not installed on their computer.
  • Metadata used when creating hangar catalogs for the Aircraft Center

3D Models 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.

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, but these days one can make a basic JSBSim from such data using the Aeromatic tool.

More advanced aircraft parts

More aircraft-set.xml file items

Spicing up the 3D model

You can make liveries to show your aircraft in different paint schemes

Through pick, knob/slider, and touch animations you can also use 3D models as interfaces, like for example buttons, switches and levers.

In addition shaders can do a lot for the aircraft's appearance.

Sound

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 language 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.

Autopilot

1rightarrow.png See Howto:Design an autopilot for the main article about this subject.

FlightGear comes with a route manager and a very basic autopilot. The autopilot can be disabled if you for example do not want it to be available on a WWI double deck aircraft.

It is pretty much always a good idea to tune an autopilot to your aircraft.

If you are developing a complex aircraft with several flight control laws, for example a fly-by-wire aircraft, you will also need to have a more complex autopilot.

The model-view-controller concept

For better maintainability he model-view-controller concept (MVC) can be of great help. It separates systems, instruments, interfaces etc. into

Views
Seen by the user, for example instruments and positions or thrust levers moved in autothrust mode
Controllers
That are operated by the user, for example when pressing buttons or operating levers and switches
Models
The software and systems that take input from the controllers, compute or filter it and use it in other systems and also drive instruments and levers

This concept also involves having properties that for example drive the movement of a lever as well as a property that is driven by the lever position.

By separation parts of your aircraft like this it can often be easier to maintain and it can also make it more flexible. If you for example have made a complex panel connected to an even more complicated autopilot, but have made sure to not have any unnecessary encapsulated Nasal code in the pick animations for the buttons and knobs as well as for the displays, someone could later make a panel as for example an app on a smartphone or as real hardware that functions by simply changing the values of the relevant control properties and showing the display properties.

Related content

Wiki articles

Forum

Readme files

Source code