Flightgear 2020.3 releases use a different encoding for multiplayer information
in Normal recordings (these are saved from in-memory recording data), which
we failed to parse. This commit restores handling of this encoding, enabling
replay of older recordings.
Also when replaying in-memory recording, don't do background in-memory record
of multiplayer information, because this gradually prunes the information that
is being replayed.
from Chris RINGEVAL
https://sourceforge.net/p/flightgear/flightgear/merge-requests/273/
Squashed commit of the following:
commit ea6e808e418533db1a41671c67a7873ddbfcc858
Author: Gonzalo Pesquero <gpesquero@yahoo.es>
Date: Sun Nov 21 17:44:44 2021 +0100
Add translations on splash screen
commit 3c47d771877743692f5d0d63e980d6694a549405
Author: Chris Ringeval <eatdirt@protonmail.com>
Date: Sat Nov 27 16:37:31 2021 +0100
Moon direction vector in the eye frame available to shaders
commit 70728f7ea29dad75c34cad69745021ee927bea31
Author: Chris Ringeval <eatdirt@protonmail.com>
Date: Sun Nov 21 22:18:38 2021 +0100
Add altitude to scolor object as needed by Milky Way texturing
Update 3rdparty/osgXR to version 0.3.8, which gets us non-linear sRGB
swapchain formats by default. This avoids double gamma correction with
Monado when FlightGear renders non-linear sRGB data into linear RGB
swapchain images.
FIx some bugs in computing turnExitPos for fly-over waypoints,
and computing leg course when preceeeding leg is a runway.
In both cass we had an incorrect turnExitPos, so points along
the leg were incorreclty positioned.
Extend the test cases to cover this further.
Make the max-flyBy angle configuable, since for exmaple AIrbus uses 90
degrees. Expose this via a new gps/config property, and extend the tests
to verify that angles greater than the fly-by angle behav as fly-over
waypoints.
Extend the RoutePath code to share this configuration, so that route
visualisations match the configured angle.
SF-ID: https://sourceforge.net/p/flightgear/codetickets/2694/
When we don't build any wapy controller, also bail out, rather than
crashing. Jonathan could trigger this with an empty route on the A320,
although no stand-alone test-case so far.
SF-ID: https://sourceforge.net/p/flightgear/codetickets/2695/
Previosu parse had embedded whitespace which is annoying
to parse in other places, switch to using backslash to
seperate terms, similar to how navdaid offsets are defined.
Add a bool flag isRoute to flight-plan, and use it to model
routes (which contain VIAs) from plans/legs, which do not.
Default isRoute to false, so most users only see expanded
Vias, and hence something that can be flown directly.
Allow making the AP source indirect (via a string property),
so that the actual source property can be configured or
adjusted from a -set.xml, or at runtime.
virtual dtor
initialize members before the ctor
config.h is not used
YawTo() is unused
assertSpeed() is unused
initializeFlightPlan() is unused
getTimeString() is unused
get/set is old school
default dtor
YawTo() seems to be unused
ensure all members are initialized
_path and _elevation_m were hiding parent members
config.h is not used
TODO: string compare not via strcmp()
TODO: remove magic number
Import osgXR from https://github.com/amalon/osgXR master branch into
3rdparty, specifically commit b7e222775553b529018ac4b847353327c24ae5d4,
which is 0.3.7 with tweaks for building as a subproject in a
subdirectory.
This will allow VR support to be more conveniently built if not already
installed, without having to fetch yet another dependency.
Recent CMake versions automatically add the include paths when
flightgear is linked against the osgXR::osgXR target, and code in
SetupFGFSLibraries.cmake handles older CMake versions. Therefore drop
the osgXR special handling in SetupFGFSIncludes.cmake and handle old
versions in SetupFGFSLibraries.cmake as done for the other libraries.
