Volunteer: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Creating Scenery Models: Fixed broken link '3D models')
(44 intermediate revisions by 11 users not shown)
Line 1: Line 1:
Many people think that contributing to FlightGear requires writing C++ code or doing 3D Modeling, and therefore feel that they cannot contribute directly. Not so. There are a whole variety of ways to make a valuable and satisfying contribution to FlightGear without having to be a developer. This page is intended to provide a starting point for those wanting to contribute, but who don't know how.
{{Volunteer Intro}}


Of course, these are just suggestions for some possible ways for getting involved, and there are obviously plenty of other options.
== Media ==
So if you have already a specific idea in mind, please do get in touch with the community to ask for feedback. This can be easily done using the mailing lists, forums or the IRC channel (chat).
=== Screenshots ===
Another easy way for getting started contributing is to create nice FlightGear screenshots. You can upload these to the wiki where they can then be used to illustrate articles and to highlight articles via the [[:Category:Picture of the week|picture of the week]] on the main page.


Often, work in such non-development related areas will at least be as appreciated by other users as are contributions by developers, simply because it is in the nature of non-development related contributions that they will specifically appeal to non-developers/users. So, if you would like to help the FlightGear project improve, please take a look at the following opportunities and feel free to make suggestions for new ones.
[[Howto: Make nice screenshots]] provides some tips on how to create stunning shots, while [[Help:Upload]] discusses how to upload screenshots to the wiki.


If you are contributing to the core simulator, or an aircraft in the master repository, you should be part of the FlightGear-devel mailing list, which is the primary point of contact for all discussions regarding the development of the simulator.
=== Videos ===
Many users like to capture their flights in FlightGear as a video, YouTube for example is an excellent way for sharing such videos with fellow FlightGear users. YouTube videos can also be directly embedded in forum postings and wiki articles.


==== Participate in the FlightGear Forums ====
=== Screencasts (video tutorials) ===
If you haven't done so already, please consider registering at the [http://www.flightgear.org/forums FlightGear forums], this is a very simple thing to do, but it makes it very easy to obtain and provide help and other support within the FlightGear community.
Creating FlightGear related video tutorials is another excellent way for getting started contributing.  


Taking extra care in your posting to avoid requiring the attention of the moderators is in some ways also a contribution. Doing so helps self-police the forums so that the moderators can spend their time doing constructive development.
== Documentation ==
 
{{forum|72|FlightGear Documentation}}
 
=== FAQ-Maintainers ===
The FlightGear project is looking for people who are willing to help maintain the FAQ which, given the constant development of the project, is chronically out of date. If you you would like to get involved, follow the {{forum link|text=forum}} to stay current on the latest news, problems, and of course on what questions are asked more frequently, and simply start editing the [[FAQ|wiki FAQ]].
 
=== Maintaining the wiki ===
You can easily [[Special:UserLogin|register an account]] and help [[Portal:Wiki|improve the wiki]], and provide your help in reviewing articles, fixing their look and readability, updating them and adding what you think is missing, for example many articles could be greatly improved just by adding a handful of relevant screenshots for illustration purposes. Proof reading of existing articles is also greatly appreciated.
 
Registering takes less than 10 seconds. After registration, you'll have to confirm your registration by clicking on the link sent to you by email.
 
=== Translating the wiki and FlightGear ===
You can also help localize the wiki by [[Help:Translate|translating]] important articles into different languages. Please see the [[translation requests]].
 
Also, FlightGear itself can be easily translated by updating the files in [[$FG_ROOT]]/Translations. For details please see [[Howto: Translate FlightGear|Translating FlightGear]].
 
=== Wiki article writers ===
Various aspects of FlightGear are currently not yet sufficiently documented, and available documentation is often not really suitable to be used by non-developers. This results in users being unaware of the wide range of features and possibilities that FlightGear supports already.
 
As an "article writer" you should be able to document your own experiences with FlightGear in a clear and concise style, so that others can easily follow your instructions in order to make use of the less known features of FlightGear. These articles don't need to be very comprehensive, they shall only provide users with easy to follow instructions on how to achieve something, and possibly some caveats and hints.
 
* [[:Category:Volunteer: Writing]]


==== Check out the FlightGear Chat channel ====
=== Contributing to "The Manual" ===
To talk to fellow FlightGear users in realtime, you may want to check out the IRC chat channel, please see: http://wiki.flightgear.org/index.php/IRC
The wiki is not the only documentation here, of course. FlightGear comes with a set of illustrated documentation, notably [[FlightGear Manual|"The Manual"]]. If you are a skilled writer and a little bit familiar with LaTex, your help would be really welcome. More on this at "The Manual" wiki page. You'll find the source code in the {{getstart source|text=Getstart repository}}.
This is also an excellent way for getting and providing community help, or for getting the latest news about FlightGear.


==== Tell us about your own ideas and feature requests for improving FlightGear ====
=== Documentation Editors/Reviewers ===
If you think you have a good idea or feature request for improving FlightGear, the FlightGear forums and the IRC channel are also an excellent way for getting feedback.
{{Main article|Howto:Write a FlightGear Review}}
The documentation that comes with FlightGear base package is lacking, terse or simply inaccurate (outdated), due to the advances in FlightGear's code. You should check the current documentation and identify areas for improvement, by directly making corresponding suggestions for augmentations, or even writing new help documents altogether, while staying current with the mailing list.


Another new way for posting feature requests and making suggestions is provided at http://code.google.com/p/flightgear-future/issues/list
Smaller corrections shall be sent by email to the developer mailing list, preferably in unified diff format (for patch to work). Alternatively, small text files can also be sent directly to the mailing list, more complex modifications should be only made available by uploading them to a webpage and linking to the corresponding files from your emails. Please consider trying [http://kdiff3.sourceforge.net/ KDiff3], a GUI frontend to the diff and patch utilities that works on several platforms (also Windows).
This is a google code based issue tracker, specifically meant to be used for posting suggestions for new features.


==== Help us write the FlightGear Newsletter ====
If you intend to redo a major part of the current documentation, first discuss this with the developers, to avoid documenting code that may also be under development or deprecation.
The FlightGear newsletter is a community driven newsletter that is created and edited using the wiki.
All community members are invited to contribute to the newsletter. The only thing that is required is a wiki account, which is free and easy to register.
Please feel free to add news about your own FlightGear related projects, or projects started by others to the newsletter.


You can find the draft of next month's newsletter at: http://wiki.flightgear.org/index.php?title=Next_newsletter
== Development ==
=== Creating interactive tutorials ===
FlightGear has a built-in [[Tutorials|tutorial]] system that is based on its scripting language [[Nasal]], this system is very flexible and can be used for creating interactive tutorials (or even missions) for use in FlightGear itself, in other words these tutorials run directly in the simulator.  


Just tracking the forums, mailing lists or the IRC channel should provide you with plenty of opportunities for things that could be added to the newsletter.
Creating new tutorials, or updating and improving existing ones, is another great way for getting more familiar with FlightGear. For details please see [[Tutorials]].


==== Write FlightGear reviews ====
=== Providing patches for aircraft's -set.xml status fields ===
Another thing that can be easily done is reviewing FlightGear (or just certain parts of it, like for example scenery and/or aircraft) and submit your reviews to some of the flight simulation portals. Of course, you can also directly write your reviews using the FlightGear wiki.
One way you could easily contribute would be to submit patches to HEAD setting the "status" flag on each aircraft accurately. While it will require learning a bit about SCM, and XML, that would be a fine contribution. For a details on how the status should be arrived at see  [[Aircraft status indication]].


==== Help improve the Wiki ====
=== Creating Scenery Models ===
You can easily register a new account and help improve the wiki, for example by editing existing articles or creating new ones.
The FlightGear project maintains a steadily growing repository of [http://scenemodels.flightgear.org 3D models] for adding some eye-candy to the scenery. The world has always enough room left for your [http://scenemodels.flightgear.org/contribute.php contribution]. Please take the time to investigate what is already there and enjoy populating your favourite area.
Also, many articles could be greatly improved just by adding a handful of relevant screenshots for illustration purposes. Proof reading existing articles is also greatly appreciated.


Registering an account takes less than 10 seconds.  
Note that you don't have to create any models yourself. You can simply [[Howto: Place 3D objects with the UFO|place existing models using the UFO]]. For example, placing objects in the scenery with the [[UFO]] and submitting them to the database is pretty straightforward and takes very little time. Even an hour spent doing this makes a difference.
To register an account, please go to http://wiki.flightgear.org/index.php?title=Special:UserLogin&type=signup


After registration, you'll have to confirm your registration by clicking on the link sent to you by email.
If anyway you'd like to [[Modeling - Getting Started|test your modeling skills]], here some suggestions:
* We need people to go out and take good pictures of all the buildings at their local airports, build models, and create textures (that could be different people for each task).
* We need people to start modelling identifiable human-made landmarks like bridges, stadiums, and major buildings. Around the San Francisco Bay area, bridges are especially important. Once you have identified some buildings or objects you would like to have (Aircraft carriers, fuel bowsers, cars, towers, ...) you will need to check out the tools for creating and placing these objects.  


==== Help review Wiki articles ====
It would be helpful if people would model the area they are interested in. Generally contributions are going to be from FlightGear users who find scenery lacking in some area and choose to improve it. You are encouraged to research your own area for airport, navaid and scenery information, to contribute the data or dive right in to airport and scenery design.
Many wiki articles are outdated, or may simply need to be reviewed and improved for other reasons - your help in reviewing existing articles would be highly appreciated!


==== Help translate the Wiki ====
=== Making airports ===
You can also help localize the Wiki by translating important articles into different languages.
Sometimes you'd like to populate your favourite airport with objects, but you find it has a wrong layout or that it doesn't exist at all! So, you'll want to [[Howto:Make an airport|make or improve that layout]], which can be done with [[WED]]. Remember that we're maintaining an open (GPL) airport database in common with X-Plane simulator.
Please see [[Translation requests]].


Also, FlightGear itself can be easily translated by updating the files in $FG_ROOT/Translations. For details please see [[Translating FlightGear]].
Other than just fix the look, you might want to add interactive details like [[AI Traffic]] and maybe update navaids and comm frequencies. We need people to go over paper lists and airport diagrams for countries that don't publish air navigation data free online (i.e. almost everyone but the U.S.) and fill in the blanks in our navaid and airport databases (''note: especially for the last part, see the website of the current maintainer: [http://data.x-plane.com/ data.x-plane.com]''.)


==== Submitting Bugs to the Bug Tracker ====
To be sure the airport you're interested in is not already being worked on, check the [[Airports under construction]] article. Also, note that since we switched to a newer format for the airport database, there are many airports that need to be converted from the older (810) format to the newer (850). All the info is in [[Howto:Make an airport]].
Bugs are currently being reported at [http://code.google.com/p/flightgear-bugs/ this tracker]. Feel free to contact one of the project owners to be added to the member list, if you would like to add a bug (or two). Reporting bugs accurately helps make bug fixing significantly easier for the developers.
Another thing that is very helpful, is reviewing posted bug reports and see if you can reproduce/confirm them.


==== Providing patches for aircraft-set.xml status fields ====
=== Contributing to the scenery terrain ===
One way you could easily contribute would be to submit patches to HEAD setting the "status" flag on each aircraft accurately. While it will require learning a bit about SCM, and XML, hat would be a fine contribution. You would have to decide on appropriate criteria for the status flags, but that isn't impossible.
We need people to collect geodata to give us more accurate roads, rivers, etc., especially outside the U.S. and Europe. Note that since we're now allowed to use OpenStreetMap data for this, you might consider contributing to that project too. With time, more and more features will be imported from OSM, beginning with roads and rails, and going on with power lines and antennas and whatnot.


==== Screenshot Managers ====
The first step into this is learning how to [[Using TerraGear|use TerraGear]]. Remember that all the data you plan to use must be GPL compatible. You might also consider editing some of that source data and contribute it to the Scenery Project that would make good use of it!
In order to illustrate FlightGear's impressive and advancing capabilities it was recently suggested (and agreed) to conduct monthly screenshot competitions where users are encouraged to submit their best FlightGear screenshots, so that the very best screenshots will be posted on the webpage for one month. Participants are expected to make their submissions at the end of each month, submissions should not be directly sent to the user mailing list as attachments, rather participants are expected to upload their screenshots to some free webspace and send mails containing links to their screenshots to the FlightGear User mailing list. It will be the decision of the screenshot managers to determine which screenshots shall win the monthly competition and are thus uploaded to www.flightgear.org


==== FAQ-Maintainers ====
=== Core development ===
The FlightGear project is currently looking for people who are willing to help maintain the FAQ (which is quite out of date). If you you would like to get involved, please subscribe to the FlightGear Developers [[Mailing list]] in order to discuss the details or simply start editing the wiki FAQ here: http://wiki.flightgear.org/index.php/FAQ
If you actually happen to be a C++ programmer and know Git, consider contributing to [[Howto:Start core development|core development]].


==== Scenery Model Creators ====
{{CppBind Ideas}}
The FlightGear project maintains a steadily growing repository of [http://scenemodels.flightgear.org/models.php 3D models] for adding some eye-candy to the Scenery. The World has always enough room left for your [http://scenemodels.flightgear.org/contribute.php contribution]. Please take the time to investigate what's already there and enjoy populating your favourite area.


Note that you don't have to create any models yourself. You can simply place existing models using the UFO.
== Other ==
For example, placing objects in the scenery with the UFO and submitting them to the Scenery Objects DB is pretty straightforward and takes very little time. Even an hour spent doing this would make a difference.
=== Submitting bugs to the Bug Tracker ===
Bugs can be reported to [http://code.google.com/p/flightgear-bugs/ this tracker]. Reporting bugs accurately helps make bug fixing significantly easier for the developers. Another thing that is very helpful, is reviewing posted bug reports and see if you can reproduce/confirm them on your system.


==== Artwork Creators/Contributors ====
=== Artwork Creators/Contributors ===
FlightGear itself would not be possible without the contribution of various types of artwork:
FlightGear itself would not be possible without the contribution of various types of artwork:
* Often aircraft developers have to use different resources to accomplish the goal of realistically modeling a particular aircraft. Contributing photographs, images, sounds all have value.
* Aircraft developers need photographs, images and sounds to realistically model a particular aircraft.
* A splashscreen is displayed when loading the simulator, and can be specific to the aircraft being loaded. Why not create a spashscreen of your favorite aircraft: [[Howto: Create custom splash screens]]
* The splash screen displayed when loading the simulator can be personalized, and you can [[Howto: Create custom splash screens|create one for your favourite aircraft]].
* Sound recordings of aircraft are also valuable - particularly engine sounds for unusual aircraft.
* Sound recordings of aircraft are also very valuable - particularly engine sounds for unusual aircraft.
 
In general, you can find requests and post your offers of this kind in the Developers forum, but you can also browse [[:Category:Aircraft by status|existing aircraft projects]] and see if there's anything you'd like to improve.


Also see:
=== Pre-Release Testers ===
* [[Splash screen requests]]
Prior to a release, release candidates are provided to the community. By directly providing feedback about your experiences with FlightGear's development code, you will become a crucial part of the development process and you will basically serve as quality control for FlightGear, your experiences will determine whether FlightGear's development code is ready for a next official release or not. See the [[Release plan]] to find out when release candidates will be distributed.
* [[Livery requests]]
* [[Texture requests]]
* [[3D object requests]]
* [[Instrument requests]]
* [[Airport requests]]
* [[Aircraft requests]]
* [[Sound requests]]


==== HowTo Writers ====
Note: If you are interested in actually doing development for FlightGear, make sure to check out the [[Portal:Developer|Developer section]].
Various parts of FlightGear are currently not yet sufficiently documented, also available documentation is often not really suitable to be used by non-developers. This results in users being unaware of the wide range of features and possibilities that FlightGear supports already.  


As "HowTo writer" you should be able to document your own experiences with FlightGear in a clear and concise style, so that others can easily follow your instructions on order to make use of FlightGear's less known features. HowTo guides do not need to be very comprehensive, they shall only serve the purpose of providing users with easy to follow instructions about how to set up their version of FlightGear.  
=== Hosting a multiplayer server ===
If you have access to an Unix based server, another good opportunity for contributing would be to set up a multiplayer server for use with FlightGear, for details please check out [[Howto: Set up a multiplayer server]].


Adding screenshots to articles is another excellent way for improving the existing documentation.
=== Tell us if FlightGear works with your hardware ===
You can help fellow FlightGear users by telling us if FlightGear works with your hardware. Please see [[FlightGear Hardware Recommendations]], [[Problematic Video Cards]] and [[Notebooks known to run FlightGear]].


Topics that could use some HowTos are listed in [[Article requests]].
=== Participate in the FlightGear Forums ===
If you haven't done so already, please consider registering at the {{forum link|text=FlightGear forum}}, this is a very simple thing to do, but it makes it very easy to obtain and provide help and other support within the FlightGear community.


==== Documentation Editors/Reviewers ====
Taking extra care in your posting to avoid requiring the attention of the moderators is in some ways also a contribution. Doing so helps self-police the forums so that the moderators can spend their time doing constructive development.
As already stated on the Wiki main page, FlightGear comes with a set of illustrated documentation, notably "The Manual". This piece of documentation aims at being printed onto paper and being read as a reference while you're exploring FlightGear - or simply taken with you on a long trip. If you are a skilled writer and a little bit familiar with LaTex, please take the time to dig into the [http://mapserver.flightgear.org/getstart.pdf PDF] or
[http://www.flightgear.org/Docs/getstart/getstart.html HTML] version. Instructions on how to get the source code are [http://www.de.flightgear.org/cvs/getstart-cvs.html here].
It lies in the nature of FlightGear development that The Manual is always a bit behind current development. We invite you to pick information from a) your personal experience with FlightGear, b) the available README's in the FlightGear source tree or the Base Package or c) the Wiki and merge these into an appealing shape for The Manual. Turn your head to the FlightGear developers' [http://www.flightgear.org/mail.html mailing list] and you'll find someone to talk about how to improve The Manual.


Currently, some of the other documentation that comes with FlightGear is lacking, terse or simply inaccurate (outdated) in various places due to the advances in FlightGear's code since the time when the original documentation was written. This state is not improved by people's tendency to create new documents instead of maintaining what already exists. As a documentation editor/reviewer, it would be your task to check the current documentation and identify areas for improvement. Preferably you should also be able to directly make corresponding suggestions for augmentations, or even write new help documents altogether (possibly based on evaluating recent mailing list discussions). You would be expected to thoroughly check the documentation folder ($FG_ROOT/Docs) and review all relevant documentation for obvious shortcomings or mistakes, smaller corrections shall be sent by email to the developer mailing list, preferably in unified diff format (for patch to work). Alternatively, small text files can also be sent directly to the mailing list, more complex modifications should be only made available by uploading them to a webpage and linking to the corresponding files from your emails. If you are not now familiar with the process of creating unified diff patches, but would like to make it easier for the developers to work with your changes, please consider trying [http://kdiff3.sourceforge.net/ KDiff3], a GUI frontend to the diff and patch utilities that works on several platforms (also Windows).
=== Check out the FlightGear Chat channel ===
If you intend to redo a major part of the current documentation, it is recommended that you first discuss this with the developers, to ensure that you do not end up documenting code that may also be subject to major changes or even removal altogether. Please contact the developers before launching into a major documentation effort.
{{Main article|FlightGear IRC channel}}
To talk to fellow FlightGear users in realtime, you may want to check out the IRC chat channel.
This is also an excellent way for getting and providing community help, or for getting the latest news about FlightGear.
 
=== Tell us about your own ideas and feature requests for improving FlightGear ===
If you think you have a good idea or feature request for improving FlightGear, the FlightGear forums and the IRC channel are also an excellent way for getting feedback.
 
Another new way for posting feature requests and making suggestions is provided at http://flightgear-bugs.googlecode.com
 
=== Help us write the FlightGear Newsletter ===
The FlightGear newsletter is a community driven newsletter that is created and edited using the wiki. All FlightGear users are invited to contribute to the newsletter. The only thing that is required is a wiki account, which is free and easy to register.
 
Please feel free to add news about your own FlightGear related projects, or projects started by others to the newsletter.


You can find the draft of next month's newsletter at: [[Next newsletter]]


==== Pre-Release Testers ====
Just tracking the forums, mailing lists or the IRC channel should provide you with plenty of opportunities for things that could be added to the newsletter. One simple thing for getting started - even without writing anything - is uploading screen shots showing recent FlightGear developments for use in the FlightGear newsletter.
Pre-release testers will be regularly offered the opportunity to test development code without having to build the corresponding binaries themselves, it will be expected of you to provide feedback about your experiences with experimental code to the developers, you should be able to provide details about your hardware and software setup, as well as being able to follow developer requests to track down any potential issues. You should also be willing to test run all aircraft that are by default included in FlightGear's base package on the platforms you have access to in order to ensure that all default aircraft are working properly.
By directly providing feedback about your experiences with FlightGear's development code, you will become a crucial part of the development process and you will basically serve as quality control for FlightGear, your experiences will determine whether FlightGear's development code is ready for a next official release or not. If you are willing to volunteer in this way to the FlightGear project, please consider subscribing to the FlightGear announcements mailing list, where future pre-releases are likely to be announced in order to attract a greater number of potential pre-release testers.


Note: If you are interested in actually doing development for FlightGear, make sure to check out the Developer section.
=== Reviews ===
Another thing that can be easily done is reviewing FlightGear (or just certain parts of it, like for example scenery and/or aircraft) and submit your reviews to some of the flight simulation portals. Of course, you can also directly write your reviews using the FlightGear wiki, see: [[FlightGear Reviews]].


==== Hosting a multiplayer server ====
[[Category:Contribution requests]]
If you have access to a unix based server, another good opportunity for contributing would be to set up a multiplayer server for use with FlightGear, for details please check out [[Howto: Set up a multiplayer server]].
[[Category:Community]]


[[es:Tener a bien]]
[[es:Tener a bien]]
[[fr:Volontaires]]

Revision as of 10:59, 30 November 2020

Many people think that contributing to the FlightGear project requires writing C++ code or doing 3D modeling and that it takes lots of time, and therefore feel that they cannot contribute directly. Not so. There's a whole variety of ways to make a valuable and satisfying contribution to FlightGear without being a developer.

The Volunteer page is intended to provide a starting point for those wanting to contribute, but who don't know how. Of course, these are just suggestions. So if you have already a specific idea in mind, please do get in touch with the community to ask for feedback, using the mailing lists, forum This is a link to the FlightGear forum. or the IRC channel (chat).

Remember that work in non-development areas will be appreciated as much as developer contributions (or more!), because generally more visible to the end user.

If you'd like to learn more about getting your own ideas and features into FlightGear, check out Implementing new features for FlightGear.

If you are contributing to the core simulator, or an aircraft in the master repository, you should be part of the FlightGear-devel mailing list, which is the primary point of contact for all discussions regarding the development of the simulator. You may want to check out also Howto: Understand the FlightGear development process and Howto: Starting core development.

Media

Screenshots

Another easy way for getting started contributing is to create nice FlightGear screenshots. You can upload these to the wiki where they can then be used to illustrate articles and to highlight articles via the picture of the week on the main page.

Howto: Make nice screenshots provides some tips on how to create stunning shots, while Help:Upload discusses how to upload screenshots to the wiki.

Videos

Many users like to capture their flights in FlightGear as a video, YouTube for example is an excellent way for sharing such videos with fellow FlightGear users. YouTube videos can also be directly embedded in forum postings and wiki articles.

Screencasts (video tutorials)

Creating FlightGear related video tutorials is another excellent way for getting started contributing.

Documentation

FAQ-Maintainers

The FlightGear project is looking for people who are willing to help maintain the FAQ which, given the constant development of the project, is chronically out of date. If you you would like to get involved, follow the forum This is a link to the FlightGear forum. to stay current on the latest news, problems, and of course on what questions are asked more frequently, and simply start editing the wiki FAQ.

Maintaining the wiki

You can easily register an account and help improve the wiki, and provide your help in reviewing articles, fixing their look and readability, updating them and adding what you think is missing, for example many articles could be greatly improved just by adding a handful of relevant screenshots for illustration purposes. Proof reading of existing articles is also greatly appreciated.

Registering takes less than 10 seconds. After registration, you'll have to confirm your registration by clicking on the link sent to you by email.

Translating the wiki and FlightGear

You can also help localize the wiki by translating important articles into different languages. Please see the translation requests.

Also, FlightGear itself can be easily translated by updating the files in $FG_ROOT/Translations. For details please see Translating FlightGear.

Wiki article writers

Various aspects of FlightGear are currently not yet sufficiently documented, and available documentation is often not really suitable to be used by non-developers. This results in users being unaware of the wide range of features and possibilities that FlightGear supports already.

As an "article writer" you should be able to document your own experiences with FlightGear in a clear and concise style, so that others can easily follow your instructions in order to make use of the less known features of FlightGear. These articles don't need to be very comprehensive, they shall only provide users with easy to follow instructions on how to achieve something, and possibly some caveats and hints.

Contributing to "The Manual"

The wiki is not the only documentation here, of course. FlightGear comes with a set of illustrated documentation, notably "The Manual". If you are a skilled writer and a little bit familiar with LaTex, your help would be really welcome. More on this at "The Manual" wiki page. You'll find the source code in the Getstart repository.

Documentation Editors/Reviewers

1rightarrow.png See Howto:Write a FlightGear Review for the main article about this subject.

The documentation that comes with FlightGear base package is lacking, terse or simply inaccurate (outdated), due to the advances in FlightGear's code. You should check the current documentation and identify areas for improvement, by directly making corresponding suggestions for augmentations, or even writing new help documents altogether, while staying current with the mailing list.

Smaller corrections shall be sent by email to the developer mailing list, preferably in unified diff format (for patch to work). Alternatively, small text files can also be sent directly to the mailing list, more complex modifications should be only made available by uploading them to a webpage and linking to the corresponding files from your emails. Please consider trying KDiff3, a GUI frontend to the diff and patch utilities that works on several platforms (also Windows).

If you intend to redo a major part of the current documentation, first discuss this with the developers, to avoid documenting code that may also be under development or deprecation.

Development

Creating interactive tutorials

FlightGear has a built-in tutorial system that is based on its scripting language Nasal, this system is very flexible and can be used for creating interactive tutorials (or even missions) for use in FlightGear itself, in other words these tutorials run directly in the simulator.

Creating new tutorials, or updating and improving existing ones, is another great way for getting more familiar with FlightGear. For details please see Tutorials.

Providing patches for aircraft's -set.xml status fields

One way you could easily contribute would be to submit patches to HEAD setting the "status" flag on each aircraft accurately. While it will require learning a bit about SCM, and XML, that would be a fine contribution. For a details on how the status should be arrived at see Aircraft status indication.

Creating Scenery Models

The FlightGear project maintains a steadily growing repository of 3D models for adding some eye-candy to the scenery. The world has always enough room left for your contribution. Please take the time to investigate what is already there and enjoy populating your favourite area.

Note that you don't have to create any models yourself. You can simply place existing models using the UFO. For example, placing objects in the scenery with the UFO and submitting them to the database is pretty straightforward and takes very little time. Even an hour spent doing this makes a difference.

If anyway you'd like to test your modeling skills, here some suggestions:

  • We need people to go out and take good pictures of all the buildings at their local airports, build models, and create textures (that could be different people for each task).
  • We need people to start modelling identifiable human-made landmarks like bridges, stadiums, and major buildings. Around the San Francisco Bay area, bridges are especially important. Once you have identified some buildings or objects you would like to have (Aircraft carriers, fuel bowsers, cars, towers, ...) you will need to check out the tools for creating and placing these objects.

It would be helpful if people would model the area they are interested in. Generally contributions are going to be from FlightGear users who find scenery lacking in some area and choose to improve it. You are encouraged to research your own area for airport, navaid and scenery information, to contribute the data or dive right in to airport and scenery design.

Making airports

Sometimes you'd like to populate your favourite airport with objects, but you find it has a wrong layout or that it doesn't exist at all! So, you'll want to make or improve that layout, which can be done with WED. Remember that we're maintaining an open (GPL) airport database in common with X-Plane simulator.

Other than just fix the look, you might want to add interactive details like AI Traffic and maybe update navaids and comm frequencies. We need people to go over paper lists and airport diagrams for countries that don't publish air navigation data free online (i.e. almost everyone but the U.S.) and fill in the blanks in our navaid and airport databases (note: especially for the last part, see the website of the current maintainer: data.x-plane.com.)

To be sure the airport you're interested in is not already being worked on, check the Airports under construction article. Also, note that since we switched to a newer format for the airport database, there are many airports that need to be converted from the older (810) format to the newer (850). All the info is in Howto:Make an airport.

Contributing to the scenery terrain

We need people to collect geodata to give us more accurate roads, rivers, etc., especially outside the U.S. and Europe. Note that since we're now allowed to use OpenStreetMap data for this, you might consider contributing to that project too. With time, more and more features will be imported from OSM, beginning with roads and rails, and going on with power lines and antennas and whatnot.

The first step into this is learning how to use TerraGear. Remember that all the data you plan to use must be GPL compatible. You might also consider editing some of that source data and contribute it to the Scenery Project that would make good use of it!

Core development

If you actually happen to be a C++ programmer and know Git, consider contributing to core development.


FlightGear's built-in Nasal scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.

Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.

Until FlightGear 2.8, the Nasal scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.

Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.

Thanks to development on Tom's Canvas system, there's now a new bindings framework to be found in $SG_SRC/simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features by operating through classes and methods with full STL support, abstracting most common operations away.


After working through the Nasal/CppBind article, some of the more useful things to play with in the beginning, would be exposing additional SG/FG classes to Nasal space, such as for example:

Done

Work in Progress

  • SGPropertyChangeListener Pending Pending (suggested by Zakalawe & TheTom) [1] This is a link to the FlightGear forum.
Cquote1.png This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
— Thomas Geymayer (2014-11-22). [Flightgear-devel] RFC: Nasal ghosts and garbage collection.
(powered by Instant-Cquotes)
Cquote2.png

Autopilot/Property Rules

Note  This is a summary of all discussions about exposing the autopilot/property-rule system (there are certain Nasal GC issues, so that we ask people not to implement FDM-coupled Nasal code like autopilots): this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [2] This is a link to the FlightGear forum. and TheTom's system-modeling plans.
Cquote1.png The quantity of details and system modeling that goes in to covering all the aircraft of the world is impossibly complex. The idea is to put as much support for common/shared systems in C++ as we can and then make it possible to stitch these systems and details together and configure them with xml in a wide variety of ways to create aircraft. But we can never anticipate every system in use, and we can't anticipate the level of detail or feature set that every aircraft developer might want to implement or experiment with, and even if we could there would be no way to model everything in the world in a single application. Nasal gives a lot of flexibility to cover those unanticipated gaps and it allows aircraft developers to push in new areas ahead of the C++ coverage. Now in many cases, aircraft developers were happy with the nasal implementation and called it good enough. Many aircraft developers have become proficient and comfortable in nasal and prefer doing their work there.
— curt (Dec 16th, 2015). Re: Military simulation (from Su-15 Screenshots).
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.
— Alant (Aug 19th, 2015). Re: Route manager leg modes.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I would prefer to do this in an XML filter in the generic autopilot helpers - definitely not in Nasal. It can be done in C++ if strictly required but then we need way to disable it for people who want different filtering.
— James Turner (2015-04-03). Re: [Flightgear-devel] Route manager: waypoint smoothing.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I vote for #3: avoid *any* Nasal in the fast simulation [FDM] loop. Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want.
Cquote2.png
Cquote1.png Concerning your original issue on implementing an autopilot: a much better way to do it is to avoid Nasal for the actual autopilot controller elements (numeric computation). Instead, use XML "autopilot" rules for the filter, gain, damper, integrator elements: Autopilot Configuration Reference

You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS).


Cquote2.png
Cquote1.png This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward.
Cquote2.png
Cquote1.png I agree with your main point that xml-configured hard-coded filters are the right way to implement and autopilot, and I also agree that in general low-level multi-purpose workhorse code should be C++ whereas Nasal is more suitable for the numerically cheap high-level specific functions.
— Renk Thorsten (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png it should basically resemble the C++ 3D animation system and be invisible (enough) that it could easily be replaced with more C++ should we need more performance (or just 'cause). Exposing SGExpression to Nasal would be helpful soon but not necessary yet.
— Philosopher (Sat Aug 16).  animations.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Given that a very simple animation system would mainly need to deal with "events/triggers" (i.e. timers & listeners) and "actions", we might even be able to reuse some of galvedro's sophisticated failure management modules, because those already deal with both concepts via the property tree (sent a heads-up to him for some feedback).
— Hooray (Sat Aug 16). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I'd strongly agree with Thorsten here. It's nothing against Nasal from me - I've not even used it - but creating an autopilot (or any GNC or system model, for that matter) can be done very effectively with discrete objects such as summers, gains, controllers, filters, switches, etc., much as JSBSim has done with the system components. This is a standard approach in industry as Thorsten mentions as exemplified by Mathwork's $imulink product.

Scilab/Scicos is similar in concept. Control system topologies are often diagrammed in a way that can lead to a one-to-one correspondence between a block and a control system object that can be referenced in an XML file, if the control system component library has been defined properly. This, again, is the way that JSBSim has approached the solution. Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one materialize. The downside is that XML can be verbose, but it's a price I've come to accept.


— Jon S. Berndt (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
— Torsten (Thu Feb 02). Re: 2 Questions: vacuum & electrical.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually... :D

An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.


— galvedro (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, just to prevent scripters from implementing APs in Nasal (due to garbage collection issues) - so that should be a no-brainer actually, and such work should be appreciated
Cquote2.png
Cquote1.png there's an extremely powerful and flexible autopilot system in FG that is entirely XML configurable: Autopilot

There's also a very powerful route manager. Please note however, that there's currently no support for AI traffic to directly make use of the autopilot system or the route manager, so you need to come up with your own infrastructure in scripting space.


— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png Note however that scripted AI traffic cannot currently make use of any hard-coded FDMs/AP/RM functionality (JSBSim/YaSim), instead you need to come up with your own "pseudo systems" in scripting space unfortunately.
— Hooray (Tue Jan 03). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The AI traffic system has its own "route manager" system which is currently not yet compatible with the rest of FG unfortunately. But there are plans in place to fix this eventually: [3] This is a link to the FlightGear forum.
— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
— Hooray (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png You can probably find 50+ postings by long term contributors suggesting that AI traffic with FDM support would be a good idea: An_Integrated_AI_Traffic_System#FDM_driven_AI_Traffic
— Hooray (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png When you then take into account that you will probably not need to run the AI traffic FDM at a rate of 120 hz (the FlightGear default), but much more likely at 1-5 hz (at most), you should be able to multiplex at least 20-30 different aircraft onto one dedicated FDM thread (or process).


Thus, the problem lies in the integration part and not the lack of computing power: AI traffic is already the component that accounts for many reported performance bottlenecks and unfortunately the "solution" has often be to disable AI traffic or at least reduce traffic complexity.
Before these issues are resolved, we are unlikely to see real FDMs being supported to simulate AI traffic, even though that would simplify many things in one go (e.g. any aircraft could be used as an AI aircraft and so AI aircraft could also benefit from other systems such as the autopilot or route manager).


— Hooray (Wed Feb 24). Re: "Sophisticated AI aircraft" ... ?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png you would need to hack the autopilot code so that autopilot configurations can be loaded and created dynamically. At the moment, the autopilot code makes the fixed assumption that there's only a single "main aircraft", so it doesn't know about more than one aircraft.
— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png if you wanted to equip your AI traffic with a working route manager, autopilot or even FDM, you would also need to instantiate these subsystems dynamically
— Hooray (Thu Jan 05). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote2.png

props.nas

Cquote1.png ne thing I thing I want to achieve with this changes is to make the Nasal props API more similar to its C++ counterpart as this makes it easier to use if you are using both the C++ and the Nasal API. Also someday I want to refactor nasal-props.cpp to use cppbind, where I want to export as much methods as possible with exactly the same signature than in C++. Especially if using properties seldom (eg. only for initialiation) the relative versions are probably even faster, as the Nasal overhead is lower. Eg. consider the following Nasal code used to initialize some module: var cfg = props.globals.getNode("/my/config/root", 1); var x = cfg.getDoubleValue("x"); var do_it = cfg.getBoolValue("do_it"); Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method).
— Thomas Geymayer (Apr 14th, 2013). Re: [Flightgear-devel] Nasal props API relative path support.
(powered by Instant-Cquotes)
Cquote2.png

Candidates

Cquote1.png When we have vector road data at runtime, we can do the following:
  • render it in moving-map displays - either real ones (Garmin G1000 / G430) or the map dialog
  • use it to drive building outline creation as Thomas was suggesting
  • animate traffic on the roads, as point lights at night or even meshes in daytime
    (the important one...)
  • generate tile overlay textures dynamically (and based on view distance) to show the roads on the terrain surface. (And the detail of this texture can include road markings / borders based on distance from the viewer / view angle / etc)

— James Turner (2014-11-21). Re: [Flightgear-devel] Future city terrain strategy.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Specifically, there are some C++ data structures that still need to be exposed to Nasal via cppbind so that we can implement features available in the Map dialog and the hard-coded ND

Canvas_GUI#PUI_Widgets


— Hooray (Tue Jun 24). Phasing out MapWidget post 3.2.
(powered by Instant-Cquotes)
Cquote2.png
Note  Before working on anything related, please do get in touch with other contributors to ensure that this list is still up-to-date.

For more technical Nasal questions (C API, internals etc), you'll probably want to refer to Philosopher, TheTom, Zakalawe or Hooray on the forum - TheTom and Zakalawe can also provide help on using cppbind, having both used it extensively during the last months.


Other

Submitting bugs to the Bug Tracker

Bugs can be reported to this tracker. Reporting bugs accurately helps make bug fixing significantly easier for the developers. Another thing that is very helpful, is reviewing posted bug reports and see if you can reproduce/confirm them on your system.

Artwork Creators/Contributors

FlightGear itself would not be possible without the contribution of various types of artwork:

  • Aircraft developers need photographs, images and sounds to realistically model a particular aircraft.
  • The splash screen displayed when loading the simulator can be personalized, and you can create one for your favourite aircraft.
  • Sound recordings of aircraft are also very valuable - particularly engine sounds for unusual aircraft.

In general, you can find requests and post your offers of this kind in the Developers forum, but you can also browse existing aircraft projects and see if there's anything you'd like to improve.

Pre-Release Testers

Prior to a release, release candidates are provided to the community. By directly providing feedback about your experiences with FlightGear's development code, you will become a crucial part of the development process and you will basically serve as quality control for FlightGear, your experiences will determine whether FlightGear's development code is ready for a next official release or not. See the Release plan to find out when release candidates will be distributed.

Note: If you are interested in actually doing development for FlightGear, make sure to check out the Developer section.

Hosting a multiplayer server

If you have access to an Unix based server, another good opportunity for contributing would be to set up a multiplayer server for use with FlightGear, for details please check out Howto: Set up a multiplayer server.

Tell us if FlightGear works with your hardware

You can help fellow FlightGear users by telling us if FlightGear works with your hardware. Please see FlightGear Hardware Recommendations, Problematic Video Cards and Notebooks known to run FlightGear.

Participate in the FlightGear Forums

If you haven't done so already, please consider registering at the FlightGear forum This is a link to the FlightGear forum., this is a very simple thing to do, but it makes it very easy to obtain and provide help and other support within the FlightGear community.

Taking extra care in your posting to avoid requiring the attention of the moderators is in some ways also a contribution. Doing so helps self-police the forums so that the moderators can spend their time doing constructive development.

Check out the FlightGear Chat channel

1rightarrow.png See FlightGear IRC channel for the main article about this subject.

To talk to fellow FlightGear users in realtime, you may want to check out the IRC chat channel. This is also an excellent way for getting and providing community help, or for getting the latest news about FlightGear.

Tell us about your own ideas and feature requests for improving FlightGear

If you think you have a good idea or feature request for improving FlightGear, the FlightGear forums and the IRC channel are also an excellent way for getting feedback.

Another new way for posting feature requests and making suggestions is provided at http://flightgear-bugs.googlecode.com

Help us write the FlightGear Newsletter

The FlightGear newsletter is a community driven newsletter that is created and edited using the wiki. All FlightGear users are invited to contribute to the newsletter. The only thing that is required is a wiki account, which is free and easy to register.

Please feel free to add news about your own FlightGear related projects, or projects started by others to the newsletter.

You can find the draft of next month's newsletter at: Next newsletter

Just tracking the forums, mailing lists or the IRC channel should provide you with plenty of opportunities for things that could be added to the newsletter. One simple thing for getting started - even without writing anything - is uploading screen shots showing recent FlightGear developments for use in the FlightGear newsletter.

Reviews

Another thing that can be easily done is reviewing FlightGear (or just certain parts of it, like for example scenery and/or aircraft) and submit your reviews to some of the flight simulation portals. Of course, you can also directly write your reviews using the FlightGear wiki, see: FlightGear Reviews.