Post FlightGear 2020.2 LTS changes: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Code clean-ups and changes: https://sourceforge.net/p/flightgear/mailman/message/37148477/)
 
(33 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Current status ==
{{Mergeto|Building using CMake}}
'''06/2020''':
James has pushed some configuration changes to next (SG+FG) to raise various required versions of things.
If you’re developing on ‘something fairly recent’, you shouldn’t see any difference except it would be a wise time to wipe your build dirs and re-CMake from clean. If you’re on a ‘somewhat older’ Linux, the baselines being Ubuntu 18.04 (their previous LTS) and CentOS 7 (which our Jenkins runs), you should also be fine except for GCC, where you will need a version supporting C++14: in practice this means GCC 5.x or higher. (Or use Clang…) For both of these distros there are officially supported ways to get newer GCCs (we’re actually using GCC 9 on Jenkins now..), so I don’t expect this to be a problem.
As part of this we now require CMake 3.10<ref>https://sourceforge.net/p/flightgear/mailman/message/37094732/</ref>, Qt 5.9 and OSG 3.4.1, and James started removing various legacy pieces from next around this. There are plenty more cleanups that can be done based on this : especially on the CMake and C++ sides. Things like Boost -> Std stuff, Cmake targets-as-objects support (eg, target_compile_features can be used now).
Windows and macOS should be unaffected BTW - because on those platforms you're always running something you downloaded which is fairly up to date. If you choose to go and download an ancient version of CMake or Qt, on either platform that’s your problem to fix - but you’ll get a configuration error at least.
The idea of doing this /now/ is that the build deps won’t change again during the next two years, barring any surprises.
None of this affects the release branches of course: they continue to work with OSG 3.2, GCC 4.x, Qt 5.4 and CMake 3.0. And you shouldn’t see any behavioural changes because of this either.
Let’s see if reality corresponds to all the theory above :)<ref>https://sourceforge.net/p/flightgear/mailman/message/37041064/</ref>
'''08/2020''':
James pushed a large overhaul of the Cmake build files for FlightGear:
* we now use modern Cmake style nearly everywhere, i.e targets-as-objects for an OOP-style build system
* transitive dependencies are handled automatically (or at least, that’s the idea…), which simplifies things in many places (eg, audio library handling)
* system vs built-in dependencies is handled vis ALIAS targets, so most other code doesn’t care. We link to a target which is an alias for either our built-in version or the system one (via an IMPORTED target)
* we should have better isolation from system headers / versions of things. <ref>https://sourceforge.net/p/flightgear/mailman/message/37091728/</ref>
== Changes that are already on next ==
== Changes that are already on next ==
{{Mergeto|Changelog 2020.1#Replay_.2F_Flight_Recorder}}


=== Record/replay ===
* [[YASim#Torus-shaped_contact_surface_on_next]] - YASim tyre contact surfaces.
 
* [[Video_encoding]] - video encoding of Flightgear's main window.
* Include multiplayer aircraft in recordings.
* [[Instant_Replay]] - new Record/replay functionality.
* Continuous recording to file without any loss of detail.
* [[Highlighting]] - highlight animated parts of the user aircraft and show associated properties.
* Periodic generation of a recovery snapshot, allowing resumption after a flightgear crash.
* [[ExtraViewWindows]].
 
* [[SimpleTime]] - an alternative to [[Real_Time_manual|Real time]] mode.
See new '''File''' - '''Flight Recorder Control''' dialogue.
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Simplifications to Multiplayer carrier operation]].
 
==== Details ====
 
* Continuous recording to file is uncompressed to simplify replay; e.g. 100MB for an hour's recording near EDDF.
 
* A recovery snapshot is actually a single-frame continuous recording, and will be called '''<aircraft-type>-recovery.fgtape'''. Load in the usual way using the '''Flight Recorder Control''' dialogue or on the command line with '''--load-tape=<aircraft-type>-recovery'''. Then do '''Ctrl-R''' to see replay dialogue and click on '''My Controls'''. I think that some aircraft may have no or limited support for '''My Controls''' though?


== Code clean-ups and changes ==
== Code clean-ups and changes ==
{{Mergeto|2022.X Release Plan}}


Collecting what's going to change : this will also be used to work out what manual or automatic migrations are required to keep aircraft working. It's expected that for the first few months of 'next', there will be higher than usual breakage, i.e regular  might not be possible.
Collecting what's going to change: this will also be used to work out what manual or automatic migrations are required to keep aircraft working. It's expected that for the first few months of 'next', there will be higher than usual breakage, i.e regular  might not be possible.


As a general guideline, the minimum system to develop / build the code on will be Ubuntu 18.04 LTS (Bionic) : the versions below correspond to what is available in a stock Bionic install.
As a general guideline, the minimum system to develop / build the code on will be Ubuntu 18.04 LTS (Bionic) : the versions below correspond to what is available in a stock Bionic install.
Line 51: Line 18:
# Make C++14 (possibly C++17 to facilitate {{Abbr|VSG|Vulkan Scene Graph}} [[Vulkan Scene Graph|migration]]? <ref>https://sourceforge.net/p/flightgear/mailman/message/37041706/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37042499/</ref>) the minimum required version (will make it easier to continue [[Deboosting FlightGear|replacing Boost]] items with std:: ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/36988831/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36984349/</ref>
# Make C++14 (possibly C++17 to facilitate {{Abbr|VSG|Vulkan Scene Graph}} [[Vulkan Scene Graph|migration]]? <ref>https://sourceforge.net/p/flightgear/mailman/message/37041706/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37042499/</ref>) the minimum required version (will make it easier to continue [[Deboosting FlightGear|replacing Boost]] items with std:: ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/36988831/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36984349/</ref>
# Make CMake 3.6 the minimum required version: this will allow simplifying a bunch of compatibility logic in the build files <ref>https://sourceforge.net/p/flightgear/mailman/message/37020794/</ref> {{Progressbar|70}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37091728/</ref>
# Make CMake 3.6 the minimum required version: this will allow simplifying a bunch of compatibility logic in the build files <ref>https://sourceforge.net/p/flightgear/mailman/message/37020794/</ref> {{Progressbar|70}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37091728/</ref>
## <del>Blocked by: [[OSGText Issues]]</del> <ref>https://sourceforge.net/p/flightgear/mailman/message/37284981/</ref>
# Use CMake OBJECT_LIBRARY to improve how we collect sources together when building each sub-dir {{Progressbar|10}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37042800/</ref>
# Use CMake OBJECT_LIBRARY to improve how we collect sources together when building each sub-dir {{Progressbar|10}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37042800/</ref>
# Make Qt 5.9 the minimum for the launcher {{Done}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37041064/</ref>
# Make Qt 5.9 the minimum for the launcher {{Done}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37041064/</ref>
Line 66: Line 34:
* {{done}} Improved view support - so that the nearest tower will include carriers
* {{done}} Improved view support - so that the nearest tower will include carriers
* {{done}} Changes to core code to support moving towers.
* {{done}} Changes to core code to support moving towers.
* {{Progressbar|50}} Multiple (tower) views - permit selection of LSO, PLAT and Tower as part of the "Tower view"; selection mechanism TDB. Consider revisions to the existing view system to better support this.
* {{Progressbar|80}} Multiple (tower) views - permit selection of LSO, PLAT and Tower as part of the "Tower view"; selection mechanism TDB. Consider revisions to the existing view system to better support this.
* {{done}} Extend XML to include definitions for FLOLS touchdown position, LSO view position, Tower View position, deck angle.
* {{done}} Extend XML to include definitions for FLOLS touchdown position, LSO view position, Tower View position, deck angle.
* {{Progressbar|50}} Improve 3d models for IFLOLS to ensure that a ball call can be made.
* {{Progressbar|80}} Improve 3d models for IFLOLS to ensure that a ball call can be made.
* {{Progressbar|80}} Improve logic for IFLOLS lights; not quite an LSO simulation more of an approximation of the definitive cases (e.g. waveoff)
* {{Progressbar|80}} Improve logic for IFLOLS lights; not quite an LSO simulation more of an approximation of the definitive cases (e.g. waveoff)
* {{pending}} Animate the lineup lights on the stern (of Nimitz class).
* {{pending}} Animate the lineup lights on the stern (of Nimitz class).
* {{Progressbar|90}} Improved support for Precision Approach Landing System (PALS) (AN/SPN-46); to support lineup deviation as well as glideslope (ball) deviation.  
* {{Progressbar|100}} Improved support for Precision Approach Landing System (PALS) (AN/SPN-46); to support lineup deviation as well as glideslope (ball) deviation.
* {{Progressbar|70}} Change approach deviations to use new aircraft reference point rather than eyepoint; it is probably more correct to use the eyepoint when in the cockpit view - but for external views this can be slightly inaccurate when outside the aircraft to completely wrong when in tower/LSO view. The reference point is taken as the aircraft position with an optional model defined x,y,z offset. This allows ball tuning on a per aircraft basis.
* {{Progressbar|70}} Change approach deviations to use new aircraft reference point rather than eyepoint; it is probably more correct to use the eyepoint when in the cockpit view - but for external views this can be slightly inaccurate when outside the aircraft to completely wrong when in tower/LSO view. The reference point is taken as the aircraft position with an optional model defined x,y,z offset. This allows ball tuning on a per aircraft basis.
* {{Pending}} Improved support for AI logic to permit XML definition of e.g. LSO logic. Possibly a version of the autopilot / state machine that can be included as "logic blocks"
* {{Pending}} Improved support for AI logic to permit XML definition of e.g. LSO logic. Possibly a version of the autopilot / state machine that can be included as "logic blocks"
* {{Pending}} Review 3d model usage for all Nimitz class and either add LOD selection (low, medium, high)
* {{Pending}} Review 3d model usage for all Nimitz class and either add LOD selection (low, medium, high)
* {{Pending}} Possible extra visual aids for Case 1 and Case 2 recovery training (e.g. a set of markers to fly through)
* {{Pending}} Review and include Marsdolphin contributions for MP Carrier (i.e. MP trumman)
*{{Progressbar|20}} Possible extra visual aids for Case 1 and Case 2 recovery training (e.g. a set of markers to fly through)
* {{Pending}} Better integration of carriers with JSBSim to permit catapult hookup
* {{Pending}} Better integration of carriers with JSBSim to permit catapult hookup
* {{Pending}} Simulate carrier operations Flight Deck Personnel, e.g. yellow shirts.
* {{Pending}} Simulate carrier operations Flight Deck Personnel, e.g. yellow shirts.
Line 84: Line 53:


== Possible additional items ==
== Possible additional items ==
Once the hackathon is done, we should merge compositor, and then once the build is stabilised, merge composite viewer: i,e during ‘the rest’ of November 2020.<ref>https://sourceforge.net/p/flightgear/mailman/message/37147622/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37148460/</ref>
{{Main article|2022.X Release Plan}}


=== osgText ===
===2D Panels ===
{{Main article|OSGText Issues}}
{{Caution|See James' comments about pixel-level compatibility at [[Shiva Alternatives#Testing]]}}
{{Main article|2D Panels}}


=== CompositeViewer ===
The idea is to remove all 'raw' OpenGL or OpenSceneGraph code from the panel code, it should be 100% done with Canvas elements. Eg use the Canvas Transform to compute the matrices<ref>https://sourceforge.net/p/flightgear/flightgear/merge-requests/217/#a8d5</ref>
{{Note|CompositeViewer integration would entail raising our [[CompositeViewer_Support#Issues_when_using_OpenSceneGraph-3.4|required OSG version to 3.6]] <ref>https://sourceforge.net/u/cgdae/flightgear/ci/d52392ee8190a315dd920e05963ae6730843ecbc/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37147659/</ref>}}
* [[Canvas_News#2D_Panels|Remove the 2D panel code in favour of Canvas]] (this requires completing some work to load 2D panel elements as Canvas, from XML) <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref> (as of 06/2020,  Gaétan Allaert  is still working on the replacement of the 2D panel by canvas <ref>https://sourceforge.net/p/flightgear/mailman/message/37042351/</ref>) {{Progressbar|80}}<ref>https://sourceforge.net/u/gallaert/flightgear/ci/789f5bdbce10637222ffa25206938947fec4bc64/</ref>
* possibly review state of optional [[CompositeViewer Support|CompositeViewer]] integration ? <ref>https://sourceforge.net/p/flightgear/mailman/message/37075130/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37075182/</ref>


=== Canvas ===
=== Canvas ===
{{See also|Unifying the 2D rendering backend via canvas}}
{{See also|Unifying the 2D rendering backend via canvas}}
* [[Canvas_News#2D_Panels|Remove the 2D panel code in favour of Canvas]] (this requires completing some work to load 2D panel elements as Canvas, from XML) <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref> (as of 06/2020, Gaétan Allaert  is still working on the replacement of the 2D panel by canvas <ref>https://sourceforge.net/p/flightgear/mailman/message/37042351/</ref>) {{Progressbar|80}}<ref>https://sourceforge.net/u/gallaert/flightgear/ci/789f5bdbce10637222ffa25206938947fec4bc64/</ref>
* Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable.(Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not)<ref>https://sourceforge.net/p/flightgear/mailman/message/29608899/</ref>
* Remove the C++ HUD in favour of Canvas-based version: this requires some kind of migration script or framework, so we have at least the default UFO HUD available <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref>
* Remove the C++ HUD in favour of Canvas-based version: this requires some kind of migration script or framework, so we have at least the default UFO HUD available <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref>
* Review Tim's original suggestion<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>: Another [Canvas] optimization is to use a pre-render camera that isn't in the scene graph to do the Canvas rendering. '''Otherwise the Canvas textures are rendered at least twice, in the near and far cameras'''. <ref>https://sourceforge.net/p/flightgear/mailman/message/36352621/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref> Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>, since within each camera pass (far camera, near camera), all the passes of a technique are run.<ref>https://sourceforge.net/p/flightgear/mailman/message/29563353/</ref> Also, Mathias stated once: that it would be good to be able to specify a completely different scenegraph in some subcameras, i.e. for having panel like instruments on an additional screen/display for example.<ref>https://sourceforge.net/p/flightgear/mailman/message/19718354/</ref>
* <del>Review Tim's original suggestion<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>: Another [Canvas] optimization is to use a pre-render camera that isn't in the scene graph to do the Canvas rendering. '''Otherwise the Canvas textures are rendered at least twice, in the near and far cameras'''. <ref>https://sourceforge.net/p/flightgear/mailman/message/36352621/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref> Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>, since within each camera pass (far camera, near camera), all the passes of a technique are run.<ref>https://sourceforge.net/p/flightgear/mailman/message/29563353/</ref> Also, Mathias stated once: that it would be good to be able to specify a completely different scenegraph in some subcameras, i.e. for having panel like instruments on an additional screen/display for example.<ref>https://sourceforge.net/p/flightgear/mailman/message/19718354/</ref></del>
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/FGCanvasSystemAdapter.cxx#l70
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/FGCanvasSystemAdapter.cxx#l70
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer_compositor.cxx#l927 (compositor renderer)
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer_compositor.cxx#l927 (compositor renderer)
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer_legacy.cxx#l1842 (legacy renderer)
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer_legacy.cxx#l1842 (legacy renderer)
* As per James' comments: Investigate adapting the [[Canvas Popout Windows|WindowBuilder to allow OSG windows to be created dynamically]] for features like Stuart's [[FG1000]] to be shown in a separate window (canvas placement) <ref>https://sourceforge.net/p/flightgear/mailman/message/37058207/</ref>  
* <del>As per James' comments: Investigate adapting the [[Canvas Popout Windows|WindowBuilder to allow OSG windows to be created dynamically]] for features like Stuart's [[FG1000]] to be shown in a separate window (canvas placement)</del> <ref>https://sourceforge.net/p/flightgear/mailman/message/37058207/</ref> (this is basically now possible thanks to Jules' CompositeViewer work)
* Review/integrate experimental C++ patches for new Canvas elements floating around on the forum, namely:
* Review/integrate experimental C++ patches for new Canvas elements floating around on the forum, namely:
** [[Canvas View Camera Element#Proof of Concept|view manager support]]
** [[Canvas View Camera Element#Proof of Concept|view manager support]]
Line 111: Line 82:
* Clean up the GPS code with respect to FG_210_COMPAT :
* Clean up the GPS code with respect to FG_210_COMPAT :


== property tree clean-up ==
== Property tree clean-up ==
remove /yasim/* "new" path is /fdm/yasim (since version 201x.?)
remove /yasim/* "new" path is /fdm/yasim (since version 201x.?)


Line 118: Line 89:


[[Category:Core development]]
[[Category:Core development]]
[[Category:Release plans]]

Latest revision as of 19:18, 29 December 2022

Changes that are already on next

Code clean-ups and changes

Merge-arrow.gif
It has been suggested that this article or section be merged into 2022.X Release Plan.

Collecting what's going to change: this will also be used to work out what manual or automatic migrations are required to keep aircraft working. It's expected that for the first few months of 'next', there will be higher than usual breakage, i.e regular might not be possible.

As a general guideline, the minimum system to develop / build the code on will be Ubuntu 18.04 LTS (Bionic) : the versions below correspond to what is available in a stock Bionic install.

  1. Make C++14 (possibly C++17 to facilitate VSG migration? [1] [2]) the minimum required version (will make it easier to continue replacing Boost items with std:: ones) [3] [4]
  2. Make CMake 3.6 the minimum required version: this will allow simplifying a bunch of compatibility logic in the build files [5] 70}% completed [6]
    1. Blocked by: OSGText Issues [7]
  3.  Use CMake OBJECT_LIBRARY to improve how we collect sources together when building each sub-dir 10}% completed [8]
  4. Make Qt 5.9 the minimum for the launcher Done Done [9]
  5. Drop 32-bit windows support [10]
  6. Drop the pre-2017.x MultiPlayer message format - this will fix warnings from some aircraft about MP packet overflows [11]
  7. Drop the KLN-89 code, since it's unused and not maintained for a long time: Canvas and the regular GPS code can easily implement a working KLN-89 or similar equipment now [12]
  8. Switch to Compositor mode as the only rendering option 90}% completed [13][14][15][16]
  9. Drop Rembrandt support from C++ (really part of the above) [17]
  10. Drop the C++ NavDisplay: the Canvas version replaces it [18]

Carriers and AI

Richard has been working on carriers since April 2020; originally the intention was to release as part of the 2020.2 LTS however the changes have grown into a set of new features rather than bugfixes and are therefore more suited to a longer development and review process.[19]

  • Done Done Improved view support - so that the nearest tower will include carriers
  • Done Done Changes to core code to support moving towers.
  • 80}% completed Multiple (tower) views - permit selection of LSO, PLAT and Tower as part of the "Tower view"; selection mechanism TDB. Consider revisions to the existing view system to better support this.
  • Done Done Extend XML to include definitions for FLOLS touchdown position, LSO view position, Tower View position, deck angle.
  • 80}% completed Improve 3d models for IFLOLS to ensure that a ball call can be made.
  • 80}% completed Improve logic for IFLOLS lights; not quite an LSO simulation more of an approximation of the definitive cases (e.g. waveoff)
  • Pending Pending Animate the lineup lights on the stern (of Nimitz class).
  • 100}% completed Improved support for Precision Approach Landing System (PALS) (AN/SPN-46); to support lineup deviation as well as glideslope (ball) deviation.
  • 70}% completed Change approach deviations to use new aircraft reference point rather than eyepoint; it is probably more correct to use the eyepoint when in the cockpit view - but for external views this can be slightly inaccurate when outside the aircraft to completely wrong when in tower/LSO view. The reference point is taken as the aircraft position with an optional model defined x,y,z offset. This allows ball tuning on a per aircraft basis.
  • Pending Pending Improved support for AI logic to permit XML definition of e.g. LSO logic. Possibly a version of the autopilot / state machine that can be included as "logic blocks"
  • Pending Pending Review 3d model usage for all Nimitz class and either add LOD selection (low, medium, high)
  • Pending Pending Review and include Marsdolphin contributions for MP Carrier (i.e. MP trumman)
  • 20}% completed Possible extra visual aids for Case 1 and Case 2 recovery training (e.g. a set of markers to fly through)
  • Pending Pending Better integration of carriers with JSBSim to permit catapult hookup
  • Pending Pending Simulate carrier operations Flight Deck Personnel, e.g. yellow shirts.
  • Pending Pending Animation of arrestor wires
  • Pending Pending Add some sort of trap grading (approach/touchdown plot)

see https://www.cnatra.navy.mil/local/docs/pat-pubs/P-816.pdf for T-45 carrier operations

Possible additional items

1rightarrow.png See 2022.X Release Plan for the main article about this subject.

2D Panels

Caution  See James' comments about pixel-level compatibility at Shiva Alternatives#Testing

1rightarrow.png See 2D Panels for the main article about this subject.

The idea is to remove all 'raw' OpenGL or OpenSceneGraph code from the panel code, it should be 100% done with Canvas elements. Eg use the Canvas Transform to compute the matrices[20]

Canvas

fgdata clean-ups

/Nasal

2do: list outdated / deprecated functions for removal (I remember one comment saying: remove after FG 3.0 or something)

  • Clean up the GPS code with respect to FG_210_COMPAT :

Property tree clean-up

remove /yasim/* "new" path is /fdm/yasim (since version 201x.?)

References

References
  1. https://sourceforge.net/p/flightgear/mailman/message/37041706/
  2. https://sourceforge.net/p/flightgear/mailman/message/37042499/
  3. https://sourceforge.net/p/flightgear/mailman/message/36988831/
  4. https://sourceforge.net/p/flightgear/mailman/message/36984349/
  5. https://sourceforge.net/p/flightgear/mailman/message/37020794/
  6. https://sourceforge.net/p/flightgear/mailman/message/37091728/
  7. https://sourceforge.net/p/flightgear/mailman/message/37284981/
  8. https://sourceforge.net/p/flightgear/mailman/message/37042800/
  9. https://sourceforge.net/p/flightgear/mailman/message/37041064/
  10. https://sourceforge.net/p/flightgear/mailman/message/34899704/
  11. https://sourceforge.net/p/flightgear/mailman/message/36300829/
  12. https://sourceforge.net/p/flightgear/mailman/message/36327950/
  13. https://sourceforge.net/p/flightgear/mailman/message/36606242/
  14. https://sourceforge.net/p/flightgear/mailman/message/37039397/
  15. https://sourceforge.net/p/flightgear/mailman/message/37040359/
  16. https://sourceforge.net/p/flightgear/mailman/message/37148477/
  17. https://sourceforge.net/p/flightgear/mailman/message/36340736/
  18. https://sourceforge.net/p/flightgear/mailman/message/36975265/
  19. https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/aaa9a3ee-ca18-e3af-1538-0cd59ae7a752%40zaretto.com/#msg37038519
  20. https://sourceforge.net/p/flightgear/flightgear/merge-requests/217/#a8d5
  21. https://sourceforge.net/p/flightgear/mailman/message/36973988/
  22. https://sourceforge.net/p/flightgear/mailman/message/37042351/
  23. https://sourceforge.net/u/gallaert/flightgear/ci/789f5bdbce10637222ffa25206938947fec4bc64/
  24. https://sourceforge.net/p/flightgear/mailman/message/29608899/
  25. https://sourceforge.net/p/flightgear/mailman/message/36973988/
  26. https://sourceforge.net/p/flightgear/mailman/message/36659646/
  27. https://sourceforge.net/p/flightgear/mailman/message/36352621/
  28. https://sourceforge.net/p/flightgear/mailman/message/37042457/
  29. https://sourceforge.net/p/flightgear/mailman/message/36355833/
  30. https://sourceforge.net/p/flightgear/mailman/message/29563353/
  31. https://sourceforge.net/p/flightgear/mailman/message/19718354/
  32. https://sourceforge.net/p/flightgear/mailman/message/37058207/