Volunteer
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 
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
 |
The FlightGear forum has a subforum related to: 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 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
|
|
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: X-Plane Scenery Gateway.)
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
- SGPath
Done (by TheTom) - SGCondition Done (by TheTom) flightgear/flightgear/1b55ab5f4032c6f3f1a4d07c0b9babd3744f1c37 commit view
Work in Progress
- SGPropertyChangeListener
Pending (suggested by Zakalawe & TheTom) [1]
|
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) |
|
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] and TheTom's system-modeling plans.
|
|
|
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) |
|
|
|
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. |
|
|
|
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) |
|
|
|
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.
— ThorstenB (2012-08-29). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
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). — ThorstenB (2012-08-29). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
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.
— ThorstenB (2012-08-29). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
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) |
|
|
|
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.
|
|
|
|
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).
|
|
|
|
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) |
|
|
|
I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
|
|
|
|
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) |
|
|
|
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
— Hooray (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes) |
|
|
|
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. |
|
|
|
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.
|
|
|
|
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]
|
|
|
|
At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
|
|
|
|
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
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
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
|
|
props.nas
|
|
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) |
|
Candidates
- environmental sounds [4]
- simgear::PropertyBasedElement (background/motivation)
- for better diagnostics, and better end-user bug reports, we could consider exposing a cross-platform process and system utilities module via Nasal/CppBind, such as e.g. SIGAR (Windows, MacOS & BSD/Unix)
Not done - Airways/Airspace boundaries don't seem to be exposed via NasalPositioned currently? [5] [6]
- FGProtocol, to implement I/O protocols via Nasal (and help solve ticket #396 and support AJAX, REST, JSON or WebSockets)
[7] [8] [9] (stubs available at gitorious/fg/hoorays-flightgear/topics/cppbind-fgprotocol). - the loglist/SG_LOG() logging buffer machinery [10] [11]
- expose VoiceSynthesizer/FLITE TTS[12] to Nasal to get rid of ATC chatter [13] Not done
- the SGSubsystem interface to register scripted SGSubsystems
- flight path history [14] Done (by TheTom)
- the flight recorder system (replay buffers) Not done
- State machines e.g. to help clean up the ND code [15]
- exposing the sound manager, so that scripts can directly play audio files [16]
- exposing the random buildings system [17] [18] Pending [19] [20]
- There's also a pending feature request (ticket #619) to implement USB-HID support [21] .
- ESRI shapelib? [22]
|
|
When we have vector road data at runtime, we can do the following:
— James Turner (2014-11-21). Re: [Flightgear-devel] Future city terrain strategy.
(powered by Instant-Cquotes) |
|
- effects framework ?
- Howto:Using OpenCL in FlightGear
- Nasal/HLA bindings, so that we can run certain scripts as HLA federates outside the fgfs process space (such as bombable or local weather)
|
|
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 |
|
| 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 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
|
|
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.