If /sim/highlighting/enabled is true, we highlight animated objects under the
pointer, and also highlight other objects that are animated by the same or
related properties.
The intent here is to be able to give a visual indication of what cockpit
controls do or what cockpit controls affect particular aircraft objects - for
example moving the pointer over the flaps will highlight the flaps and also
highlight any controls or rotary indicators in the cockpit that are associated
with the flaps.
To make this work, we have to discover associations between properties. This
is currently done for YASim (e.g. associations between /controls/flight/flaps
and /surface-positions/flap-pos-norm) and autopilot filters (e.g. with
the 777, digital filters associate /controls/flight/rudder-nul with
/fcs/fbw/yaw/rudder-ratio-out). We don't currently gather associations between
properties in JSBSim
We also detect associations between dialogs, menus and keypresses and
properties, which is used to populate /sim/highlighting/current with
information about dialogs, menus and keypresses that are associated with the
currently highlighted nodes' properties.
Details:
src/GUI/Highlight.cxx
src/GUI/Highlight.hxx
src/GUI/CMakeLists.txt
src/Main/fg_init.cxx
New subsystem called 'highlight', with support for registering and
recovering links between menus, dialogs, keypresses and OSG node
animations.
Provides a function Highlight::highlight_nodes() which highlights
related nodes using internal NodeHighlighting class, and populates
/sim/highlighting/current with information about related dialogs, menus and
keypresses.
The NodeHighlighting class works by making nodes use an alternative
StateSet which shows up as a distinct material on screen. We remember each
highlighted node's original StateSet so that we can un-highlight. We update
the material parameters using a listener for /sim/highlighting/material,
which allows some control over the appearence of highlighted nodes.
src/FDM/flight.cxx
src/FDM/flight.hxx
Added virtual method FGInterface::property_associations() which returns
property associations from the FDM. Default implementation returns empty
set. Implemented in YASim, but not (yet) in JSBSim. Uses a simple function
pointer at the moment to avoid requring FDMs to use recent C++ features.
src/FDM/YASim/FGFDM.cpp
src/FDM/YASim/FGFDM.hpp
src/FDM/YASim/YASim.cxx
src/FDM/YASim/YASim.hxx
Gathers information about property associations on startup such as
/controls/flight/flaps => /surface-positions/flap-pos-norm, then
YASim::property_associations() overrides default implementation to return
these associations.
src/Autopilot/analogcomponent.cxx
src/Autopilot/analogcomponent.hxx
src/Autopilot/digitalfilter.cxx
src/Autopilot/inputvalue.cxx
src/Autopilot/inputvalue.hxx
Filters now gather information about their input/output properties and
register with Highlight::add_property_property(). For example this makes
highlighting work on the 777, where pilot controls affect control surfaces
only via filters.
src/GUI/new_gui.cxx
Scan menus, keypresses and dialogs and register associations with
Highlight::add_*().
src/GUI/property_list.cxx
src/GUI/property_list.hxx
src/GUI/FGPUIDialog.cxx
Added <readonly> flag to property-list. If set, we don't show .. or . items
and don't respond to mouse/keyboard.
Used by fgdata's new Highlighting dialogue.
src/Model/acmodel.cxx
src/Model/acmodel.hxx
Visit the user aircraft's scene graph when it is loaded, gathering
information about osg::Node's that are animated by properties, and register
these associations with Highlight::add_property_node().
src/Viewer/renderer.cxx
When scanning for pick highlights, use Highlight::highlight_nodes() to
highlight animated objects under the pointer and related objects.
Patch by Michael Danilov: allow an aircraft set XML to define the requied
directory name, and if one is provided, validate the actual name against
this. This catches common issues where a manually downloaded aircraft
has the wrong name and some assets will therefore not load.
SF-Ticket-ID: https://sourceforge.net/p/flightgear/codetickets/2647/
Implement support for virtual reality headsets via version 0.3 of the
osgXR[1] library I've been working on which uses OpenXR.
Add a new VRManager class based on osgXR::Manager to implement its
callbacks. When osgXR needs a new view created, we build a new camera in
the default camera group, and notify osgXR of each new "scene" typed
render pass. It also hooks into the CameraInfo's new compositor reload
callback to ensure osgXR is updated when the compositors are reloaded.
VR settings are controlled by properties, and new --enable-vr /
--disable-vr options are implemented to enable/disable VR at start.
This is enough to get basic VR for looking around the cockpit, but more
work will be required to support a desktop mirror of VR view, VR splash
screen, VR GUI, controller interaction, and correct positional sound.
[1] https://github.com/amalon/osgXR
Allow supression of bad_alloc reports based on a RAII helper. This
will allow reducing backend reports for code-paths where we know bad_alloc
is handled.
When we don't have an explicit attribute, check if the file path mentions the current
aircraft directory. This should fix attribution for some GUI dialogs and property rules.
Also fixed uneven MP carrier motion.
If /ai/models/carrier[]/ai-latch is true (e.g. by MPCarrier.nas), we
set /position/* and /orientation/* in C++ every frame instead of in
nasal. For external multiplayer carriers the values are copied from
/ai/models/multiplayer[]/*, so the AI carrier follows the corresponding MP
carrier exactly. For this to be useful, multiplayer motion needs be smooth,
e.g. with /sim/time/simple-time/enabled=true.
scripts/python/recordreplay.py
Added --carrier test - checks that multiplayer carrier moves with even
speed.
src/AIModel/AIBase.hxx
Added speed_fps, to be kept up to date and tied to velocities/uBody-fps
when we are a carrier. Previously this was set from Nasal which doesn't
do what is required when all updates happen in C++.
src/AIModel/AICarrier.cxx
src/AIModel/AICarrier.hxx
If is-user-craft is true, we directly update /position/* every frame.
If ai-latch is true, we don't call TurnToLaunch(), TurnToRecover(),
ReturnToBox(), TurnToBase() etc, because our position and orientation is
determined only by multiplayer packets.
src/AIModel/AIMultiplayer.cxx
src/AIModel/AIMultiplayer.hxx
If an mp craft is a carrier, MP packets define velocities/speed-kts but
set ecLinearVel to all-zeros. So we now copy across to ensure that the
extrapolation algorithm has a velocity to work with. Previously the zero
velocity caused very uneven motion.
If ai-latch is true we set AI craft's position+velocities directly from
the equivalent (extrapolated or interpolated) MP position, every frame. We
also set AI craft's orientation. And we copy MP's uBody-fps to AI's
velocities/speed-kts which ensures that friction works between carrier deck
and aircraft undercarriage.
Added logging of raw speeds implied by multiplayer packets, activated by
/sim/log-multiplayer-callsign; used by scripts/python/recordreplay.py's
--carrier test.
src/AIModel/AIShip.cxx
Tie velocities/uBody-fps to new speed_fps member and set speed_fps in
update() along with members that are tied to properties.
Replaced code that calculated new position using heading and speed:
Previously the new position after dt was calculated using
ft_per_deg_lat, ft_per_deg_lon, speed_north_deg_sec and
speed_east_deg_sec. But this was moving slightly faster than the
specified speed.
This was leading to incremental errors when a different Flightgear
instance extrapolated the multiplayer position from the information in
multiplayer packets, because the specified velocity was too small, so
we jumped forwards when extrapolation moved to a new packet.
The fix is to use a Quaternion-based calculation to calculate movement
in the direction specified by (heading, pitch, roll), as done by other
code such as the view code.
src/Main/fg_init.cxx
Moved FGAIManager to just before FGMultiplayMgr so we send latest info in
mp packets.
src/MultiPlayer/multiplaymgr.cxx
Fixed minimum transmit rate calculation - if transmit rate is less than 1,
default to 1, not 10.
src/Network/props.cxx
Use more precision when sending double-precision values e.g. to telnet
client. Otherwise for example UTC times don't have sufficient resolution.
src/Viewer/viewmgr.cxx
Generate internal logs of multiplayer position and speed (after
interpolation/extrapolation) if /sim/log-multiplayer-callsign is set. Used
by scripts/python/recordreplay.py's --carrier test.
Previously we always used the default download dir, and ignored any
user override of this. Use the active download dir as the base for
the cache dir.
Also write the cache dir to the property tree, and wipe it on a
clean uninstall.
When we fail to find the request aircraft, ensure we log the paths
to Sentry. If the user didn’t supply any aircraft paths at all, or
was using a hangar aircraft, adjust the error dialog text, to make
it a bit clearer what is going wrong.
out command, in option curently overwrite the rate given by the out option
eg: --multiplay=out,20,localhost,5000 --multiplay=in,,,5003 end with a tx
rate of "0" and this end with the default value 10 later
Disable error-reports in ‘developer-mode’, and only consider aircraft
errors critical if they happen before postinit().
Add logic to show the correct report when a popup is clicked.
Assess how critical the error is, and based on this, show a popup
instead of the dialog in some cases. Add commands to allow delayed
display of the main dialog, and stepping through multiple error
reports in the dialog.
Also add a new error category for shader errors, since these are
always emitted from the render thread and we can’t easily attribute
them to an aircraft, scenery or core feature.
Carrier improvements
- Calculate lineup deviation (degrees left/right)
- Position for touchdown added (for more accurate lineup and glideslope deviation checks)
- LSO position and Tower position added (for views)
- Better logic for controlling the FLOLS
- Added ability to start on a specific course (works better
with the launcher if the carrier starts on a recovery course
when positioning in air for recovery (approach)
- Support for normal, tower, LSO views (via controls/view-index)
- Aircraft can define offset for FLOLS in sim/model/reference-offset-{xyz}
Added the ability to find the nearest carrier to use as a tower
Rework of the tower position so that it updates frequently to support moving towers.
TODO: Need to review how to better implement/integrate 'sub-views' i.e. ai/models/carrier[]/controls/view-index which is actually a sub index for the tower view.
