Board index FlightGear Development

5-10 Year Goals?

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

5-10 Year Goals?

Postby legoboyvdlp » Tue Jan 13, 2015 3:17 am

Has FlightGear got a list of goals for 5-10 years? How about making or adding to it? I wrote some pages of personal FG goals and possible FG Goals.

To start, why not attempt to have each and every airport with correct runways and taxiways? In the 2-3 years it would take to do, at some point there would be a scenery update?

Also, parking positions for each major airport would be nice. Like Tokyo, Houston, Beijing, and others

Also, if we want our layouts to appear in TS at SOME point if XPlane gives us a way, we submit to gateway?
User avatar
Posts: 7750
Joined: Sat Jul 26, 2014 1:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: 5-10 Year Goals?

Postby Hooray » Tue Jan 13, 2015 1:53 pm

There used to be some kind of mission statement, e.g. see: (from 1998).
And then there's a more recent wiki article trying to cover the same thing based on community activity:
The most representative long-term list of goals is probably any core developer page listing their own goals:

These days, many core development efforts have a lifetime of at least 5 years given the low number of active core developers, as well as the degree of required architectural large-scale changes - for instance, to name just a few ongoing efforts:

  • increasingly adopting OSG (since early 2006, still in progress)
  • support reset/re-init, for switching aircraft at run-time, without requiring existing/restarting fgfs (equally, people want to be able to save/load flights to continue a flight at a later time)
  • increasing focus on proficiency/flight instruction scenarios (e.g. by being able to replay/continue an approach reliably)
  • allowing aircraft/scenery to be downloaded/installed and managed from inside the simulator
  • better use of multi-core systems
  • supporting distributed setups with multiple windows/viewers and multiple graphics cards
  • adopting HLA/RTI, especially for distributed setups, but also for better leveraging multi-core systems and an improved multiplayer experience
  • making more and more subsystems configurable and entirely optional, e.g. for better troubleshooting/regression testing
  • For the past few years, the Canvas subsystems has been used to re-implement MFD functionality without requiring core development
  • modernizing the GUI
  • procedurally populated scenery ("autogen") is becoming increasingly relevant, i.e. we're seeing a lot of activity in anything involving OSM and procedural scenery creation
  • equally, people want to keep on improving the scenery engine and the TerraGear compilation suite to support more and more visibility, while also providing good performance

These are just some of the things that some of the more consistent core developers have been working towards over the last couple of years, many of these efforts dating back at least 5+ years.
There are also a handful of external efforts, including a few "internal" ones that simply got stalled at some point (think Rembrandt/deferred rendering).

Overall, FlightGear is very much evolving - not unlike HTML browsers have evolved over the last 10-15 years - however, FlightGear's evolution is taking place much more slowly, but the trend is very similar (e.g. better use of multi-core platforms, more and data-space coding etc)

In addition, FlightGear is using quite a few external dependencies/libraries that have their own roadmaps/goals (e.g. OSG or JSBSim).

In summary, it is hard to maintain an up to date list of priorities/roadmaps - simply because goals are mainly determined by those people who are involved, as well as their degree of involvement. For instance, some of the goals listed above could be considered controversial - so may not get as much support from certain contributors, but they're very actively being worked towards by some of the most active core developers. Equally, this situation may change quickly once some key people are having to take a hiatus from FlightGear core development.

In the last couple of years, Zakalawe and TheTom were the most active core developers when it came to SG/FG commits - so their statements and actions were pretty representative about the direction of the project. These days, some things have changed a little and some other core developers showed up again, i.e. veto'ing certain changes/trends or pulling into completely different directions. Equally, there are long-term contributors who are no longer as active anymore, but whose stated goals are not aligning too well with things that more active developers are working towards.

Basically, the degree of your own involvement (and influence) gets to determine how FlightGear will evolve - once you're taking a step back, you may very well have to defend your contributions/ideas and roadmaps, or they may quickly become obsolete - this can be seen in a number of areas that are no longer as well maintained (think Nasal engine, or the basic weathe system).

In other words, you should take everything said in this context with a grain of salt and look who's supporting certain changes, and if that someone is even (currently) involved or not.
The efforts I've listed above are not comprehensive, but fairly representative - however, only as long as those people around actually around, and only as long as there are no more senior contributors showing up to veto a certain change.

I do agree that it would be a good idea to ask more contributors to state their goals, and try to come up with a more recent "mission statement" - maybe just by using a subset of "meta goals" that most people can agree on. But given how FlightGear works, this may turn out to be too difficult - but it would definitely be a good thing for the sake of the project, especially given the total lack of project management.

In general, FlightGear is moving away from just being a flight simulator towards being a very flexible and generic platform for simulation needs - which seems like a logical step, but it is happening slowly.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Posts: 11925
Joined: Tue Mar 25, 2008 8:40 am

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest