ZDoom

I'm going to close this commit due to the age of it. I personally don't have any problems under Linux and haven't had reports of this from anyone else so hopefully its all good!

Okay so it's only the Debian archives that work the way I said. The 'install' target generated by CMake is a whole different bag of worms.

I do not know if [url=https://github.com/coelckers/Raze/commit/38faefa66383d826f28953ad54a9b51fd5e054a3]this commit[/url] solves the issue, but it does nevertheless set things that should have been set from the get-go.

To be quite honest I don't even know if the CMake project does the same thing as what the official Debian archives do.

As for me personally, it's a feature I use very little, so I haven't had much reason to use or check it.

My role in porting Raze to Linux was mainly getting it to run at all. I really can't be the only one doing this stuff for Linux, I am not the one who uses Raze on Linux a whole heck of a lot. Much as I like Raze, I use it very little (I am not that strongly tied to Build games), and I *rarely* use Linux for anything gaming related, I more often use it for projects.

Why isn't it set up like that anyway? The CMake project was built upon GZDoom's after all...

#!/bin/bash

exec /opt/gzdoom/gzdoom "$@"

I don't see why not. Raze wouldn't be the first to do that.

I think the underlying intent of it all is that all executables on the system can be found in a folder easily marked with the $PATH variable, and its data in another consistent spot. But things get a bit muddied up, when as you already cited, everyone has their own idea of what those folders should be.

That being said, what GZDoom does is it installs a script into /usr/games (which is $PATH searchable) called "gzdoom" that consists of nothing more than the following:

[code]#!/bin/bash

exec /opt/gzdoom/gzdoom "$@"
[/code]

All of its data is in that folder, alongside the executable.

Raze should be able to do something similar. That might not be too hard for me to set up.

... which all would be a moot point if it could just be placed into the same folder as the executable - like any properly designed Windows and Mac application does.

Well - the game data itself can go literally anywhere regardless of distro rules, you could just do /opt/data/raze and call it a day, or even /opt/raze. (GZDoom's .deb does /opt/gzdoom) The key here is that the installer script and the file searcher must agree on exactly where that should be.

TBH, I'll never understand why Linux is so anal about putting the game data into some folder far, far away from the executable. And of course that apparently every distro uses different rules. How is this ever supposed to work? Nobody can memorize all these idiotic rules.

Raze 0.8.1, Linux Mint 19.1 x86_64, compiled from the source archive from the Github Releases section.

Raze, for whatever reason, absolutely refuses to check any of the FileSearch or GameSearch paths in the INI file for Raze.pk3. Running a copy of Raze that has been [i]sudo make install[/i]'ed, from any folder that does NOT contain Raze.pk3, spews this error message:
[url=http://i.imgur.com/ADGks4v.png][img]http://imgur.com/ADGks4vl.png[/img][/url]

However, popping up a terminal window and changing to any folder containing raze.pk3 causes the game to run normally, as does manually changing the working folder of any menu entry created for it, as seen here:
[url=http://i.imgur.com/LfJMbva.png][img]http://imgur.com/LfJMbval.png[/img][/url]

For what it's worth, for some reason, [i]sudo make install[/i] from the build folder copies raze.pk3 into [b]/usr/local/share/games/doom[/b] which otherwise contains no other files. Raze doesn't detect it in there, either.