[Linux] Extra game files not in file search path

[Caligari87]

I think this is a long-standing issue but only became apparent to me just now.

The files lights.pk3, brightmaps.pk3, and game_widescreen_gfx.pk3 are all installed in the /opt/gzdoom/ folder, but this folder is never added to the .ini as a search path.

Code: Select all

/opt/gzdoom/brightmaps.pk3
/opt/gzdoom/game_support.pk3
/opt/gzdoom/game_widescreen_gfx.pk3
/opt/gzdoom/gzdoom.pk3
/opt/gzdoom/lights.pk3

Code: Select all

[FileSearch.Directories]
Path=$HOME/.config/gzdoom
Path=/usr/local/share/
Path=/usr/local/share/doom
Path=/usr/local/share/games/doom
Path=/usr/share/doom
Path=/usr/share/games/doom
Path=$DOOMWADDIR

gzdoom.pk3 and game_support.pk3 appear to load properly, but setting autoloadbrightmaps / autoloadlights / autoloadwidescreen doesn't work, and probably hasn't worked for some time. This is a somewhat hidden issue, as the IWAD selection box on Linux doesn't include the checkboxes for any of these (or any other optional settings for that matter).

Possible solutions:

1. The files need to be installed to one of the other directory paths.
2. The path list needs to include /opt/gzdoom/ (unless this can be pushed, users would need to delete their .ini).
3. The loading code needs to treat these files the same as gzdoom.pk3 and game_support.pk3.

[Caligari87]

So I was doing some reading around and it looks like for GZDoom's purposes, option #2 above might be the most consistent. This thread on StackOverflow suggests that /opt/ is meant for "monolithic windows-style" application deployments from outside sources. Plus it would avoid blzut3 needing to change the package build.

On the other hand, /opt is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor.

(though obviously there's significant debate on this point as is traditional with all things *nix).

Unfortunately I think it means that existing Linux users would either need to regenerate their INI on the next version update, or add the path manually, but if we're being truthful the amount of people affected by this seems to be rather small since it's probably been broken for years.

[Rachael]

I think Option #3 would be the best way to go, I just haven't got around to it.