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.
Update 3rdparty/osgXR to version 0.3.9, which gets us better handling of
quirks and window closure, and the ability to create quad composition
layers which will be particularly useful for the loading screen when
flightgear isn't so good at timely frame updates.
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.
Avoid a console warning from OpenAL-soft about leaked buffers on
shutdown, by ensuring IAXClient backend does matching cleanup
for the buffers it allocates.
* 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'.
