- Fix a little regression introduced in commit d2f4807fa2: changing
the standby frequency disabled the low-pass filter for the next call
to updateReceiver(); this must happen when the selected frequency is
changed but not when the standby frequency is changed. This is covered
by the recently-added unit test NavRadioTests::testVORSignalQuality.
- Optimization of the older code: no need to perform a navaid search()
when only the standby frequency is changed.
When the selected frequency is changed or when leaving GPS slave mode,
disable the low-pass filter applied to signal quality. Otherwise, the
following may happen for instance:
- the active frequency corresponds to a navaid whose signal is well
received;
- user makes it so that the Morse code for the navaid ID can be heard;
- user then changes the selected frequency to one that doesn't belong
to a navaid that is close enough to be usable;
- yet, as soon as the frequency is changed, the Morse code for the ID
of the newly selected navaid (if any), even if it is way too far for
its signal to be received, will be very clearly heard for about one
second---and likely truncated.
This is because before this commit, after the frequency change, the
low-pass filter applied to signal quality made the code behave as if the
signal, supposedly coming from the new navaid, were still strong---which
of course doesn't correspond to physical reality. This fixes the bug
reported at [1].
[1] https://forum.flightgear.org/viewtopic.php?f=25&t=40890#p405708
The splash window name was only being set for the default / legacy
camera setup, however if the camera group is set up explicitly in the
configuration XML the splash window wouldn't get set and the splash
would no longer get displayed.
This is fixed by selecting the first referenced window name from a
camera.
A better fix (more closely matching the prior behaviour) would be to
create a splash camera for each created window, however this is proving
difficult to test due to instability with multiple windows, so this fix
will suffice in the mean time.
Fixes: bb0d7fc0a7 ("src/Viewer: Move splash to cam group camera")
Reported-by: Durk Talsma <durktals@gmail.com>
When FG encounters an unknown property id in a MP packet, it discards
the remainder of the packet. This happens when adding new MP properties:
older clients will discard the property and anything that comes after.
This is normally not an issue because newer properties are placed at the
end of the packet.
However MP bool array properties (sim/generic/bool[*]) are transmitted
at the very end of a packet, meaning they get broken (for backward
compatibility) each time a property is added to the protocol.
Fix this by placing them earlier in the packet, with the same ordering
rules as other properties.
Commit 6aff646cf (Mach number added to mode-S XPDR properties, 2022-07-20)
added /instrumentation/transponder/mach-number as a new MP property.
It was inserted with other transponder properties, in the middle of
the list of MP properties. This breaks backward compatibility:
older FG client discard any property after this.
Move the new property to the end of the list, with the largest id.
VRManager::instance() was using a function scoped static osg::ref_ptr to
store the VRManager instance. However it needs to be used from
fgOSCloseWindow(), which is called from an atexit handler, and C++11
specifies that static object destruction and atexit handlers are reverse
sequenced, i.e. a static object initialised after an atexit call will be
destroyed before the atexit callback is called.
On Windows this can result in the osg::ref_ptr being destroyed (and
hence set to NULL) before fgOSCloseWindow() tries to call
destroyAndWait() on the instance.
Fix the resulting seg fault by moving the ref_ptr object to static file
scope so it is default constructed before the atexit call, and using
only a simple static bool to initialise it on first call to
VRManager::instance().
Reported-by: Alan Teeder <ajteeder@v-twin.org.uk>
fgInitAircraft() loads the aircraft -set.xml file, which calls
ResourceManager::findPath() for each 'include=...' directive. In order
to prevent such includes from triggering the new warning printed by
ResourceManager::findPath(), call fgInitAllowedPaths() after the
aircraft paths have been updated and before the -set.xml file is loaded.
Thanks to Alan Teeder for reporting the problem.
We can now probably remove the call to fgInitAllowedPaths() after
processOptions() in fgStartNewReset() (I believe the newly-added call
comes “soon enough”). Not doing so in this commit, though: let's fix
problems before optimizing.
This is an additional call to fgInitAllowedPaths(), earlier than the
normal one. It doesn't know the paths given to --allow-nasal-read, but
can already authorize read access for all of $FG_ROOT. This allows one
to add SGPath::validate() checks for paths given to
ResourceManager::findPath() with a non-null second argument (without
this change, the validation would fail for files included from
defaults.xml, read by fgSetDefaults() before the definitive
fgInitAllowedPaths() call has been performed).
The previous way only worked because after trying
SGPath(aContext, aResource), ResourceManager::findPath() tries all
providers, among which there is a BasePathProvider with $FG_ROOT as its
base... provider which doesn't use the 'aContext' argument at all.
Move the fgValidatePath() code and the two associated static variables
'read_allowed_paths' and 'write_allowed_paths' to SimGear.
fgValidatePath() is now known as SGPath::validate(). This requires
SimGear commit e002a481f481709263a.
osgXR 0.5.0 broke the API slightly, so update VRManager to use the new
enumeration names and update the required osgXR version for when using a
system version of osgXR.
Signed-off-by: James Hogan <james@albanarts.com>
- Use the complete path when performing the existence check (previously,
only the directory part was used: bug in commit
8853fded29).
- Use the resolved path (SGPath instance) obtained from
FGGlobals::resolve_maybe_aircraft_path() when constructing the
SGSoundSample instance; this makes it possible to use paths starting
with the '[addon=...]' special prefix (handled by the
AddonResourceProvider) with FGSoundManager::playAudioSampleCommand(),
and therefore with the 'play-audio-sample' FGCommand.
This requires SimGear commit 8febf6b9f58e9a1919ff3 ("SGSoundSample
constructor changes").
Before this commit, if several menu entries (possibly in different
menus) had the same label after translation and latin1-ization by
FGLocale::utf8toLatin1(), selecting one of them used to fire the
bindings associated to all such entries. This is because the bindings
used to be stored in an std::map whose keys were the
translated-and-latin1-ized labels.
This commit fixes the problem in the following way:
- the std::map (_bindings) is turned into an std::forward_list;
- each element of this std::forward_list references the bindings
assigned to a menu entry;
- in order to allow FGPUIMenuBar::fireItem() to find the bindings
assigned to the menu entry that triggered it,
FGPUIMenuBar::make_menu() calls puMenuBar::add_submenu() with an
additional argument ("user data") that attaches to the puObject for
each menu entry a pointer to the relevant element of _bindings.
Note: given how the menubar is created, an std::vector wouldn't be
appropriate for _bindings, because we need the pointers to its elements
to be stable when new elements are added to _bindings.
Reported by Wayne Bragg: https://sourceforge.net/p/flightgear/mailman/message/37682605/
FGButton::init() passes the module parameter (a non-const string
reference) straight through to FGCommonInput::read_bindings() as a const
reference.
Change the FGButton::init() signature so that module is const there too,
so that callers can pass it const string references returned by
accessors without having to make copies.
Use a quad composition layer object from osgXR 0.3.9 to make the splash
screen VR friendly. This allows the OpenXR compositor to redraw the quad
without any updates from flightgear, which is particularly helpful as
flightgear makes no attempt at a reasonable VR frame rate during
initialisation.
The quad is positioned 2 meters from the user, with an aspect ratio
matching the desktop window. The quad is blended using an
unpremultiplied alpha channel which is forced to a given alpha value by
osgXR.
The splash is effectively already rendered to an FBO as non-linear SRGB,
so this is made explicit in the internal texture format, with the
rendering to the desktop window using GL_FRAMEBUFFER_SRGB to ensure it
is properly re-encoded.
Move the splash screen from the scene root to a camera group camera,
just below the GUI camera. This has a number of advantages, mainly VR
related:
- The splash FBO will only be rendered once per frame. Currently it
appears to be rendered for both near & far cameras, and with
stereoscopic rendering for both left & right (even though it splats
right across both views at the moment), so 2 or 4 times.
- It makes it possible to render the splash fullscreen on the desktop
window, while presenting it on a 3d quad in VR (possibly via an
OpenXR composition layer so the runtime can keep rendering it
smoothly while FlightGear framerate drops during loading.
We were not appending the video container suffix if there was already a '.' in
the name.
Part of this fix is also to simplify the code - if name_in is not "" we don't
attempt to create softlink or append /sim/video/container.
* Parking with point beyond parking so aircraft don't stop early
* Better approach routes (wait pattern)
* Extracting vector math from AIFlightplan
* More use of SGPositioned in ATC
The launcher diagram and navaid-search now include TACANs, using
the current NavCache encoding (DME whose name ends in TACAN). A new
‘—tacan’ option works similar to —vor etc to set position (with
optional offset).
Tuning the Tacan instrument from the command line is not yet supported,
but could be easily added.
upper_case_property causes valueChanged to fire twice, since
SGPropertyNode string storage is now immutable (std::string). This
caused double-processing of for example adding a waypoint in
the route-manager dialog. Since the InputListener already upper-cases
the string, we can simply remove the upper-case property logic.
Detects /sim/affinity-control being set to 'clear' and 'revert' and modifies
all thread affinities accordingly. Only active on Linux.
Also modified meaning of /sim/thread-cpu-affinity. Instead of true/false, we now
expect these values:
'': do nothing.
'none': tell OSG to not set up any thread affinities (same as prev
'false').
'osg': allow OSG to set up thread affinities but attempt to cancel affinity
of main thread afterwards.
This is for investigating bug 2734.
If /sim/thread-cpu-affinity is true or unset on startup, we use default
behaviour where we tell OSG to set up thread-cpu affinities.
Setting /sim/thread-cpu-affinity to false on start up results in all/most
threads being free to run on any cpu core. For example in .fgfsrc or on
command, use:
--prop:bool:/sim/thread-cpu-affinity=false
- Output files are now written in the current directory instead of being written in the aircraft folder (issue GH#337)
- A new exception TrimFailureException is now thrown when trim fails. This eases the detection of the trim failure (previously the exception message needed to be checked).
- An exception is thrown when a latitude higher than 90 degrees is supplied to a <waypoint> control element (PR GH#536)
- Fix the sign of the initial NED climb rate (property ic/gamma-deg) (PR #545)
- JSBSim now checks malformed data in <table> elements. Anything different than numbers and spaces/tabs will be rejected.
- Usage of <location> and <orientation> in engines is now officially dropped (PR #559, #561 and #563). These elements were deprecated long ago in favor of the corresponding elements <location> and <orientation> in thrusters. Therefore the code removed is no-op.
- The computation of the initial rotation rates has been fixed (Issue GH#553). Previously, the rotation rates could be initialized with extremely high values when the vehicle was spawned over the Poles. And for a given set of initial conditions, the initial rotation rates could have different values depending on the initial latitude at which the vehicle was initialized. This now fixed.
- The precision with which values are transmitted thru a socket can now be set via the attribute precision such as <output precision="8"> (PR GH#579)
- Added 2 new methods to FGFDMExec: SetOutputPath and GetOutputPath to specify the path to which the output files will be written.
- All JSBSim exceptions now inherit from JSBSim::BaseException. There still exist std::* exceptions thrown by JSBSim. Cleanup is still in progress.
- JSBSim no longer calls exit() or abort(). Exceptions are thrown instead. This gives the calling application an opportunity to gracefully recover.
With this change, binding can be activated mostly-correctly from
the compatability layer. Closing still isn't working quite right, more
changes to follow.
We now allow an aircraft to specify both simple gear contact points (which will
be automatically used by old Flightgear builds), and also gear contact surfaces
(which will be automatically used by new Flightgear builds).
When parsing gear specifications, if specified we now use 'wheel-x', 'wheel-y'
and 'wheel-z' in preference to 'x', 'y' and 'z' for the wheel centre point.
These new 'wheel-*' values will be ignored by old Flightgear builds.
So to work with both old and new Flightgear builds, an aircraft should specify
old-style contact points with 'x', 'y' and 'z' as before, and new-style contact
surfaces with 'wheel-x', 'wheel-y' and 'wheel-z', and 'wheel-radius' and
'tyre-radius'.
Contact surface can now be a torus shaped tyre; we find the part of this torus
that is furthest towards the ground instead of using a fixed contact point.
Torus is specified by radius of wheel centred on original contact point,
orientation of a wheel axle, and radius of torus. If both wheel and tyre radius
are both zero the calculations reduce to a fixed contact point as before.
src/FDM/YASim/FGFDM.cpp
Read new optional <gear> attributes:
wheel-axle-x
wheel-axle-y
wheel-axle-z
wheel-radius
tyre-radius
src/FDM/YASim/Gear.cpp
Added new gearCompression() function that calculates gear compression for
wheel with torus tyre. If new radius values are both zero the calculation
behaves like a contact point as before; we also optimse this case to avoid
the extra matrix operations.
Moved old algorithm into gearCompressionOld() function to allow testing
that new algorithm gives same results when wheel and tyre have zero radius.
src/FDM/YASim/Gear.hpp
Added new members:
_wheelAxle,
_wheelRadius
_tyreRadius
Also declare gearCompression() function so it is available for unit
testing.
Added GearVector struct for caching unit vector and magnitude and use for
_compr and _wheelAxle, so we avoid having to calculate magnitude and unit
vector each iteration.
Clarified that _compressDist is vertical movement of gear. Not useful for
gear animations - one must use compression-norm.
src/FDM/YASim/Airplane.cpp
src/FDM/YASim/Model.cpp
src/FDM/YASim/YASim.cxx
Use g->getContact() instead of manually adding compression vector to
g->getPosition() (which no longer gives the correct contact point).
Ensure that lag/lag-mod-averaged is created and set to a valid value (0) prior to calling the base class init method as otherwise the MPList will have a nil reference.
This needs to be done prior to the base class ::init() because that method sets the model-added property which will trigger the lisetener.
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.
Using a <condition> images can be hidden now.
Also reworked the logic so that any hidden item will be hidden from creation and not rely on the update logic; as otherwise items can momentarily appear.
Refactor Splash to be data drive using definitions in <content> for the system splash and <model-content> for model related content.
All system splash is at fixed index and should not be changed except for good reason.
Allow other code to map property values to an naRef, without exposing
the generic property node on their API. This avoids creating a wrapper
props.Node frequently for simple value access.
(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.
