refs: https://sourceforge.net/p/flightgear/codetickets/2674/
Because disabling threaded GC wouldn't result in exactly the same allocation and GC due to changes I made to the GC as part of the threaded GC work the only safe thing to do is to remove it all.
Once we have figured out if it is the threaded GC causing the problem or not then we will at least know what needs fixing.
(Disabled by a CMake option)
This builds equivalent C++ objects to what the PUI dialogs build, with
properties exposed to Nasal. Peer objects are created by Nasal callbacks,
which can implement the various dialog functions needed to keep
compatibility, especially the ‘update’ and ‘apply’ hooks.
This is by Lars Toenning <dev@ltoenning.de>, Roman Ludwicki <romek21@op.pl> and
SDeAstis <salvatore.deastis@gmail.com>, in 2021 Hackathon.
Also cope with removal of SGPropertyNode::getName() - use getNameString()
instead.
Make --view-offset set /sim/view[0]/config/heading-offset-deg instead of
/sim/current-view/heading-offset-deg. Setting the latter has no effect
because of what flightgear::View::createFromProperties() does when it
initializes flightgear::View::View. This was discussed at [1].
[1] https://sourceforge.net/p/flightgear/mailman/message/37406317/
This will fix other uses of the APi blocking because the backend
failed to start. Enable debug logging in non-release builds so
it's obvious when the deploymenty is not configured right.
If specified we start video encoding when replay starts, and stop video
encoding when we reach recording end.
This is supported with --load-tape on the command line and from the 'Load tape'
dialogue.
src/Aircraft/continuous.cxx
src/Aircraft/continuous.hxx
If stopping replay with auto create video, then stop video encoding and
restore original /sim/time/fixed-dt if we changed it.
src/Aircraft/replay-internal.cxx
src/Aircraft/replay-internal.hxx
When starting replay, call view_mgr->video_start() and set
/sim/time/fixed-dt if specified.
src/Aircraft/replay.cxx
src/Aircraft/replay.hxx
loadTape(): added bool create_video and double fixed_dt args.
src/Main/options.cxx
Added new command-line options --load-tape-create-video and
--load-tape-fixed-dt=<double> to allow auto create video and fixed-dt when
replaying.
The main FGReplay subsystem class now contains just the public API for
record/replay, plus a pointer to instance of new ReplayInternal implementation
class. Also moved some Continuous-specific code into new source file.
src/Aircraft/CMakeLists.txt
Updated for new files.
src/Aircraft/continuous.cxx
src/Aircraft/continuous.hxx
New, code specific to Continuous record/replay.
src/Aircraft/flightrecorder.hxx
Minor changes.
src/Aircraft/replay-internal.cxx
src/Aircraft/replay-internal.hxx
New, contains implementation of record/replay.
src/Aircraft/replay.cxx
src/Aircraft/replay.hxx
Modified to be just concerned with public record/replay API. The
implementation now defers to the ReplayInternal instance. Added support for
auto create-video when loading Continuous recording.
src/Main/fg_init.cxx
resetStatisticsProperties() is now in FGReplay, not FGReplayData - the
latter is not in the replay.hxx header any more.
Uses simgear::VideoEncoder().
Added video-start and video-stop commands. We allow specification of container,
codec, quality, speed and bitrate.
src/Main/fg_commands.cxx
Added video-start and video-stop commands.
src/Viewer/viewmgr.cxx
src/Viewer/viewmgr.hxx
Added video_start() and video_stop().
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.
