Allow resource packs authors to acknowledge & dismiss shader warnings

[Aeltumn]

This is a follow-up to recent changes where Sodium now shows warnings to users when they are using a resource pack that changes core terrain shaders. Some packs need to override these shaders for vanilla users (or use glsl files elsewhere) and could use some method to make the warnings go away for end users.

So, this PR adds a way for authors of resource packs to include additional information in the pack.mcmeta file which indicates that the author is OK with Sodium gracefully ignoring their shaders.

An example pack.mcmeta would look as follows:

{
    "pack": { "pack_format": 18, "description": "My resource pack with custom shaders" },
    "sodium": {
        "ignored_shaders": [
            "rendertype_solid.vsh",
            "rendertype_translucent.vsh",
            "rendertype_cutout_mipped.vsh",
            "fog.glsl",
            "light.glsl"
        ]
    }
}

No errors are logged specifically about the specific files mentioned (only an info message). This has the benefit that the author of a pack has to see the error messages first, and would see the error messages on any new shaders that get blacklisted in the future. However, the author now has the opportunity to fix their pack and then remove the warnings from the end users which do not care. The config specifies it's ignored shaders to hopefully inform the author that these shaders are not being run.

This is my first MR so let me know if I did anything wrong and I'll fix it asap!

(note I removed some old parts of this message as I realised I had wrongly assumed how Sodium handled the shaders beyond the warnings)

[Octol1ttle]

I opted to remove both the user warning and the console log for safe shaders. The message logged to the console only really states that you can't override the file and doesn't say much more. So, if a pack author already acknowledges the warnings the console warnings don't say anything relevant anymore. Could be re-added if the logs did have useful info.

I think it would be best to keep the console log message, but mention in the message that the resourcepack opted to have the warning hidden

[Aeltumn]

I think it would be best to keep the console log message, but mention in the message that the resourcepack opted to have the warning hidden

That makes sense, I'll go change that.

[douira]

Does this mean these resource pack shaders correctly work with sodium or do they not work but also just not cause issues by being disabled?

[Aeltumn]

Does this mean these resource pack shaders correctly work with sodium or do they not work but also just not cause issues by being disabled?

If a shader is marked as safe in the pack it is not warned about and not disabled. The assumption is that the pack author can ensure no issues are caused and use this to communciate that.

If the server wanted to disable a shader they could send a different pack I guess, or just not have it at all.

[douira]

ok I spoke to some people for information and want to clarify that even if the warning is disabled, sodium isn't loading any of the shaders that it replaces in vanilla from a resource pack, even if the warning has been disabled. Sodium isn't exposing it's internal shader format and isn't allowing replacement of sodium's internal terrain shaders, which differ from those vanilla uses. This PR only allows disabling the warning that a resource pack is attempting to replace core shaders which sodium already replaced. If a pack has the warning disabling flag that doesn't mean sodium will use the pack's shaders, only that it won't warn.

[Aeltumn]

Talked about it on Discord, I wasn't aware that Sodium doesn't even use the base shaders, really sorry about that! I'll edit this PR in a bit to clarify that shaders are ignored, not safe, to clarify that they won't get used but the shader can be safely ignored.

[douira]

looks good to me

[jellysquid3]

The proposed change looks good to me, especially in regards to requiring resource pack authors to include the name of each file with a compatibility warning. There are just some code style nitpicks that should be resolved before we can merge it.

[Aeltumn]

Fixed the code style comments and re-tested everything. Should all be good now.

[jellysquid3]

Sorry for the delay. I know this is probably annoying for some resource pack developers. We'll try to push a release with these changes as soon as possible.