Note to self: Is this a release mode/broken by optimizer thing? Debug mode seems un-affected.

EDIT: Debug build's also affected, so not debug vs release issue

Note to self: Is this a release mode/broken by optimizer thing? Debug mode seems un-affected.

how are you sure that debug mode is 100% unaffected? it wasnt happening 100% of the time on release linux (atleast on my machine), found a way to reproduce?

From some limited empirical testing on my own machine, this seems to fix it at least for me:

• In the game's root folder (where the gameinfo.txt is), delete the generated glshaders.cfg file, if it exists.
• Launch the game to main menu.
• Close the game.
• Verify that in the root folder, a new glshaders.cfg has been generated.
• Make that file read-only: chmod 444 ./glshaders.cfg.
• Launch the game and verify vision shaders work for all 3 classes.
• If broken, delete the glshaders.cfg and start over from step 1, until you get working shaders (undo the read-only with e.g. chmod 644 ./glshaders.cfg to be able to delete the file)
• Once you have working shaders, and the file is write-protected, the shaders shouldn't get corrupted anymore.

I don't know why this happens or if this is a universal fix, but I can't reproduce the bug anymore after following these steps. I'm guessing it might have something to do with whatever state is being cached here somehow getting corrupted over multiple restarts of the game.

Would be curious to hear if this works for others using Linux.

@Rainyan Seems like that works. It seems the cache is rather inconsistent/varied anyway (some having like 3 items, some like 50). It seems to me that file can just be this:

"glshadercachev002"
{
}

And read-only and it seems to also just work out due to no cache? It also looks like it generates at the end, maybe it could be programatically worked-around by being early (or late) enough to delete/overwrite that file as a potentional work around to not need read-only. Although just a guess.

It also looks like it generates at the end, maybe it could be programatically worked-around by being early (or late) enough to delete/overwrite that file as a potentional work around to not need read-only. Although just a guess.

I quickly tried this in CHLClient::Init, as soon as we've acquired the IFileSystem* from the factory, by calling filesystem->RemoveFile("./glshaders.cfg", "MOD"); but that seemed to be too late as I was still sporadically seeing the bug when testing with multiple restarts. But maybe this would be viable closer to the dll entry point, perhaps using std functions if we don't have a filesystem interface pointer available yet. Could be worth exploring.

Another thing maybe worth testing would be to simply programmatically rewrite the file contents to the dummy contents you posted above at CHLClient::Init, and see if this has any difference from simply deleting the file altogether. But I suspect it may be too late at that call site to have an effect.

But if we are able to track the file's write permissions somehow with Git, then that might be a simpler solution. Or if that's not possible, generate the dummy file as a CI build script step, but this would have the downside of devs needing to set this stuff up manually.

edit: I suppose it could be a part of the Linux CMakeLists(?) (This doesn't work because it'd only generate for developers running the build system.)