This avoids crashing when using Qt : we cannot call exit() safely since
QGuiApplication won’t shut down correctly. Instead throw a special
marker object and catch this in boostrap.
For an instance of this, see:
https://sourceforge.net/p/flightgear/codetickets/2070/
Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
- Rename fatalMessageBox() to fatalMessageBoxWithoutExit(). This should
prevent the kind of bug that prompted this set of changes: someone
calling fatalMessageBox(), assuming the program would stop at that
point, whereas in reality it did not.
- Add new function fatalMessageBoxThenExit(). This is not vital of
course, but allows one to spare one line here and there and to apply
the DRY principle for such fatal exits.
- Replace every existing call to fatalMessageBox() with one or the other
of the two new functions. Improve formatting along the way. This
fixes a few bugs of the kind explained above.
This reverts commit 9e6a3ebc6b ("Make
fatalMessageBox() end with std::abort() and declare it [[noreturn]]").
After reflexion, it seems better to let fatalMessageBox() return,
because there is existing code that appears to be relying on this aspect
to do some work after having called fatalMessageBox() (cf. main() in
bootstrap.cxx). Also, the way of exiting from fatalMessageBox() after
commit 9e6a3ebc6b (std::abort()) was probably too brutal for a
controlled exit---as opposed to a terminate handler.
This allows us to display a platform-native dialog for problems
which occur early in startup (before we can show a PUI/Canvas dialog).
In particular this improves feedback where FG_HOME, FG_DATA or
aircraft selection is wrong, all of which happen very early in startup.
