Basically, this is because fatalMessageBox() is only safe to call from
the GUI thread, however it seems fg_terminate() can be called from any
thread (according to C++11 semantics). Additionally, fatalMessageBox()
typically requires some work to happen in the GUI thread (event loop) in
order to display something, but we can't realistically expect this while
running a terminate handler just before the program dies.
See messages around
<https://sourceforge.net/p/flightgear/mailman/message/35775803/> for a
discussion of this subject.
+ Minor header cleanup (<locale.h> replaced with <clocale>, etc.)
/sim/multiplay/protocol-version is either 1 or 2 and controls how packets are sent. V2 packets will only have the (motioninfo) basic properties visible to older clients.
New string encoding that is efficient.
Support short int encoding (pack a property and value into 4 bytes).
Allow properties to be transmitted using a different encoding to the property type in the tree.
Support scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
V2 protocol uses transmit so most properties are either scaled floats or short ints.
Allow the client to request a larger visibility range by setting /sim/multiplay/visibility-range-nm. This will transmit in the repurposed header field ReplyAddress - which has been renamed to RequestedRangeNm. This will require support from fgms to actually do anything.
Extra debugging options. The most useful (for aircraft developers) is the loopback bit, as this allows model multiplay testing without running two instances.
Update property /sim/multiplay/last-xmit-packet-len with the size of the packet transmitted
Debug level bits in property /sim/multiplay/debug-level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
/sim/multiplay/protocol-version is either 1 or 2 and controls how packets are sent. V2 packets will only have the (motioninfo) basic properties visible to older clients.
New string encoding that is efficient.
Support short int encoding (pack a property and value into 4 bytes).
Allow properties to be transmitted using a different encoding to the property type in the tree.
Support scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
V2 protocol uses transmit so most properties are either scaled floats or short ints.
Allow the client to request a larger visibility range by setting /sim/multiplay/visibility-range-nm. This will transmit in the repurposed header field ReplyAddress - which has been renamed to RequestedRangeNm. This will require support from fgms to actually do anything.
Extra debugging options. The most useful (for aircraft developers) is the loopback bit, as this allows model multiplay testing without running two instances.
Update property /sim/multiplay/last-xmit-packet-len with the size of the packet transmitted
Debug level bits in property /sim/multiplay/debug-level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
Also build the test code first, so tests can reside in source tree as
well as the test tree.
Finally, build local Sqlite with -fpic to give consistent linkage when
using either built-in or system sqlite.
If GPerfTools and/or the SYSTEM_SQLITE options are enabled, the test
suite fails to build (GPerfTools is not linked explicitly in CMakeLists.txt,
but becomes required by SimGear, so the linker failes with an "undefined
reference" error; the SQLite library the test suite links against is always
hardcoded to the FG-provided one).
This patch adds the GPerfTools library to the target link libraries
(if the profiler is enabled) and links to the system SQLite library
whenever SYSTEM_SQLITE is enabled.
We probably need a warning for cross-aircraft paths, but leaving that
for a separate change since I’m worried it will warn on MP aircraft.
Maybe better checked in the Python scripts than in the app?
Compile a useful subset of FG as a shared library, and add two basic
uses of this to exercise some Flightplan / RoutePath / navaid
functions.
The test framework can/will be expanded incrementally from here, this
is just a starting point.
As part of this, add the ability to distinguish default vs explicit
airport selection via a new /sim/presets/airport-requested flag. This
enables us to more cleanly handle different combinations of startup,
especially the case where the user requests an airport but no runway
(wants auto selection), ensuring we don’t look for the default airport’s
runway (from location-presets.xml) in that case.
