Optifine is messing with procedurally-generated textures from Mystcraft

[Kizzycocoa]

Optifine 1.12.2 seems to be the culprit of an issue with Mystcraft. To easily see the issue, What Looms Ahead helps to craft the banners Mystcraft provides.

Essentially, there is a "language" in that mod that is procedurally generated from symbol parts on the fly, based on the Myst franchises. There is integration into the Banner system so each symbol can be placed onto a banner. However, Optifine seems to cause issues with this, making the texture a solid white, regardless of dye used. This can be circumvented if the texture, in any form, exists.

Essentially, Optifine only allows hardcoded images, and errors when a mod uses a Forge-based method to dynamically generate textures.

I'm unsure precisely of the nature of the issue, but that's the best handle I can get on it in discussion with the Mystcraft modding team. The original modmaker is making a small batch to try to fix it his end, but has said that Optifine should be made aware of the issue. In fact, it's a condition to his releasing the fix. :P

Hope this can be fixed!

[Kizzycocoa]

To elaborate, this particular link seems to note the method that Mystcraft is fetching these symbols that Optifine is blocking:

https://github.com/MinecraftForge/MinecraftForge/pull/5041

[sp614x]

The LayeredColorMaskTexture patch is there and MinecraftForgeClient.getImageLayer() should be called. Can you provide a test case (how to generate a banner with custom texture)?

[TheFloydman]

You can grab a few from the creative menu. They should be a red banner with yellow pattern, but they are all pure white with OptiFine. I added blank files with the correct banner names at each pertinent location, and OptiFine loads the textures correctly.

[TheFloydman]

Unless you're asking how Mystcraft generates it's banner textures. I don't know the exact mechanics, and it's closed source, but it generates a BufferedImage and passes the ResourceLocation to Forge.