[1.7.2] Material.rock vs. Material.stone vs. ???

[Robosphinx]

Alright, my problem here is probably a simple fix, but it's not coming to me;

 

Inside eclipse, I've got my custom ores' material set as Material.rock, because that is what seems to have replaced Material.stone from pre-1.7... Works as expected, *inside* eclipse. Then I go build it and throw it into my client, and there's where I run into a snag:

cpw.mods.fml.common.LoaderException: java.lang.NoSuchFieldError: rock

 

Kinda weird... So I decided to try Material.stone on the off chance it gets compiled/obfuscated/magical-ized, and to no avail, same NoSuchFieldError: stone instead. So to any of you who have been working with 1.7 longer than I have and have figured this out: Help a guy out here?

 

Thanks in advance!

-- Robosphinx

 

EDIT: Here's the relevant snippet in a pastebin: http://pastebin.com/2XY6zUct (sorry for the wonky formatting, I suppose that's pastebin for ya.

[TheGreyGhost]

Hi

 

Just a guess- Are you calling registerBlocks() in preInit?  (If not - you should be, i.e in your

public void preInit(FMLPreInitializationEvent event) {

 

Also - did you build using gradlew.bat build?  Your output files should then be in build/libs.

 

-TGG

[Robosphinx]

Yes and yes

 

Most of my mods I use separate methods to keep it more organized, then call them inside their respective (in this case PreInit) method.

 

Although, building with gradle recently went wonky; it used to package it all into a single jar, but now all it is is the Meta-Inf in that jar and I have to manually package the rest from the bin folder.

 

Folder structure (files are in "quotations"):

forge
| .gradle
| .settings
| bin
|  | All my mod classes, in their folder structure (yes, compiled into classes), but not in a jar
|
| build
| eclipse
| gradle
| src
|  | project folder
|     | .gradle
|     | build
|     |  | libs
|     |  |  | properly named jar file, only containing "MANIFEST.MF"
|     |  |
|     |  | natives
|     |  | sources
|     |  | tmp
|     |  |
|     |  | ".gitignore"
|     |
|     | eclipse
|     | java
|     | resources
|     |
|     | "build.gradle"
|
| ".classpath"
| ".project"
| "build.gradle"
| "gradlew"
| "gradlew.bat"
| "settings.gradle" (points gradle to build the project folder -as well as- the main (example) mod)

[TheGreyGhost]

Although, building with gradle recently went wonky; it used to package it all into a single jar, but now all it is is the Meta-Inf in that jar and I have to manually package the rest from the bin folder.

Hmmm coincidence?

 

I am guessing that the failure to find Material.rock is something to do with incorrect deobfuscation, since it works ok in Eclipse but not in the jar.  The bin folder might not have the proper deobfuscation applied (not sure to be honest but it seems possible).

 

It might be worth reinstalling your Forge from scratch and trying the build again.

 

-TGG

[Robosphinx]

Just did that two days ago to get a more recent version of forge (1125), and I always set it up using

 gradlew setupDecompWorkspace

 

And it has always worked just fine... Kinda at a loss here

[Robosphinx]

Not very complicated actually, it let's me keep all my projects in one workspace and the grade system is designed specifically to make that easier. I'll link to where I got the setup from if I can find it, but I'm pretty sure it came from right here in the MCF forums. And as I said before, it worked seamlessly for about 7 months before now.

[Robosphinx]

Well that's a side note anyway, I can still functionally export my mods, so back to the original problem at hand: What's up with Material.rock / Material.stone / Whatever may have replaced them? Has anyone else had success with Material.rock and I just need to recreate my workspace again or...?

[Robosphinx]

Alright, I just deleted my workspace and recreated it from scratch, works just fine now.