Alberth wrote:

Originally filed as a feature request, but I would consider it more a bug than a feature request, as recovering from an impossible preset should be somewhat cleaner imho.
Note that this is mostly a windows issue, at unix the message get printed to the console, and the game starts normally, so one can fix the problem.

Terkhen noted that the above error dialogue is ours, created in os/windows somewhere.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9893

Terkhen wrote:

I have no problems with closing the information window when OpenTTD is minimized: you just need to press "Ok" and then you can close OpenTTD normally. What problems are you experiencing exactly?

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9901

Transportman wrote:

If you force OpenTTD and the information window to the tray (by using Windows key+D or the right mouse click on the taskbar), you can't click OK or cancel if you maximize it back open, clicking in OpenTTD or in the information window minimizes them again. It is a bit of an edge case that I noticed during some switching between windows when I filled in this feature request/bug report, report was more about the fact that OpenTTD reports the problem with the preset in such an ugly way, instead of the normal red error box inside OpenTTD itself.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9903

hgnmu128 wrote:

The error is reported using ShowInfoF()

settings.cpp - Lines 1357-1373:
[code]
/* Check if item is valid */
if (!FillGRFDetails(c, is_static) || HasBit(c->flags, GCF_INVALID)) {
const char *msg;

                    :
                    :

  	ShowInfoF("ini: ignoring invalid NewGRF '%s': %s", item->name, msg);

[/code]

Maybe a little bit of laziness to avoid a few lines in the lang/* files and a seperate call of ShowErrorMessage() for each error.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9967

Terkhen wrote:

I wonder why do you assume that the reason for that implementation is laziness. The documentation of ShowInfoF hints at the real reason.

/**
* Shows some information on the console/a popup box depending on the OS.
* @param str the text to show.
*/
void CDECL ShowInfoF(const char *str, ...)

We need three different OS specific implementations because the error messages of ShowInfoF can be triggered even before OpenTTD has a GUI. If we have no GUI, ShowErrorMessage will (of course) fail to show anything. Therefore what is needed for this task is a method to detect if the GUI is already working. Once we know that, we can call ShowInfo() or ShowErrorMessage() accordingly. In this case in game errors would be displayed correctly, but we would still have a way of giving feedback of errors that happen before the GUI is started.

I did not find a simple way of checking if the GUI is enabled or not without introducing new global variables. I suppose the next time I check this I will end up adding them if I don't find a simpler method. If you are interested into this issue, feel free to look for a better way. As always patches are welcome :)

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9968

hgnmu128 wrote:

I said 'maybe'. I'm pretty new to this project and by looking at the code (yes, it is well commented and documented) have only acquired a vague idea about how things are. And like you said, I could not find a simpler way than adding global variables, other than making an error-finder function and make them return some value, like the old school graphresult(), but that would be idiotic IMO. I would go with the globals. Better late than never.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9969

Rubidium wrote:

The laziness with respect to the few strings that can be trivially added and then just using the normal error signalling is more a chicken-egg problem than laziness.

Upon loading the configuration file we load the current list of NewGRFs. This uses the same methods as when loading a preset later on in the game. The configuration file also contains the video driver and such to start OpenTTD with, as well as the language to use in-game. Thus at the time the method can be called (and is called most often) it is yet unknown what language is used or what video driver, so it can't just use the normal methods.

A secondary issue is that you would open the error message before the windowing system is initialised. Upon the (re)initialisation of that subsystem all windows, including error message windows, are closed.

A tertiary issue is that you can only show a single error via the in-game error messages, whereas this method will show all errors in subsequent windows without having to write lots of code.

Finally, it is an extremely rare corner case which is only triggered now because the version checks of NewGRFs have become more stringent and could otherwise only happen when people remove NewGRFs.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594#comment9976

Rubidium closed the ticket.

Reason for closing: Fixed

In r23480

This comment was imported from FlySpray: https://bugs.openttd.org/task/4594