A few versions of the Windows Intel drivers seem to crash while
performing the OpenGL check; re-order the code to try and prevent
this.
Sentry-Id: FLIGHTGEAR-K7R
Don’t fail to select the language, when the UI language includes
a ‘script’ value, as happens for Chinese on macOS.
Thanks to Sidi Liang for reporting.
QML implementation of getting started tips, with a nice styled
background box. Tips are defined+positioned inline, and displayed
when their enclosing scope is active.
Translocation forces us to rebuild the nav-cache each launch, and might
mess up some other details, so let’s warn the user they should copy
the app to Applications or similar.
If the user double-clicks, and their system is slow, the action can
fire twice, which then breaks because we add options twice.
Sentry-Id: FLIGHTGEAR-HKV
- 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
Overview:
Previously Flightgear always used a single osgViewer::Viewer(), which
inherits from both osgViewer::ViewerBase and osgViewer::View, giving a
single view window.
If CompositeViewer is enabled, we instead use a osgViewer::CompositeViewer
which contains a list of osgViewer::View's. Each of these View's can have
its own eye position, so we can have multiple different views of the same
scene.
Enable at runtime with: --composite-viewer=1
Changes to allow use of osgViewer::CompositeViewer:
Previously FGRenderer had this method:
osgViewer::Viewer* getViewer();
This has been replaced by these two new methods:
osgViewer::ViewerBase* getViewerBase();
osgViewer::View* getView();
If CompositeViewer is not enabled (the default), the actual runtime state
is unchanged, and getViewerBase() and getView() both return a pointer to
the singleton osgViewer::Viewer() object.
If CompositeViewer is enabled, getViewerBase() returns a pointer to a
singleton osgViewer::CompositeViewer object, and getView() returns a
pointer to the first osgViewer::View in the osgViewer::CompositeViewer's
list.
The other significant change to FGRenderer() is the new method:
osg::FrameStamp* getFrameStamp()
If CompositeViewer is not enabled, this simply returns
getView()->getFrameStamp(). If CompositeViewer is enabled it returns
getViewerBase()->getFrameStamp(). It is important that code that previously
called getView()->getFrameStamp() is changed to use the new method, because
when CompositeViewer is enabled individual osgViewer::View's appear to
return an osg::FrameStamp with zero frame number).
All code that uses FGRenderer has been patched up to use the new methods so
that things work as before regardless of whether CompositeViewer is enabled
or not.
We make FGRenderer::update() call SviewUpdate() which updates any extra
views.
Extra view windows:
If CompositeViewer is enabled, one can create top-level extra view windows
by calling SviewCreate(). See src/Viewer/sview.hxx for details.
Each extra view window has its own simgear::compositor::Compositor
instance.
Currently SviewCreate() can create extra view windows that clone the
current view, or view from one point to another (e.g. from one multiplayer
aircraft to the user's aircradt) or keep two aircraft in view, one at a
fixed distance in the foreground.
SviewCreate() can be called from nasal via new nasal commands "view-clone",
"view-last-pair", "view-last-pair-double" and "view-push". Associated
changes to fgdata gives access to these via the View menu. The "view-push"
command tags the current view for later use by "view-last-pair" and
"view-last-pair-double".
Extra view windows created by SviewCreate() use a new view system called
Sview, which allows views to be constructed at runtime instead of being
hard-coded in *-set.xml files. This is work in progress and views aren't
all fully implemented. For example Pilot view gets things slightly wrong
with large roll values, Tower View AGL is not implemented, and we don't
implement damping. See top of src/Viewer/sview.cxx for an overview.
OpenSceneGraph-3.4 issues:
OSG-3.4's event handling seems to be incorrect with CompositeViewer -
events get sent for the wrong window which causes issues with resize and
closing. It doesn't seem to be possible to work around this, so closing
extra view windows can end up closing the main window for example.
OSG-3.6 seems to fix the problems.
We warn if CompositeViewer is enabled and OpenSceneGraph is 3.4.
Avoid passing missing add-ons to FlightGear. Since we only write a
cleaned list back to QSettings upon some user change, we can persist
bad paths.
Sentry-Id: FLIGHTGEAR-NG
- Removed the ENABLE_COMPOSITOR CMake flag.
- Removed /sim/version/compositor-support.
- Removed miscellaneous branching to check if the Compositor is enabled.
- Removed custom resource loader since Compositor Effects are now located in $FG_ROOT/Effects.
- Removed splash screen warning.
- Only use the Compositor versions of CameraGroup and FGRenderer.
- Fix redout/blackout not appearing under certain circumstances.
Don’t probe for, or pass, missing paths to FlightGear. Since we don’t
show such paths in the UI, they hang around forever, causing exceptions
Sentry-Id: FLIGHTGEAR-NG
If impatient users start multiple copies of FlightGear when a cache
rebuild is required, we can get into a mess. Use an additional
named mutex on Windows to avoid this situation, and block the secondary
copies until the primary instance has completed its cache rebuild.
Sentry-Id: FLIGHTGEAR-8D
Sentry-Id: FLIGHTGEAR-FY
Changing style will reload style from filesystem, so one can edit styles and
see results without restarting fg.
Note that this duplicates initial populating of /gui/styles/ from
defaults.xml's <sim><gui>...</gui></sim> section, so it's a bit of a hack.
Since our data encoding is incompatible between 2018 and 2020, use
different settings keys so running both versions in parallel is easier.
Without this, each version screws up the data for the other.
When local aircraft scanning is slow, we can end up clearing
the locale while a scan is in progress, which crashes. Ensure we
abandon any in-progress scan when closing the launcher.
Sentry-Id: FLIGHTGEAR-CH
Add pop-up notification when we migrate to a new version of a hangar.
Convert the ‘new version available’ message to use a pop-up
notification as well.
Avoid filling up the logs when the launcher parses broken aircraft XML;
wait until the user actually pick one to fly with, before reporting
XML errors.
This causes QApplication to become unhappy and crash, so use a
graceful exit via a new return code and FG_OPTIONS_EXIT instead.
Sentry-Id: FLIGHTGEAR-6B
Fix the include context when -set.xml are parsed by the launcher to
extract states and other data. Ensure aircraft paths are available
and handled consistently with normal -set.xml parsing. Without this,
many -set.xmls fail to parse.
Sentry-Id: FLIGHTGEAR-4H
Sentry-Id: FLIGHTGEAR-3B
Sentry-Id: FLIGHTGEAR-3R
Sentry-Id: FLIGHTGEAR-3Q
Sentry-Id: FLIGHTGEAR-3F
Sentry-Id: FLIGHTGEAR-2R
Sentry-Id: FLIGHTGEAR-65
Sentry-Id: FLIGHTGEAR-42
Adjust the wording and links for these pages, after a review session
with Stuart and others. Include a link to the manual and short-ref
from the local installation.
If a menu-bar item is missing a <name>, we can end up building a string
from nullptr, which is a SEGV.
Reported as Sentry issue FLIGHTGEAR-1D
Will back-port to LTS once verified.
Use the ‘file name copying’ version of log(), to avoid an ASan use-
after-free. Note this requires SG change
908496d43dd7c3a7ca1de42b0e0c21aa0498c7df
to work correctly.
When there are installed the same aircrafts from different sources
(fgdata + fgaddon + git) with identical descriptions, use the URI to
provide stable sorting.
