Yes, like I mentioned previously (and on the wiki): it automatically supports reset/re-init (and switching aircraft) by being put into $FG_ROOT/Nasal, because all scripts there will be reloaded/executed currently as far as I am aware - while that is a bit unfortunate as a hack, it does save us some time/effort here.
Regarding the idea to "only" log the error the console/log file, I am not convinced - mainly because 1) most people have trouble locating their $FG_HOME, locating their log file, opening that and posting it and 2) as we recently learnt from Bomber and Gijs, the closing behavior is problematic on some OS (namely Windows), due to the console terminating immediately, too.
In other words, I would implement it such that it ALWAYS 1) logs to file, 2) logs to the console and 3) sets a /critical-error property in the global property tree - which could in turn be watched/processed by arbitrary GUI front-ends, including Phi, Qt5 but also PUI/Canvas or "pui2Canvas".
At the end of the callback, it would either run fgcommand("exit") to terminate the process, or return back to the Qt5 launcher or AircraftCenter.
The error message could be improved to also show a "solution" line in the form of:
Solution to fix this: upgrade FlightGear or downgrade the aircraft you are using, or use a different aircraft
The "upgrade FlightGear" part could be implemented as a button to open the download page on the website
Thorsten wrote in Tue Nov 17, 2015 5:03 pm:There's no serious 'no canvas' mode forseen as far as I know - so 'no canvas' pretty much is 'no rendering'.
There is in fact a so called "headless" mode (=no visible rendering) being worked on by Zakalawe, for better regression testing, i.e. to test non-graphics code in isolation, e.g. on a server (like the build server) - so that memory occupancy for different combinations of features can be logged and compared to past FG releases:
http://wiki.flightgear.org/FlightGear_Headless