Re: [Flightgear-devel] Feedback on the new error popup

[James T. <ja...@fl...>]

> On 11 Jun 2021, at 15:09, Tobias Dammers <tda...@gm...> wrote:
> 
> Hi,
> 
> Some thoughts on the new error popup on startup.
> 
> First, being a GUI popup, it addresses end users, but the errors being
> presented in grave-sounding language are not generally errors the user
> can fix. I understand that the goal of this is to prompt users to bug
> aircraft devs into fixing the aircraft, which I believe is a noble cause
> in itself - but in this case, I think the benefit doesn't outweight the
> cost. Contacting the aircraft developer may not always be an option;
> there may not even be a real problem (see below); and even if the
> aircraft developer can fix the problem eventually, the nag screen will
> keep coming back until you've installed the updated version, possibly
> months later (we all know that aircraft devs aren't paid for this, and
> leaving harmless warnings around rather than fixing them ASAP is a
> perfectly valid choice). At the very least, give the user an option to
> silence these dialogs (per aircraft, or globally), to keep the
> frustration to a minimum.

The language is very much up for discussion: it also needs to be translated. The current tone is what a bunch of English speakers judged about right for a first attempt, but of course suggestions are welcome. The important thing is that the messages should be a call to action, to provoke a user into checking the bug tracker, or asking on the forum ‘hey, why are all the displays in the B1900d purple for me?’, or similar.

A ‘don’t show again’ is absolutely planned, just not implemented yet. It will be per-error-instance, so if you ‘don’t show again’ for a particular aircraft or scenery path, it wont happen again. I /hope/ that’s the right balance between annoying and telling people what is happening. 

There are also some uses for the popup which are more serious: especially shader errors and out of memory errors : so there’s also some different UI to balance things out there. 

> And second, the errors being reported in my case are really not errors
> at all. They're warnings about something that I consider a feature,
> namely, listing objects in `<animation>` tags that may or may not exist.
> You see, those animations routinely get reused between different models,
> e.g. different types within an aircraft type family, and whether the
> animation targets exist or not can depend on all sorts of factors. So
> far, FG has always just ignored animation tags with missing targets,
> issuing a warning and leaving it at that. But now, actively using
> animations like this is considered an error, and the user is reprimanded
> for using an aircraft model that dares do this, and I find myself in a
> situation where, in order to avoid this un-mutable nag screen, I have to
> add additional ceremony to my animation files.

My ideal goal is to have the simulator run with *zero* warning or alerts, at least for an end-user. So for the <animation> tags: if this is feature, you need to formally request that this behaviour of animations become supported. (And then we remove the warning) Which may be a completely valid thing to do: we probably have various warnings that don’t actually make sense, but I’m defaulting to assuming all things are a ‘real warning’ on next. It’s much easier to provoke the discussion this way around :)

My expectation is that we’ll find some ‘warning’ things which everyone agrees are okay, and some which divide people on whether they are harmless or not. What we might end up doing for those is adding some specific disable flags, eg in this case:

	/sim/warnings/missing-animation-object=false

…which you could set in your aircraft if you’re okay with the warning, but other people feel it’s valuable.

Again, I’d expect to do this on a case-by-case basis for each warning, after some discussion here about relative importance / severity of the condition being warned about. 

BTW, the entire system is disabled in developer mode (—developer), there everything goes to console. So for aircraft developers if you choose to ignore warnings during day-to-day development, I’d expect a day spent just prior to making a release of an aircraft, would work pretty well.

Kind regards,
James