Implementing new features for FlightGear

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding, hardware support, backward compatibility etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.

Now, we do appreciate any community involvement obviously, even just people making constructive suggestions, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless, too. Indeed, as contributors, we would also appreciate it if it would suffice to just make a suggestion and provide feedback. But that's not how things work unfortunately. Still, most of us went through this whole process at least once, so we do know pretty well what it felt like, including all the frustration surrounding it, i.e. of having some great idea or vision, and seeing it not recognized as/dealt with as such.

We've had some extremely heated discussions over the years, some debating really interesting ideas and features - and many ending up being dozens of pages in size, containing hundreds of postings. Nobody in their sane mind is going to dig out such old discussions and spend hours to find the valuable stuff. But often, even such heated discussions may still contain lots of good ideas and suggestions, but sooner or later these debates become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. And even those among us who usually remain levelheaded, may find their valuable postings remain unnoticed in such threads.

In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form. Basically, some of us have literally wasted dozens of hours trying to contribute to such discussions in order to provide some direction, to no avail however.

We are now trying to document how "bootstrapping" a feature or project works conceptually from having an idea to turning it into a feature, i.e. implementing new features for Flightgear from a high-level standpoint to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own, and without necessarily having been a part of the community for years (or even decades). It's been shown that this particular model also seems to work for newcomers.

Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which nobody really came up with, but which is just a convention that happens to "just work" for all contributors, which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens", so any form of coordination, networking and collaboration must be self-directed, too.

Currently, this article is mostly based on a write-up that Thorsten contributed based on having worked on a variety of novel, and unprecedented, FlightGear features over the years which initially also didn't receive much support at all, and which also caused lengthy discussions (or even flame wars) on the forum and the devel list, including features like Advanced weather, Atmospheric light scattering, Procedural Texturing and most recently the EarthView orbital rendering engine. None of these were implemented through so called core development, which would typically mean that people change/write C++ code and have to recompile the FlightGear source code. In fact, one could see that all of these changes could be qualified as so called "mods", even though all of them have meanwhile become an official part of the main FlightGear distribution.

These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not FlightGear core developers per se, we are also primarily middleware/base package contributors, i.e. contribute to those part of FlightGear that are typically considered very "accessible", as you don't need to be a programmer to make a meaningful contribution. This means that making changes to these parts of FlightGear typically involves editing text files (XML, scripts, effects, shaders) or textures (images), sounds or 3D models.

And when we started out a few years ago (and several thousand forum postings back), we were also highly critical about the way the project works, and all its obvious shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out.

Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a lessons learnt intro based on newcomers becoming contributors, turning their ideas into features that actually end up in FlightGear, without having to be expert programmers necessarily, or even programmers at all, and without having to be familiar with FlightGear.

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 available:

• You mention it in the forum:
  A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there. Some may point you to past discussions to provide a few pointers.
• You make a formal feature request on the issue tracker:
  The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen.
• You make it your own project to get feature XY implemented:
  This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on.

Some (unpleasant) truths up front

First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail.

1. Flightgear relies on having a contributor base, but not on a user base:
   Unlike a commercial project which needs customers to survive, FG does not. A commercial project is sustained by paying customers, so that the company can pay its workers. In FlightGear, "workers" are generally not paid. And a self-sustaining project depends very much on contributors. As a result, FG development is not focused on the end user. Developers, and other contributors, tend to work on ideas and features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting. And this is something that is generally true in the wider context of the FlightGear history: technology-enablers improving accessibility and usablity that ended up getting more people involved, generally helped the simulator and community to grow over time.
2. Developers are free to do what they want:
   This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily (this is for example how this article came into existence, without the person suggesting it, being originally involved in creating it).
3. Flightgear development tends to be inclusive:
   There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers).
4. FlightGear being not focused on end-users, it may often not be as accessible/usable as a more polished/commercial piece of software. This has several reasons, which are explained below.

Obviously, we would all like to have a flight simulator that provides for an experience that doesn't involve a steep learning curve.

Often, people tend to compare usability (or lack thereof) to some great GUI tools available in proprietary simulators. Historically, however, we've learned that implementing such extremely high level end user features doesn't scale all that well. We've seen several years of time spent developing high-level features in C++ space that got quickly re-implemented, or even replaced, once middleware developers had sufficient tools at their disposal to customize the simulator through XML and scripting (for example, the existing weather system is more feature-rich than any previous weather system developed by core developers). Besides, it generally works better for the community to reuse existing tools whenever possible - no matter if it's Blender for 3D modeling, Inkscape for vector graphics, GIMP for texturing, or even just a conventional text editor for XML/script editing. Coming up with such tools from scratch, as is common in commercial software projects, would be a huge effort - obviously, having to use generic tools, also means that usability may lack at times. A couple of examples are given in this forum post and the following one, dealing with this very issue by telling about what happened when it was attempted to make development easier with terrain texturing and the Canvas system.

What this means is that developing high-level end-user features through core development often doesn't scale as well as using existing tools, customize those or just exposing the infrastructure required to allow middleware developers to implement certain features directly through existing FlightGear extension mechanisms.

Which is a win/win for both sides, because core developers get to do core development, freeing them from having to develop end-user features, while middleware developers get to evaluate end-user requests and implement popular requests.

Test the waters

If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there. And make sure that you're aware of who you're talking to, there's often a ton of end-user feedback, but little development from other contributors, which is however the only thing that matters to get your work accepted and included.

It is always a good idea to announce your project on the forum, you can also use the Newsletter to make announcements. If your project/idea is in any way about software or the base package, another good idea is becoming familiar with using git and gitorious and using it to conduct development in the open, so that others can track your work and provide feedback. This in and of itself demonstrates to long-term developers that you are to be taken seriously, because your development process is transparent and can be easily tracked.

Some events that have occurred in the past, and what to learn from them:

• Beautiful airport scenery (and certain aircraft/cockpits) could not be committed, because it was textured using material from a source that has free textures with a no commercial use clause. This however is incompatible with FGs GPL license which permits also commercial use. Lesson: If you use any material other than your own work, check the license early!

• A large collection of Swiss airport scenery could not be committed because it was structured in the wrong way - scenery data has to be submitted in a certain format to the scenery database, other data to the FGData repository. Lesson: Study the structure of FG - don't expect that the whole structure of the project will change for you, it is what it is for good reasons, even if you don't know them, others do.

• The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say.

• Huge patches for novel features were announced shortly before a release, providing little time to thoroughly test and integrate the patches in time for the release, while also creating a huge workload for other developers who were not aware of the effort, and may have made conflicting changes in the meantime - something like this can be prevented by using gitorious regularly, and by getting touch with other developers to make them aware of your plans, but also your implementation strategies - ideally, asking for feedback on how to proceed best in order to avoid coding conflicts.

Gather information

Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about. It is also a good idea to look up who's previously done related work, or who's recently been working on similar ideas and projects, so that you know who to get in touch with. Usually, other community members will be glad to provide pointers to related projects and their contributors.

Make a proposal

Now it's time to approach the people who can help you. Remember - they're volunteers. So you need to get them interested.

Do...

• ... point out how your idea will make FG a better simulation.
• ... make a point out of what you would be willing to do if only XY were available.
• ... be as concrete as possible, point out what precisely you would like to see changed.
• ... demonstrate that you have looked at the relevant information and know what you're talking about
• ... provide a summary of your main ideas using the wiki, in case the discussion leads nowhere, people can still pick up the whole thing at a later time

Don't...

• ... demand anything from anyone.
• ... be rude or angry if people are critical - it's part of the process.
• ... point out how bad FG is going to be or how it will fail if your idea is not implemented
• ... say that you're going to abandon the project or switch to a commercial product
• ... say you can't do anything, because you don't understand C++, coding or XML - the human mind can learn

Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support?

Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept', you can help improve you signal/noise ratio significantly by ensuring that you follow up on your commitments and do the necessary behind-the-scenes networking to implement a new feature or project.

It is this combination of having a track record, or "credit", and a good signal/noise ratio that will ultimately give you certain leverage when interacting with other contributors. Overall, time spent contributing to the project really is our "currency-it shows dedication and discipline and it demonstrates to potential collaboratos that you are serious about your commitments, and that teaming up with you is not a waste of their time. If properly done, such networking can be a great multiplier/lever.

If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support.

Finally, proposals failing may still happen for other reasons, such as bad timing, lack of man power, people being busy with other aspects of FG or RL etc. This happens even to long-term contributors regularly, including core developers.

Getting People involved

One of the most common show-stoppers preventing people from succeeding with their ideas, feature requests or projects is the lack of networking, and the unwillingness to compromise and make sacrifices.

The common pattern we get to see is that people want their particular idea to be implemented immediately, expecting others to drop pretty much anything else and provide first-class support to them. Obviously, this is not how things work - just imagine for a second, somebody were to ask you to drop your own ideas and projects in favor of some random new idea, in a volunteer project.

the main problem seems to be "tunnel vision", things have to be done in a certain way or they're considered inferior inevitably, which also isn't helping - but technically, we have more building blocks in FG to create a dogfighting WW2 environment than we have building blocks for any modern airliner simulation. If you don't believe me look up any well-developed airliner, and check those todo lists - the majority is about FG issues, i.e. things that cannot be worked around easily. In fact, in the pre-Canvas days we had clever guys like omega95 who used massively complicated XML animations to come up with a navigation display, despite lacking a 2D drawing API. But that was basically a dead-end. And even in the Canvas days, there's a ton of stuff that isn't currently supported easily. A WW2 simulation would not encounter many real showstoppers, there's a ton of stuff that can be accomplished even without any explicit support, as can be seen in flug's bombable addon - he never got any support from core developers to pull all that off, it's all his own work, representing probably hundreds of hours of testing, designing and coding. — Hooray (Thu May 01). Re: Trouble at EDDF-Triangle.

However, there is a way to have your cake and still it eat, by going more slowly, and by sharing.

To get people involved, you need to get them interested, and you need to motivate them.

People are not just motivated by ideas but by actions that materialize, and short of that, by saving their own time. Sometimes, it may be helpful to not just introduce the final outcome, but also the pathway to make it happen.

Usually, most contributors have different ideas about FlightGear, and very different priorities, skills and expertise.

So the point really is compromising. Finding overlapping areas of interest, i.e. common goals. Very often, that means that people may not directly work towards the original goal/project (such as for example an improved multiplayer system, a weather system or even combat support), but rather some interim milestones, as part of some longer-term roadmap or bigger picture.

That way, contributing becomes pretty much a journey, where you may meet people willing to accompany you for a certain time, task and project, until their own goals have been reached, or until they join some other effort (or even project). Sometimes this journey make take a few months or even years, but often it's really just a few weeks or even just days that someone finds some of your project overlapping with his own goals and interests, such as for example programming shaders/effects or doing Nasal scripting or helping with Canvas related projects.

This may seem frustrating at first, but you should cherish such opportunities, no matter how short-lived they may be, for they provide an excellent networking opportunity, getting more people involved in your project, but also to become better known to fellow contributors.

In retrospective, this is exactly how some of the most popular base package projects took shape recently, despite a lack of momentum initially: People were willing to compromise their original goals by talking to others who had somewhat overlapping, or at least sufficiently similar, goals and found a way to collaborate to a certain degree, even though every contributor would still keep his own long-term goals and priorities in mind. Sometimes, this requires a significant shift in thinking and creative or very unconventional ways to explore a new solution space.

In general, it is unlikely that you'll be able to directly form a team of people who fully share your motivation, goals and roadmap - and even then, you may find yourself missing other components that are required for a successful project, such as expertise in certain areas (3D modeling, texturing, programming, scripting, effects or shaders etc).

This is why you'll typically have to reach out to other contributors and ask them to get involved. And this is also exactly where most people fail right from the beginning: because they're more focused on their own goals and projects, than demonstrating to fellow contributors, how they can help improve others lives, i.e. by learning more about other projects and efforts, and potentially overlapping areas there, to contribute to similar projects first, before asking others to contribute to theirs.

Typically, this means that you must be willing to adjust your own priorities - while it may seem of utmost important to you to work on feature X, some other contributor may be more interested to work on something that you don't consider extremely important, or maybe even making concessions that you don't consider acceptable (such as e.g. supporting mouse-control in a combat sim, or using scripted code to implement a space rendering framework) - this is where most people fail big time, discussions start becoming enormous, vocabulary harsh - and at some point, there's no collaboration feasible anymore. Potential contributors with a track record often start losign interest quickly, so that the whole project gets killed quickly, or is left with zero manpower - just with people having ideas and "visions", but nobody able to actually implement them.

But this is one of the most important aspects of successfully "bootstrapping" a new project: finding overlapping areas, contributors who can help with related efforts, and making compromises, i.e. accepting that you have to walk before you run.

Conceptually, this boils down to thinking in terms of components, i.e. "building blocks", that need to be established in order to accomplish something. It is very likely that a dozen unrelated projects may benefit from very similar building blocks, depending on the viewpoint - typically, there's at least a handful of needs that projects may have in common. Sometimes, you may need to extend your own plans beyond what seems reasonable to you, while limiting your original goals to a subset of the original idea, just to get something started.

Note that this doesn't have to do anything with programming, building blocks can just as well be non-coding items, like textures, sounds, instruments, 3D models etc.

Successful contributors realize that such overlapping areas are an excellent opportunity to get others involved, but also to get involved in other projects, that may not be directly related to their own area of interest - i.e. to learn a new skill, or even just introduce yourself to a contributor with a known track record and certain skills, to pave the way for future collaboration.

For instance, some of our most active contributors have very little time to provide support to end-users or even just to maintain their documentation, this could be a great opportunity to introduce yourself to a contributor - you're demonstrating that you're interested in contributing, while also saving them some time, so that they can work on other projects, so that you inevitably show up on their "radar".

There are some contributors who have never contributed to the software itself directly, still they managed to shape the project through lots of feedback, simply because they have become important in other aspects of the project, which are also important - no matter if it's the forum, the wiki or other aspects of the infrastructure surrounding the project.

Still, there may be areas with little, if any, momentum and where networking doesn't seem feasible, this is where you may have to make an upfront investment to get other contributors involved, i.e. reach out to re-implement/replace features or infrastructure with parts of your own work. This is basically a pretty safe way to get more eyeballs involved.

Be persistent

If you fail to get help you need, think about why-and don't take it personally. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal scripting often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form, i.e. to build momentum over time. Seriously, the perfect is the enemy of the good here - we've seen countless of good proposals that simply failed because people were not willing to make concessions, people would see problems with any workaround and imperfect solution suggested by others - so what they ultimately got in return was a "perfect" design, discussed across hundreds of postings, usually wasting dozens of manpower hours of in the process.

As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation.

Likewise, one of the most-heated discussions in the history of the FlightGear forum involved bringing space flight or combat support to FlightGear - these discussions took place over many years, brought up by various individuals - but most people would only see the limitations in the suggested approaches, so that the system they envisioned was never implemented - and in retrospective, it would have taken them a tiny fraction of the time spent debating with others to come up with a very basic working prototype, which is a great momentum builder.

Honor your commitments

This should go without saying but: Keep your end of the bargain. Seriously. If you got someone to do a month of work for you because you proposed it would enable you to do XY and you in fact don't do XY later, that's pretty much it - no one will ever lift a finger for you from that point. This may never be publicly discussed, but people will notice it and will refrain from collaborating with you once they have witnessed something like this. If you cannot make some deadline, it's better to be candid about it and announce it early-on, ideally offering to catch up ASAP or offer to volunteer somewhere else instead.

Release early, document your efforts

Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum. It is also always a good idea to do a forum/devel list search to check the archives for related discussions that took place in the past, this should give you a good idea on discussed approaches, but also people involved in these discussions (and if they're still around or not).

While the forum and the devel mailing list are great places for discussions, there are sometimes topics that have been discussed at great lengths, this includes topics like multiplayer improvements or even combat support for example.

For such popular discussions, there are often 5-10 threads per year on the list/forum with typically dozens of responses. Another popular debate is better multi-threading support, but also scenery improvements, providing better end-user support and accessibility, improving hardware support for lower-end hardware, funding/crowd-funding/sponsporship schemes and even setting up a non-profit to help FlightGear.

Accordingly, given the popularity of these topics, there are typically hundreds (or even thousands!) of postings and statements that have been made over the years.

Often, with little -if anything- materializing from such debates directly, no matter how good the discussed ideas were. Postings may contain good suggestions, useful feedback, but also lots of controversial arguments. And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved.

Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of actual features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time.

Time really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change parts of the project's philosophy (see Release Plan) or some of its infrastructure (e.g. the FlightGear Build Server). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years and also by different people.

Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time, while providing an entry point for people interested in a certain topic. For instance, some of the aforementioned flamewars ended up having ~4000 views in over 2 years, compare that to wiki articles covering the same topic, getting 12k views in just a few months. Go ask yourself, how would you prefer to be introduced to some novel idea that you may want to work on at some point ?

We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA and reset/re-init efforts are other ongoing examples for this. Typically, complex ideas may very well have a shelf life of several months - often even, 12-18 months. The Canvas system only took shape 18 months after it had been introduced on the FlightGear wiki for example.

Thus, sometimes good ideas may take time to materialize, for momentum to build up - and whenever timing doesn't seem to work in your favor, it's a good idea to let time work for you instead, by creating a corresponding wiki article to document something, and maintaining it over time, e.g. by adding links, quotes or references to related discussions. To provide another example: We've had various discussions on coming up with a scenery build server, and this is something that is slowly starting to materialize now - largely thanks to having a dedicated wiki article presenting an overview about past discussions and ideas, and all this took really just a few months - but those were spread across almost 3 years now. But the wiki article allowed us to still build on existing ideas and discussions, without requiring people to spend hours in the archives.

Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release.

If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!

Collaboration and Consistency

people won't change a single thing by just debating - even if they should be completely right. And being ignorant about how the project works behind the scenes, will not help much either. This is not to say that we all "like" the way the project works, but the way things are working is not by conscious decision, but due to people caring about their own stuff, with little to zero interest for getting involved in other projects. Simple as that. It is the few cases where people manage to work around such issues and actually collaborate that FlightGear is shaped in major ways. Nasal, Canvas, NavDisplay and MapStructure are testimony to this working extremely well - but it's tedious and not exactly "fun" to work like this - just ask TheTom, Gijs, Philosopher or myself: It is much more fun to focus on our own little projects than keeping the big picture in mind and coordinating things behind the scenes. — Hooray (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

the thing is that consistency is a b*tch to get "right" There are obvious areas like backward compatibility where consistency would help us a great deal. But being consistent takes a great deal of work, not just in your own working areas, but especially in other areas that you have never touched. Being consistent takes a lot of time, dedication, discipline and skill and a ton of networking. And it really isn't fun at all We have an infinite number of examples for this being the case in FlightGear. It's not just our lack of standardized XML processing. The whole MP/MMO debate is basically about the same thing - competing/conflicting features that never got updated and integrated, so that they end up crippling each other. And we end up having a dozen way to "skin a cat" semi-properly Being consistent means that "coding" (or even 3D modeling or developing FDMs) is suddenly no longer "just" about your own work, but looking at all the other places and potential use-cases in FlightGear that may benefit from it, including stuff that you never used, and never intend to use yourself. — Hooray (Wed May 14). Re: scaling instruments in xml.

To see for yourself, just ask yourself if any of your recent work (textures, 3D models, livery packs, FDMs, FDM components, autopilots, scripts, instruments or aircraft) can be easily used outside the context/scope that you designed them for originally ? For instance, how easily can your aircraft: support being used by the AI traffic system ? support different liveries, liveries over MP ? dual-pilot use across multiplayer ? the weight& balance dialog ? the replay/flight recorder subsystem ? checklists ? autopilot dialog ? the bombable addon ? ... These are all features in existence today that could be supported by aircraft developers - but most contributors only really scratch their own itch understandably And that's really just the non-coding side of things - for programmers, pulling off consistent designs is often even more difficult. — Hooray (Wed May 14). Re: scaling instruments in xml.

As a coder, you permanently need to re-evaluate your own design and look at other/similar features, and see how those affect each other potentially - and be willing to modernize and re-implement certain stuff. There's stuff like our networking stack, and the I/O system, along with its generic protocol system - and a httpd/telnet system, and of course the multiplayer system. All of this came into existence at different times - so are hardly integrated, even though they're sharing almost identical requirements, and could be re-implemented on top of 3-5 building blocks probably. — Hooray (Wed May 14). Re: scaling instruments in xml.

The thing about consistency is that it needs to be future-proof, too - i.e. in case someone leaves the project for a while, or even completely abandons a project. And that's when becoming a "visionary" is almost as important as being a "designer" of some new project or feature. Which also means that solutions must not be "lock-in" solutions, but need to be sufficiently well-understood and documented to either allow others to review/maintain them over time, or let them completely revamp/replace them if needed. We always tend to see the problems in solutions that others come up with, but refer to our own contributions as "hacks", "workarounds", or more eloquently, "prototypes", even though they typically have the same issues and effects on projects and features developed by others Yet, those very "prototypes" often end up being around for several years until someone comes up with something better or some major improvement. At the end of the day, we're all just that: lazy human beings - and volunteers at that, too - i.e. we are really only motivated by stuff that's not a chore, but it must be fun. So you end up with a huge herd of cats that don't want to be organized at all ... — Hooray (Wed May 14). Re: scaling instruments in xml.

Then again, there are a few people doing the unpopular "grunt" work here, i.e. constantly refactoring things, and permanently looking at the bigger picture to generalize stuff over time. However, their work is usually not at all "visible" or even compelling to non-developers, often not even to developers. We're really here to scratch our own itch and not contribute to some "global cause" that we may never benefit from at all. Asking for better and more consistency is however exactly doing that: asking people to drop the "interesting & fun" stuff in favor of improving things for the long-term, without them necessarily benefiting from such work (or without it being obvious to them). Understandably, that's kinda frustrating - not just for the people asked to do the work, but also for those asking for it — Hooray (Wed May 14). Re: scaling instruments in xml.

magine for a second you had spent 18 months working on a new project/aircraft/feature, and everybody is proud of your product, but suddenly someone comes around and says something along the lines of this is all great, but it's not future-proof, what you should really be doing is neuter the whole thing, split it up into a dozen modules, generalize each component to make it accessible to other users, and please don't complain about regressions - there certainly will be many, and we won't have much time to help you, but it's basically the right thing to do, and it needs to be done ASAP This is pretty much what's happening to many developers who come up with useful, but non-generic, stuff - especially in a healthy software development environment, where people are constantly reviewing their own code. We've had many such discussions here in the past, i.e. when the random buildings system got first introduced, Thorsten and I were the ones discussing potential scripting hooks to make it less random and expose it to scripting space, so that placement heuristics could be based on other data (i.e. OSM). Back then, that was not a popular thing to ask for, the response was "this only has theoretical merits..." - 3+ years later, this is what people are looking into now So being consistent really is a painful thing unfortunately, because it means more work, less time for interesting stuff, much more networking - and the outcome may still be uncertain, and it may cause frustration among contributors, too. — Hooray (Wed May 14). Re: scaling instruments in xml.

For instance, when one aircraft developer came up with the new NavDisplay code, we had been talking with Zakalawe about doing kinda that as part of the map dialog - and I was pretty frustrated seeing code that was more complete than mine, but on the other hand much less generic (not as re-usable), i.e. it being aircraft-specific, single instance, single style, too slow etc And raising my concerns, the 747 developer was the one saying "not a high priority for me" and next: "but, ok be my guest" (which is very common around here!). So that's how the whole shebang got split up into ~20 different modules, introducing a plethora of regressions/bugs (that he gratefully ignored!), slowing down his progress and overall development by at least 6 months in the process, and introducing a degree of complexity, so that the original developer no longer felt responsible for the modified code, or even refused to work with it afterwards As you can imagine, this sort of thing ...case. So, all the while we'd been trying to be more consistent, and then that - and looking at the extra500 commit history, we're apparently having a hard time inviting them to be more consistent by adopting our framework now. And that's what kinda everybody is going through here - Thorsten also mentioned various times that it would be so much easier to just code his own stuff than having to maintain compatibility with other/similar or even conflicting features (e.g. basic weather/rembrandt). It really is hard to understand why we should accept such issues without being also paid for all the frustration resulting from all this Honestly, consider this a freakin' petri-dish in which software evolution simply takes place and you'll have a much better time — Hooray (Wed May 14). Re: scaling instruments in xml.

The Canvas/MapStructure work is another example for this: for over a decade, we've had various hard-coded instruments, a hard-coded GUI library, and certain 2D rendering code that could only be used within a fixed context, like 1) cockpit, 2) GUI, 3) scenery. It's only recently -thanks to canvas- that this is being unified and re-implemented, to hopefully get rid of a plethora of legacy features and modernize them through canvas and scripting space wrappers. Previously, people could not render an instrument/HUD in a dialog, or vice versa - yet, this is a key feature, because supporting recursion means that even features like interactive map editors can share the same back-end code. — Hooray (Wed May 14). Re: scaling instruments in xml.

Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term. This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code. But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time. — Hooray (Wed May 14). Re: scaling instruments in xml.

Some context on different perceptions

Assume you have this interesting feature in mind which is not in FG. Chances are, you assume that just nobody thought about having it before. Chances are however that this assumption is wrong (a rough estimate would be that perhaps 5% of the suggestions are of that type). People working e.g. with shader effects have spent thousands of hours working with rendering code and usually have a habit of comparing nature and FG to see how to improve things. They also know what other games do and have read books and tutorials on GLSL shaders. So what's the case most of the time is that if a feature is not there, it failed a cost-benefit analysis - either it's not interesting enough so that it's low on a to-do list, or it would cost too much framerate to implement it, or too much coding time. If it'd be interesting and easy to do over the weekend, someone would have done it already. As a result, the reaction to simply suggesting the feature will be along 'Oh yeah, thought about this a while ago, not so interesting...' So if you want to change this, you have to understand and change the cost-benefit analysis.

Case study - about empowering the masses

If the coders here at FG spent their time (1000 hrs) making the aps / tools that take all the coding out of making stuff, then the modders those with little coding knowledge would spend the 3000 hrs doing the rest. — Bomber (Thu May 29). Re: Does FlightGear has Multiplayer Combat mode?.

Basically, that's what's been happening over the last few years in various areas, especially canvas - however, rather than focusing on "tools" or "apps", developers tend to focus on infrastructure and building blocks - often using existing standards and established technologies, so that existing tools can be used, without those having to be coded from scratch (XML=>XML editors, Blender/AC3D, textures: GIMP, sound editing, GRASS/QGIS etc) — Hooray (Thu May 29). Re: Does FlightGear has Multiplayer Combat mode?.

Here's my personal experiment with this: Making terrain texturing look better. After a few years of coding and nagging others to code, we now have xml-configured regional texture definitions general-purpose xml-configurable effects for the terrain and the best - all controlled from the same file! and the whole thing documented in the wiki and my personal help for people who want to do it in the forum It's the classical grunt task - most of the actual work is gathering aerial imagery of an area, finding or making the textures you need and lots of trial and error with different texture schemes - almost zero coding requirement, the necessary xml you can pick up in an afternoon if you don't do cut and paste. And it makes a hell of a difference for the visuals of a region, more than any amount of CORINE data or static models can do. The net effect is that I still do 90% of the regional te...s me is a few days. Some folks use it for custom scenery, and every once in a while someone makes a definition that can actually go to GIT, but it's really the opposite of what you claim to be true - there's lots of time invested in an easy-to-use tool which enables people to make 'their' region much better - and what happens is that nobody uses it. It's simply not true that the grunts would appear and start working if only they had the proper tools / the documentation / the whatnot. The fact of the matter is that I've almost never seen it happen, so by now my prevalent philosophy (born from that experience) is that I want to see very solid evidence that someone will actually use any tool requested from me before I consider coding it. — Thorsten (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

We've actually tried that with the MapStructure framework, which is rather extensively documented now, and which even provides kind of a "plugin" or "module" system, where people can easily add their own map layers for custom stuff. While the documentation is obviously very popular (14k views within just 6 months), we still have to see someone else step up and actually adopt the system. Admittedly, FlightGear 3.2 is going to be the first release that will provide most of the building blocks required here, but currently it doesn't seem likely that there will be dozens of modules provided by others, despite us having taken the time to work out a system, and document it rather well. Still, I don't regret having spent that time, because the contribution is at least "future-proof" that way - i.e. it doesn't matter if we're around or not, because people can look up all the required info and actually understand the code sufficiently well to improve/maintain the system, or...d of seeing someone contributing something back is exponentially higher once certain criteria are met, i.e. either a corresponding track record, absent that, a strong willingness to follow advice, or at least acquire knowledge and follow pointers. Ultimately, the question still boils down to motivation - we've seen some very experienced contributors/core developers who agreed that certain features would be "good to have", but who still didn't care enough to actually work on those - at least, they stated so upfront Seriously, the same people asking for GUI tools like an aircraft, scenery, texture or mission editor are usually the same ones who refuse to use existing tools like Blender, GIMP, QGIS/GRASS or even just a good XML editor. — Hooray (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

Case study - when is rendering simple?

A fairly recurrent question is why, with all the rendering effects we have on models, we don't have something simple as a reflection in water. After all, the math to determine the varying colors of a cloud at sunrise dependent on whether the light shines through them or not is university level, one needs to solve two nested integrals for the correct answer, whereas everyone knows how to compute a reflection.

The problem is that real-time rendering is not simple when the math is simple, but when it can be parallelized. Graphics cards are built to solve a particular problem very fast - when a ray from the eye (E) hits a surface (S) and then is tracked to the light (L). If at the pixel location the surface normal is known, all relevant vectors are knows without having to know anything else about the scene, the computation is purely local and can be parallelized. So whenever an effect uses an ESL situation, it is simple to implement.

Water reflection however needs to compute at minimum ESSL (follow the light from the eye to the water, then to whatever is reflected in the water, then to the light). Raytracing codes solve these problems just fine, they track a large number of test rays from the first surface hit to everywhere else in the scene to see where the reflected light comes from. However, that doesn't run real time - if you use 10.000 test rays, the computational effort goes a factor 10.000 up and the framerate down by the same factor. What's perfectly okay if you can take a minute to render a picture is not if you need 60 per second.

There are ways around this, for instance shadows are also ESSL problems, and they can (approximately) be solved by techniques like a shadow camera pass in deferred rendering (Rembrandt in FG) - then the scene needs to be rendered just two times, which is a more acceptable value. But then this needs lots of additional resources and cleverness.

Lesson here: Many things which look (and even are mathematically) simple to do are not implemented because they are not as far as real-time rendering works because they are not ESL, and hence their cost-benefit analysis is judged poor. Clouds reflecting in a pool of still water are a cool effect but - would you work half a year for coding it and have your framerate reduced by half - would that still be cool?

(Side note: Plenty of first person shooters and racing games can run very fancy 3d effects. However, they can also run very agressive optimization because your movement is very restricted to 'levels' - so the fact that game XY can do something doesn't mean that FG where we need to render scenes from the ground into orbit can do the same thing.)