Howto:Create a custom version of FlightGear

From FlightGear wiki
Jump to navigation Jump to search
Merge-arrow.gif
It has been suggested that this or section be merged into Howto:Creating a simple modding framework.

Intro

This article is dedicated to providing an introduction to "modding" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by a question posted to the FlightGear forums in June/2010.

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

Getting Started

The largest part of FlightGear by far is its base package (referred to as $FG ROOT), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation (watch out for space requirements), so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder to work with a fresh, unmodified FlightGear version.

Note: Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable to point FlightGear to the customized version.

Reducing Size

Cquote1.png I am going to commence reducing FGDATA this weekend. The reasons for that

action have been discussed here and on the forum in epic detail, so I won't
repeat them.

The result will be a new and much smaller git repository and it will only
have the c172p and the ufo remaining.

To avoid any unnecessary extra work, I will temporarily remove all
contributors with write access except 2 or three admins on Friday afternoon
(Central European Time Zone).


— Torsten Dreyer (2015-03-05). [Flightgear-devel] FGData size reduction.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Next, I'll do a initial commit of the base package aircraft to fgaddon/svn.

Following that, I create a new git repo for a smaller git fgdata and push
it to sourceforge.
Finally, we re-add contributors with push permission.

If anything goes wrong, the original fgdata will remain intact and can
serve as a fallback.


— Torsten Dreyer (2015-03-05). [Flightgear-devel] FGData size reduction.
(powered by Instant-Cquotes)
Cquote2.png


Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

Removing Resources

You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working. Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

Proceeding

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

Disabling Features

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first (and check if FlightGear still starts up) before removing anything!

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

Customizing Preferences.xml

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )


Getting Help

If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.