FlightGear 3.0 backlog

Current release: 2020.3.19 (18 Oct 2023) Next release: 2024.1.1 (22 days from now) See release plan for details.

To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. I can't tell if that's the case for Rembrandt as I didn't have the time for any tests over the last 12 month or so. — Torsten Dreyer

and "pre-announce" 3.0 as the Feb 2014 release to give us just a little more time to prepare and make the 3.0 as polished as possible. After all, it'll be the third major release in 15 years — Stuart Buchanan

many aircraft developers in particular would want to perform some extra TLC before a major release. Externally, 3.0 is going to be considered a bigger deal than 2.12.0. — Stuart Buchanan

Declaring that the Feb 2014 release will be 3.0 now will give everyone plenty of notice, and might encourage efforts to fix bugs in the next 6 months. I'm aware that my FG development time is more limited these days, and given activity on this list I suspect I'm not alone, so this time might be quite useful. — Stuart Buchanan

Items

Please only add items that have a corresponding mentoring core developer (=someone willing and able to work on it), or items that have been marked as accepted in the issue tracker: https://code.google.com/p/flightgear-bugs/issues/list?can=2&q=FeatureRequest%20status%3Aaccepted

A more lightweight base package

For the next release (3.0, I think), I want to reduce the size of the installers by making parts of the base package optional. Some are easy, like AI Traffic and ATC chatter - the first time you enable that feature, we'll download (well, terra-sync, really) the relevant files. If you don't use the feature, you don't download the files ever. — James Turner

Random Buildings

in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Creating masks is going to require quite a bit more work in the "new world", but the end result should be better. — Stuart Buchanan

FGCom (F-JJTH)

• Integrating FGCom

Nasal (Philosopher & Hooray)

• expose hooks to access more internals, i.e. for better diagnostics (parser,codegen,VM)
• better debugging, profiling and introspection support
• provide some form of dialog to show running callbacks (timers/listeners) and their impact on performance (fps, latency)
• look at making the existing GC generational

Weather (Thorsten)

• lightfields and Rembrandt working together
• lightfields properly supported by Basic Weather Done (by Stuart for 2.12)
• lightfields integrating well with other shaders (For example, I know that the random vegetation doesn't work with lightfield shaders, and the fix that Emilian put together to allow the random buildings to work was a workaround rather than a full fix. I think this is probably something you and I will need to work on together to fix.) [1] Done (by Stuart and Thorsten for 2.12)

• a redesign of the weather interfaces, basically going to the unified weather system people have been talking about - some ideas and brainstorming urgently needed! (backed by Thorsten and Stuart) Done (by Stuart and Vivian for 2.12)

rain layers still do not drift with the wind and will be eventually displaced from their cap clouds. I've discussed this previously with James who suggested that a generic way of spawning AI objects (which can get a velocity) from Nasal rather than the current way of spawning non-AI models from Nasal which can not drift would perhaps be a solution. I don't know what the status of this is. —

Long-standing bugs

Then some fixes for long-standing, not really critical but annoying bugs

• the current rain system still only works for Basic Weather Done (by Stuart for 2.10)
• turbulence should affect YaSim and JSBSim the same way
  • http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32275.html
  • http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33134.html
  • http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40228.html
• unified weight & balance (fuel) handling (also see FDM engine feature standardization)
  • http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09582.html
  • http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30683.html
  • http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05739.html
• unify autopilot support through a shared set of I/O properties, rather than using FDM specific properties

Eye Candy

unway and other lights do not appear in the effect framework, hence they get fogged inconsistently with what Atmospheric Light Scattering is doing. I think a cheap fix would be to fade them to transparent rather than to fog color, otherwise they'd need to appear in the effect framework and then I could write a consistent shader to treat them. I don't know what is preferable. The same issue persists with particles, although that isn't as severe in terms of showing realistic low visibility for IFR (it's a bit of a spoiler then the runway lights are always visible...). —

the sun is currently pretty much always drawn, in particular also if it is below the horizon - which means that it shows inside the 'terrain' when the far away terrain is just painted onto the skydome. The sun also shows 'through' a cloud layer if the cloud layer is invisible because it is fogged. I think a property control whether the sun (moon) should be rendered would solve this. —

exposing the moon phase somewhere as a property would be nice, then the moonlight night lighting could be made automatically - currently it's property controlled and one needs to edit the property by hand to see it —

following a forum discussion about lightmaps for city and suburban terrain, my idea would be to use the urban effect for this (which has that functionality already) and run a version of the urban shader without the relief effect if random buildings are on. That appears to be working fine: {{forum url|t=21059}} FredB - is this a modification to the urban effect you can agree with? —

there's still a 'crack' in the sky visible when the skydome shader is used. Based on the color of the crack which just shows the color of the default sunlight underneath (which the skydome shader can't possibly know), I believe this is really a fault line in the geometry and that it can't be fixed within the shader code. —

Then maybe some cool, but not so important features to make things complete:

• lightning (and thunder?) for thunderstorms
• windsocks moving with ground wind rather than wind at aircraft position

Ideally, making full use of things we already have to present the best possible scenery

• regionalized random building types
• dedicated texture packs for the main vegetation zones
• exploit the placement mask possibilities fully

And then, ship 3.0 with (finally) the next edition of a world scenery release, so we can really present much better visuals! So, personally I'd like 3.0 to be a release that doesn't only have cool features, but also cool features which work basically everywhere and a release that doesn't have the current snags like 'this doesn't work with that, and the GUI is counter-intuitive and so on.

Let me be the first to admit that it's much more fun doing my own stuff the way I like and then just merge it in. But if we can find consensus about any plan having to do with integration of new features and making it all work together, then I'm willing to reserve the majority of my coding time for working towards that goal. Would this be something to aim for in a 3.0 release?

CMake Build System Issue

FlightGear versions <= 3.0 are known to have a cmake build system issue related to NOT automatically reconfiguring the SG/FG sources after updating the version files in in $SG_SRC and $FG_SRC, which basically means that using "git pull" to update your source trees (via the d&c script) will create the latest binaries, but they may not be looking for the right base package data, because the source trees are still using the old version files. This has been encountered by various contributors, including at least one core developer.

To work around this issue, simply switch into your SG/FG build directories and reconfigure each tree by running "cmake ." - for further info, see [2] [3] .

Misc

• add a standalone Nasal interpreter for people to play with Nasal without requiring a full FG sessions (Philosopher & Hooray)
• add the "Nasal Internals" docs (Philosopher & Hooray)

Related Pages

• Category:Developer Plans

Related Discussions

• A plan for a 3.0 release?
• Feature freeze 2.12