Implementing new features for FlightGear
| Working together |
|---|
| The project as a whole: |
| Users and feature requests: |
| Communication: |
We've been seeing an increasing number of discussions on the forum started by people who are eager to become potential contributors. Unfortunately, this has caused some friction over time, because people expected their involvement to work differently.
We do appreciate any community involvement, but people who are serious about bringing changes to FlightGear will find that just making suggestions is typically not enough. As contributors, we would also appreciate it if it would suffice to just make a suggestion — but that's not how things work.
We are now documenting how "bootstrapping" a feature works conceptually: from having an idea to turning it into a feature, without having to do all the work on your own. This model has been shown to work for newcomers.
Note that this is not the only way to accomplish something, but it is a tested and proven way that "just works" for contributors.
This article is based on write-ups from contributors who have worked on novel FlightGear features that initially didn't receive much support, including:
- Advanced weather
- Atmospheric Light Scattering (ALS)
- World Scenery 3.0
- Procedural Texturing
- Canvas system
- MapStructure framework
- Earthview orbital rendering engine
None of these were implemented through "core development" alone. Many started as "mods" and later became official parts of FlightGear. The contributors who wrote this are not all core developers — many work on middleware and base package content (XML, scripts, effects, shaders, textures, 3D models).
What is this about?
Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options:
- Mention it in the forum: Likely outcome: several users agree it's a good idea, a few long-term contributors point out difficulties, and it ends there.
- Make a formal feature request: Likely outcome: a few comments, then low priority, and not much else.
- Make it your own project to get XY implemented: This means you actively manage what happens rather than just putting an idea out there. If you're willing to do this, read on.
Some truths up front
- FlightGear relies on a contributor base, not a user base: Unlike a commercial project, FG does not need customers to survive. Development focuses on what contributors want to build. Arguments like "many more users will join" leave developers unimpressed. Arguments like "this enables new contributors to improve the simulator" are more interesting.
- Developers are free to do what they want: They work in their free time. You need to convince them voluntarily to help you.
- Development tends to be inclusive: New features are usually implemented in an optional way. Dropping existing features is very difficult.
- FG is not focused on end-user polish: Usability may lag behind commercial software. However, modern efforts like the Canvas system have greatly improved accessibility.
Test the waters
If you want your idea to become part of FlightGear (not a fork or addon), test the waters early. Use the forum or flightgear-devel mailing list. Announce your project. If your project involves software or the base package, use GitLab to conduct development in the open so others can track your work and provide feedback.
Lessons from past events:
- Beautiful airport scenery could not be committed because it used textures with a "no commercial use" license — incompatible with FG's GPL license. Check licenses early!
- A large scenery collection was structured incorrectly — scenery data must follow specific formats. Study the project structure.
- Huge patches announced shortly before a release create workload for others. Use GitLab regularly and communicate early.
Gather information
Find out who inside the project can help you. Learn how the effect framework works, how effects are configured, etc. The Wiki is your friend. Look up who has done related work (e.g., on ALS, WS3.0, Canvas). Other community members will gladly provide pointers.
Make a proposal
Do:
- Point out how your idea makes FG a better simulation.
- Be concrete about what you want changed.
- Demonstrate you have done your homework.
- Summarize your ideas on the wiki so they don't get lost.
Don't:
- Demand anything.
- Be rude or angry at criticism.
- Say FG will fail if your idea is not implemented.
- Say you "can't do anything" because you don't know C++/XML — you can learn.
Compare: "Wouldn't it be cool if we had better clouds like X-Plane?" versus "Would it be possible to extend the ALS shader system to support volumetric cloud shadows? I can provide cloud textures and test data if someone helps with the shader code."
If you have a track record of finishing projects, people are far more likely to support you. If you are new, create a proof of concept — even in Nasal scripting. Once people see you are investing time, you are more likely to get support.
Getting people involved
The most common showstopper is lack of networking and unwillingness to compromise. People want their idea implemented immediately, expecting others to drop everything. That is not how things work.
To get people involved, you need to get them interested. People are motivated by actions, not just ideas. Find overlapping areas of interest. Very often, people may not work directly toward your final goal, but toward interim milestones that are part of a longer-term roadmap.
This is exactly how recent projects succeeded:
- The Advanced Weather system started as a Nasal script and later received C++ help once it proved viable.
- The Atmospheric Light Scattering (ALS) effect was initially a shader prototype that grew into a full rendering option.
- The Canvas system took 18 months from wiki introduction to full adoption.
- The MapStructure framework unified multiple hard-coded instruments (radar, map dialog) into a single reusable system.
Successful contributors realize that overlapping areas are opportunities to get involved in other projects, learn new skills, and build relationships.
Be persistent
If you fail to get help, revise your proposal. Consider workarounds — Nasal scripting is often a viable alternative to C++, and subsystems can be converted later. Starting with something "good enough" and improving it is more likely to succeed than trying to be perfect up front.
Example: In the beginning, the idea of using Nasal to implement a weather system was not taken seriously. Once written in a working (though inefficient) way, it received C++ help and became Advanced Weather, one of the most sophisticated weather systems in flight simulation.
The perfect is the enemy of the good. Countless good proposals failed because people refused to make concessions, leading to hundreds of forum posts and wasted hours.
Honor your commitments
If someone does work for you because you promised to do XY, and you don't do XY, no one will help you again. If you cannot meet a deadline, be candid about it early.
Release early, document your efforts
Use the forum and wiki to show progress. People need to be aware of what you are doing before they can help.
For long-debated topics (multiplayer improvements, combat support, better threading, scenery improvements), there are often hundreds of posts over many years. It is not effective to start yet another debate. Instead, use the wiki to document ideas, proposals, and status over time. Some wiki articles on these topics get 12k+ views in months, while forum threads get 4k views in years.
Complex ideas often have a shelf life of 12–18 months. The Canvas system took 18 months from introduction to adoption. Use the wiki to let time work for you.
Make your efforts available for testing early. When ready, submit a merge request on GitLab, talk to someone with commit rights, and enjoy your feature being part of a future release.
Collaboration and consistency
Consistency is difficult. It requires looking at other places and potential use-cases that may benefit from your work — including stuff you never use yourself.
Examples of consistency challenges in FlightGear:
- Multiple competing I/O systems (generic protocol, httpd, telnet, multiplayer) that share similar requirements but are poorly integrated.
- Aircraft that could support AI traffic, multiplayer dual-pilot, replay, checklists, weight & balance, and the bombable addon — but most contributors only scratch their own itch.
The Canvas/MapStructure work is a success story: for over a decade, hard-coded instruments (wxradar, agradar, navdisplay, map dialog) existed separately. Canvas unified them into a framework under 1,000 lines of code, making over 9,000–15,000 lines of C++ obsolete. This took 24 months — but the result is far more accessible and future-proof.
However, this kind of work is not "fun". It involves refactoring, talking, and coordinating — not just coding. But it is what makes the project sustainable.
Case study: empowering the masses
A common suggestion: "If coders spent time making tools that take the coding out of making stuff, modders would spend time doing the rest."
In practice, this has been tried:
- The terrain texturing system now has XML-configured regional definitions and documented effects. The actual work (gathering aerial imagery, finding textures, trial and error) requires almost zero coding — just XML. Yet very few people use it.
- The MapStructure framework is extensively documented (14k+ views in 6 months) and provides a plugin system. Still, few third-party modules have appeared.
The lesson: It is not enough to build tools. Contributors need to show they will actually use them before developers invest time.
Case study: when is rendering simple?
A common question: Why do we not have simple water reflections when we have complex effects like ALS?
The answer: Graphics cards are optimized for local computations (eye → surface → light). Water reflections require non-local computations (eye → water → reflected object → light). Raytracing solves this but is too slow for real-time. There are approximations (e.g., shadow camera passes in deferred rendering), but they require significant resources.
Many things that look mathematically simple are not simple in real-time rendering. The cost-benefit analysis may be poor — would you work six months and lose half your framerate for water reflections?
(Note: First-person shooters can run fancy effects because movement is restricted to "levels." FlightGear renders from ground to orbit — a much harder problem.)