At least, this makes regression tests pass without patching the script, now that OpenGFX (downloaded from in-game) is found:

Running ai/regression/tst_regression... passed!
Running ai/regression/tst_stationlist... passed!

Hmm I think config_dir should be an extra search dir appended before personal_dir. Would make more sense and keep the current behaviour too. Quote from readme:

Savegames will be relative to the config file only if there is no save/ directory in paths with higher priority than the config file path, but autosaves and screenshots will always be relative to the config file. Unless the configuration file is in $XDG_CONFIG_HOME/openttd, then all other files will be saved under $XDG_DATA_HOME/openttd.

⚠[EDIT] Mislead comment, keeping it only for reference⚠

Current proposal breaks past behaviour of OpenTTD, as the location of the configuration file supplied with -c implies a configuration directory when resources & directories are created/searched for.
Worse, the configuration directory has precedence for every resource that are now not discovered/loaded anymore.

That is IMHO bad design, as documented directories shall be the only place the program shall ever write to, unless explicitely told otherwise. Widening the scope of the switch is not to be expected
With that idea in mind, -c should only provide the configuration file and not imply anything else, the working directory structure remaining the same.
This fix actually enforces that.

Now, it is not a satisfactory decision, as it breaks the backwards compitibility.
One idea is to transform the meaning of the -c switch from 'Loading a configuration file' to 'Changing working directory': This way, creation/search of files in a specified directory would be explicit, thus naturally expected.
In this working directory, the configuration file would naturally be seeked for and have higher precedence than other locations.
While the overall behaviour shall be the same, the semantics at hand imply an implementation which might differ quite a bit. I have no idea yet.

As a fallback, the new -c switch, normally accepting directories, could still be accepting the configuration file, implying the working dir around it, exactly as it is doing in the trunk version.

TL; DR
I do not think my PR breaks how the game loads save files in anyway.
From what I witnessed, it merely changes/fixes the path for auto-downloaded content, which was searched in the same location as the supplied game configuration file.

Scratch my long previous comment.

It seems the intel I got about nice precendence of directories over others is simply not how the game is working at the moment.
As an example, savegames are loaded following that logic:

As I pointed out in my issue (and fixed here), the same Searchpath is not necessarily the same used for building paths to each Subdirectory. Combinations are context-dependent, and the logic hard to follow.

If you want to question potential side effects, it is best to take them one by one and either follow their logic into the code, statically, or just dynamically compare trunk & this version builds.

This pull request has been automatically marked as stale because it has not had any activity in the last month.
Please feel free to give a status update now, ping for review, or re-open when it's ready.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

Ping?

This pull request has been automatically marked as stale because it has not had any activity in the last month.
Please feel free to give a status update now, ping for review, or re-open when it's ready.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

Ping?

I'm going to close this one, as there's been no consensus on the correct solution, other than this is likely just a hack on top of a (much older) hack. Feel free to discuss in #7311