Cici

It is not, it's how the sound origin is placed in relation to the block and where you would be looking to place said block

this occurs with other tiles but its most commonly notable with torches, IE tunneling and placing a torch to your left/right will result in the sound coming from the opposite ear

That't not my point.

Let's try a different wording: The furnace, smoker, and blast furnace all have individual filepaths for their gui's, even if said gui textures are identical in contents. This is good.

Chests, double chests, Ender chests, and barrels, as well as dispensers and droppers, share filepaths with one another. This is bad, it is inconsistent with the precedent set by the recent two furnace blocks. They should be changed to have individual file paths like the furnaces do.

This does not mean creating an entirely new texture. For regular and Ender chests, and barrels, they can just copy-paste the Shulker box's texture. Double chests can keep using generic_54.png, but renamed. Droppers just copy-paste the dispenser's texture.

This is an actual inconsistency though, not with the texture content but their presence (or lack thereof). There is a precedent set by newer textures, specifically furnaces, blast furnaces, and smokers, that each container screen should have its own texture, to which older assets have not been updated to fix this. If the three furnaces have their own textures, that look identical mind you, while the 4 storage blocks, bar one, are all share one texture, that which also mutates itself depending on which one of the storage blocks is being accessed, is not an inconsistency? Then I really don't know what is anymore.

This is not a feature request, this is an inconsistency that should be addressed like any other texture and file inconsistency have been in the past, that have been reported here.

A glossed-over look makes me think this is a problem with whatever GL library you're using.

So before you send the shader to "glCompileShader" or whatever wrapper func you use (I'm working off of de-obfuscation map'd stuff), do some kind of pre-preprocessing on the file to remove extraneous *'s (as I believe this is an issue with the compiler searching for the end of the multiline comment, and /* */ being a special case in that it's not ended by one character? Making assumptions, I don't know what's going on in there).

It's a hack but it'd probably work (assuming this is the root cause of the issue to begin with). Hell in that stage you could probably just remove the comment entirely, but at some point you just gotta bug the library creators about this instead of writing your own jalopy preprocessor.

Of course this is just a guess with minimal effort put behind it so I could (and probably am) wrong, at least about the source of the issue. I'm at least 60% confident in the guess that it has to do with looking for the end of the comment though.

EDIT: more looking has made me look like an idiot. blaze3d does have a preprocessor of its own. My bad.

Haven't looked through it extensively but I still think my 60% guess is the issue.

Indeed I have. The shader would compile perfectly fine without the multiline comment, in addition to it already having multiple newlines at the end.