I'm stumped.

No compile time errors, no runtime errors (that i can find) and yet my textures wont load for a block and 2 items.

The intended functionality is there, the block behaves like a block, the item like an ingot, and the tool like a tool.

The jar that gradle builds includes the assets in the recommended file paths.

I'm just shy of completely rebuilding the mod, but I feel like I'm so close.

The jar worked on 1.10.2 but when I updated the accepted mc versions to include 1.11.2 the textures stopped loading

Code repo:

https://github.com/dougclarknc/MinecraftMod

1.10.2 jar and 1.11.2 jar attached

I'll attach any log requested, but the only one I see is the server startup console output which gave me no errors to go on.

 

 

minerseyemod-1.10.2-1.1.jar

minerseyemod-1.11.2-1.4.jar

All asset paths have to be entirely lowercase in 1.11+.

the folders are all lowercase, you mean the files also have to be lower and not camelCase?

17 minutes ago, dougclarknc said:

the folders are all lowercase, you mean the files also have to be lower and not camelCase?

That's right, file names too.

Jingus crimbus. Well you right, it works now. Thanks. Does anyone know why this OUTRAGEOUS rule was enacted? Who does it benefit?!

FML started the lowercase enforcement in 1.11, but has been strongly advising it since 1.7 at least.
And it benefits everyone on Windows. (Or any non-Unix based systems, rather)
While in the development environment (IDE), "FileOne.png" and "fileone.png" could point to the same file. However, when you create your JAR (which is really just a ZIP file with different name) the OS cannot find "FileOne.png" any longer, if it was called "fileone.png", or "FiLeOnE.png" or whatever you called it, because of the structure of the mentioned compressed system.
As such, it would work inside your IDE, but not when you pack your mod. Countless of modders have had this issue, and reported this "bug".

 

And it is in no way "outrageous". Naming conventions, even for simple file IO's, makes it so much easier to organize your own files, and work with other's projects.

Edited March 15, 20178 yr by Matryoshika

Note, it is a industry standard due in part to exactly what Matry said. 

And it was not FORGE who forced it in 1.11, Mojang did.

We have always advised you follow the standard programming practice, its now just enforced by Mojang.

I don't know an awful lot about compression. Since google isn't returning any useful links as to why a jar cant handle CamelCase, please link or elaborate why this is.

Does this only affect jars? I've never heard of this "industry standard"

Now if some dev on *nix makes FileOne.png and fileone.png and a windows dev wants to reference one of those a) i can see the benefit of enforcing lowercase and b) *nix dev needs to change naming convention

Edited March 15, 20178 yr by dougclarknc

https://en.wikipedia.org/wiki/Filename#Letter_case_preservation

Yes if a developer intentionally makes the same file name in a different casing and expects users to know the difference then they are doing it wrong.

All archive formats that I know {notably they are mostly based off zip and rar formats} are case sensitive. As they simple store a map of "file path" to address in the file.

The point is jars CAN handle CamelCase. But "camelcase.txt" and "CamelCase.txt" are two distinct files and unless you specifically write a handler for it then there is no automatic translation of the names.

 

 

Quote

The point is jars CAN handle CamelCase. But "camelcase.txt" and "CamelCase.txt" are two distinct files and unless you specifically write a handler for it then there is no automatic translation of the names.

Ok, I'm almost following.

I'm not making the connection where if I have a FileOne.png (Windows, case-insensitive) and my classes only reference "FileOne.png" (Win, case-insensitive) and I zip both (jar, case-sensitive), who is trying to call "fileone.png"/who is storing it in lowercase? and why cant I point to "FileOne.png"?

I can only see the problem going the other direction, from a case-sensitive jar to a case-insensitive format

 

If I put CamelCase.txt into a jar and unzip it anywhere, i expect to always be able to call "CamelCase.txt"

Only took 1 OS class in school so please bear with me

Edited March 15, 20178 yr by dougclarknc

If you put "CamelCase.txt" into a jar and unzip it it will be "CamelCase.txt" unless whatever tool you are using is screwing with the file name.

As for who is trying to look for "fileone.png" That would be Minecraft:

 

There we go. Thanks for breaking that down.

Now, why is MC forcing .toLowerCase()? A MC personal preference?

Where specifically is this industry standard practiced?

I dont ship jars or deploy enterprise java, just writing qa automation, so idk which "standards" are just in-shop practices and which are "never use default package" standards

1 hour ago, LexManos said:

industry standard

 

1 hour ago, LexManos said:

standard programming practice

 

Edited March 15, 20178 yr by dougclarknc

Its practiced anywhere that a product is expected to run on more then windows. As almost every other system besides windows is case sensitive. It may not be forced in code, such as this case. But it is usually in the 'best practices' guide for naming things.

Mojang has decided to enforce it because they previously had no defined standard for themselves and people on windows were getting pissed off that their resource packs worked fine on disc and not when zipped. It's the exact same thing that causes all other products to define the standard to use for file names. They get annoyed with people having issues because they don't follow what others would consider common sense.

 

The choice between WHAT the standard was {lower case, upper case, camel case, snake case} was arbitrary. {Tho lower case is disproportionately used by the rest of the programming world, so it's no surprise they chose it}