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.
Replace the ENABLE_OSGXR option with a slightly more user friendly
ENABLE_VR which is only enabled by default on Linux. If VR is enabled we
set ENABLE_OSGXR to enable the code, but only if a compatible osgXR
version is available. In any case a status message is output to specify
whether VR support is enabled or not.
This should allow VR support to be built even after osgXR couldn't be
found the first time cmake was run. The finding is now quiet so as not
to repeatedly spam the log.
Handle removal of SGPropertyNode::getValue<const char *>() in
VRManager::Listener<const char *>::valueChanged() by switching the
string listeners and VRManager setter handlers to std::string.
This fixes the following link error when VR is enabled:
ld: VRManager.cxx.o: in function `flightgear::VRManager::Listener<char const*>::valueChanged(SGPropertyNode*)':
src/Viewer/VRManager.hxx:147: undefined reference to `char const* SGPropertyNode::getValue<char const*>(std::enable_if<simgear::props::PropertyTraits<char const*>::Internal, void>::type*) const'
If continuous compression is enabled, we used to compress recovery recording's
data, without setting continuous-compression to true in recording header, so it
would fail to load.
The fix is to compress recording data only if we are making a continuous
recording.
Two affected places:
- the built-in launcher (command line options link);
- package/org.flightgear.FlightGear.metainfo.in.
The previous link points to an old version of the manual.
