- Summary.qml - new row with Flight Plan info
- LauncherController.hxx, Launcher.qml - signals to show flightPlan &
exposing flight plan object
- FlightPlan.qml - add red color to information about airport mismatch
- FlightPlanController.cxx, FlightPlanController.hxx - description
handling, support to loading flight-plan from command line argument
'flight-plan', saving last used dir when loading/saving flightplans
Fixes https://sourceforge.net/p/flightgear/codetickets/2521/
For submodels with rotation offsets, the rotation was applied to the
translation offset.
This is incorrect: translation offsets should be in the aircraft local
frame, and thus are not affected by submodel rotation offsets.
This scales all LOD ranges and was added in an attempt
to control WS3.0 LOD ranges. However it badly impacts
WS2.0 draw distances, and is not the right solution
for WS3.0. So removing.
Elevation constraints are now added by the ReaderWriterSTG
for all OBJECT entries, so aren't explicitly required for
the .icao loader. This also allows us to clean up the BVH
generation, as the constraint is added after the model loading
is completed and the BVH policy applied.
Previously WS3.0 airports could be placed via .stg
file.
Now they are OBJECT entries rather than OBJECT_STATIC
and the placement information is taken from the apt.dat file.
Also added as elevation constraint for WS3.0 terrain.
Setting useDefault to true is equivalent to using unitialized variables we are getting whatever is currently in the memory whether it is relevant or not.
avoids an exception throw when the controller fails to init, which
avoids us breaking the stack when called via setMode, etc. Showed
up as error reports on Sentry.
Make this exception inherit std::runtime_exception, so that it’s
caught by the ‘normal’ exception cases in FG boostrap.cxx
This is the only exception I can find in the codebase, which does not
inherit from either std::exception or std::string, so this is to fix
‘unknown exception’ errors reported in the wild.
Sentry-Id: FLIGHTGEAR-1C
It seems that some aircraft sometimes incorrectly pass view indices rather
than numbers resulting in out-of-range access to FGViewMgr::views[]; See
flightgear-devel thread with subject "View crash (after loading errors)".
With this commit, if we are given an incorrect view number, we output a
diagnostic with SG_ALERT, assert fail, and cope with the problem. Arguably we
could do something more serious such as opening a popup or throw an exception.
