User:Johan G/Howto:Create an aircraft
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. |
If you are entirely new to aircraft development
If you are entirely new to aircraft development it might be better to start with adding features to existing aircraft, than making one from scratch. Though skimming through this article will still be of help.
By starting off tinkering with an existing aircraft you will for example easier grasp things like
- Typical file structures (and perhaps also that they can differ to some degree)
- Contents of important files
And depending on what you start with you could also begin to understand concepts like
- Drawing images and writing configuration files for liveries
- Modeling and animating 3D models
- Scripting systems in the Nasal programming language
- Tuning autopilots
- Improving handling characteristics
- Working with Git revision control repositories
- Working in development teams
- The GNU GPLv2 license and perhaps the Creative Commons licenses
- Etc.
In addition starting by improving an existing aircraft will also get you more aware of the hurdles involved and the time it takes to develop an aircraft.
|
One of the better approaches for a noob is to start out working on improving something that is already there but needs work. It limits the steepness of learning curve and allows you to actually get something done in the short term. This allows you to keep the frustration level down while learning how things work. Only a small % of aircraft development noobs who start a new aircraft without having done some previous work on another aircraft actually manage produce something worth while. It does happen but it is rare - the recent Bonanza work by a noob is an example of one of these rare cases. A much larger % of those who start off doing smaller tasks on existing aircraft end up making a significant contribution either by doing smaller things to a lot of aircraft or by transforming an existing aircraft into something much better (the P-51D is an example of one of these) or after building a decent skill set doing their own aircraft from scratch.
|
|
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 
. 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 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
|
|
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.xmlfile 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
|
|
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
|
|
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:
- The full aircraft if you have that installed, in essence:
$FG_ROOT/Aircraft/Aircraft-name/Models/Model-and-animation-configuration.xml - 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 - A fallback model if the other aircraft have one defined
- The default model is used (the infamous yellow and blue glider, unless another model is used)
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 keyboard bindings
- Walk view configuration
- Aerial refueling
- Canvas elements, such as for example a Canvas HUD
- Systems built with property rules
- The instant replay feature
- What properties to send over multiplayer that are for example used to drive animations etc.
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
|
|
Nasal scripting
|
|
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
|
|
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
- Howto:Build your own procedure trainer
- Release:Aircraft Selection Criteria
- Standard aircraft structure
Forum
- Aircraft development subforum
- How to make an Aircraft.... (September 2009-)
Readme files
Source code
- FGAddon repository - All the aircraft in the official repository
- flightgear/fgdata/next/Nasal - A lot of Nasal files useful when trying to figure out Nasal