Workaround for Linux shaders breakage

[Rainyan]

Description

This is a hack around the vision mode shaders sporadically breaking on Linux builds.

It seems that for whatever reason, the shader state cached at the glshaders.cfg file somehow leads to the corruption upon successive runs of the game, and write-protecting the file offers a simple way to avoid that breakage.

Ideally, we should figure out what's really going wrong here at the shader system and/or precaching level, but this should suffice for avoiding the bug.

I opted to implement this as a CMakeLists step rather than submit the glshaders file itself, because to my understanding git does not version control the "read-only" file permissions required to keep the game from modifying the file.

edit: The hack is now done at runtime, because doing it in the CMake scripts won't carry over to users as pointed out by nullsystem, and we can't version control the file, because the filesystem specific metadata required for the read-only state won't carry over, and the concept of file permission flags is not universally available on all filesystems.

For more discussion, see: #438 (comment)

Steps to repro the bug

• Use Linux
• Build the game from master (or test with a recent release)
• Launch the game
• Check whether visions modes are broken for any of the 3 classes
• If they're not broken, close the game, relaunch it, and check again
• If you have the bug, you should be seeing shader corruption within a few tries

Steps to test this patch

• The aforementioned corruption no longer occurs

Toolchain

• Linux GCC Distro Native [Mint 21.3 Cinnamon + (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0]
• cmake version 3.30.3

Linked Issues

• Fix [BUG] Vision modes are sometimes broken on linux #438

[nullsystem]

My main concern is for those downloading and installing the builds. Checking the GitHub artifact, the resources.zip is generated via Windows so it didn't apply here and neither the libraries zip includes this, so it seems to me those will not get the read-only glshaders.cfg.

[Rainyan]

My main concern is for those downloading and installing the builds. Checking the GitHub artifact, the resources.zip is generated via Windows so it didn't apply here and neither the libraries zip includes this, so it seems to me those will not get the read-only glshaders.cfg.

Right, and the chmod permissions are stored on the filesystem, so generating the file in the CI is a dead end... I guess I'll have to see if this can be monkey patched at runtime after all.

[Rainyan]

@nullsystem I've moved the patch to the client dll initialization, could you test if it's still working correctly for you?

[xedmain]

what should happen is that glshaders.cfg gets set to read-only when I run NT;RE, right? I can test right now

[nullsystem]

@Rainyan Looks like it works for me and manages to stub out that file with empty glshadercachev002.

[xedmain]

installed resources and linux release from the artifacts, ran the game twice and checked visions both times:
vision modes all work
the glshaders.cfg file is 21 bytes, set to read only

I wonder what will happen if NT;RE is installed on wacky filesystems like NTFS, FAT32/exFAT that have different types of permissions, as well what will happen if the current user can't modify permissions

[xedmain]

nevermind, I see in the code that it just errors out

[Rainyan]

I found the cvar mat_autosave_glshaders which is used by the shaderapidx9 library. It seems that toggling it off prevents the game from generating the problematic glshaders.cfg file altogether.

I made changes such that we toggle the autosave off via cvar, and then delete the file if it already existed. Since we're too late intervene at client load, it'll still be bugged for a run where the buggy file existed, but this should fix it for any future runs. And players first-time launching the game should never run into the problem, as the cvar change should prevent the file from being generated in the first place.

This also removes the chmod filesystem permission flags fiddling, since it wasn't compatible across all the possible kinds of filesystems, as pointed out by @xedmain.