I mentioned this roughly 2-3 hrs ago - the whole thing looked suspicious right away, due to its "naming conventions" when it comes to properties.

In other words, there is an actual requirement - as can be seen by aircraft developers coming up with such features, so it would make sense to determine the requirements and come up with a generic feature, that can be used by aircraft developers on an optional basis.

And those not wanting to deal with support requests, could just as well "fail" during startup:

Well, I would suggest that any fgdata implementation only use a min version number. That way you avoid the maintenance burden issue. It should also be GUI independent (i.e. it works in a non-GUI mode with no PUI, no Phi, no Canvas, no Qt, etc.).

bugman wrote in Tue Nov 17, 2015 3:57 pm:It should also be GUI independent (i.e. it works in a non-GUI mode with no PUI, no Phi, no Canvas, no Qt, etc.).

normally, that'd be over-engineering at its best: given that Phi is merely a run-time option and the state of reset/re-init, that Qt5 is only just about to become more than a startup option, and that the simulator would already be running at that point anyway.

But it's IS already GUI-independent by being implemented on top of XML, properties and Nasal, the visualization part of the message is arbitrary and could be anything - i.e. the XML dialog shown above does not need to use PUI at all, it can be just as well processed using Phi, Qt5 or Canvas (and even dumped just to the console):

There is no reason why Qt5/Phi or whatever could not render a similar dialog, and all front-ends could be using the same "common service layer" mentioned by Torsten here:

Torsten wrote:There is currently heavy activity towards a new UI. There will be the HTML5 based version, I am currently working on and an internal implementation based on well supported libraries. Most likely, both will use a common service layer to provide necessary data.

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 4: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:

It depends, I was going to use something like version-check, but then realized that it might be useful to allow arbitrary properties be checked, e.g. to check for OSG/OpenAL stuff, in case there are known bugs - but that would not be the responsibility of aircraft developers, so we could just as well do such checks at the preferences.xml level, or even just in about.xml

But I was hoping to at least allow different kinds/classes of messages to be specified by aircraft developers, analogous to SG_LOG() log-levels, so that errors/warnings and info would be treated differently, while also providing an option to override/customize the message itself, e.g. in the form of having blocks like these:

Edward, one problem with putting it in the log, is that the average Joe Blogs doesn't even know about the log file, and that to the best of my knowledge, the console is not on by default. Another thing to think about is that the console closes immediately after a crash, so it is rather hard to read a phrase in a fraction of a second

legoboyvdlp wrote in Tue Nov 17, 2015 7:17 pm:Edward, one problem with putting it in the log, is that the average Joe Blogs doesn't even know about the log file, and that to the best of my knowledge, the console is not on by default. Another thing to think about is that the console closes immediately after a crash, so it is rather hard to read a phrase in a fraction of a second

True! Though having it in the log file as well as printed to STDOUT, plus as pop up dialog implemented separately in each GUI (as needed) would be useful.

Like I said previously, in its current form it will definitely do all 3 things: 1) write to the log file, 2) log to the console and 3) write to a signal property that can be handled by an arbitrary GUI front-end like Phi, Qt5, PUI, Canvas or pui2Canvas - so it is totally agnostic to the front-end being used, and it would be to to the corresponding developers/maintainers to provide a corresponding signal handler (like the dialog shown above).

I still think we need more feature-requests/use-cases related to this. For instance, we could add buttons to it to open an aircraft specific wiki article, or the forum etc

bugman wrote in Tue Nov 17, 2015 8:15 pm:I don't think anything else would be needed, apart from functional code, and example to test, and a message to the mailing list to inform the others. Oh, and maybe the text:

"If you dare report this on the forum, you will be chased away with pitchforks and forever banished from this land!"

it will be strictly optional anway, i.e. won't do anything until an aircraft developer changes their -set.xml file to add the corresponding heuristics for the check, at which point the person most familiar with the aircraft simply decided to discontinue support for a particular fgfs version.

So it would not affect anybody "as is", as long as it is not explicitly switched on and configured for an aircraft