SuperKamiCatbug

Well I'm glad my meager amount of mod coding experience was helpful

I had a similar situation with a metadata block. The different metadata values each had a different model, so I added them as variants but it was still looking for a json with the default name. I figured that it might just add a "default" variant using the unlocalized name when no other variants are specified, though I wasn't sure where in the code to look for where that would be happening (looks like you found where that is though). So I tried moving my variant additions from init to preinit, and it stopped looking for the "default" variant.

Was thinking about why it still searches for an item json file with the same name as the block name, and thought maybe somewhere along the init process it was adding a default variant if no other variants were specified. So I tried moving the add variant for loop to preinit instead of init, and that seems to have stopped it looking for that json. Anything else odd or that could be done differently?

Trying to figure out the new texture/model system, and I have a metadata block with a different model for each metadata. Block rendering is working just fine, got the variants (one file) and block model definition json files (one for each metadata) set up. But I had some trouble getting the item models to work, since the item json can only use one block json as its parent. I fiddled around for a while and managed to get it working with this code: Item itemBlock = Item.getItemFromBlock(blockMulti); for(int i = 0; i<5; i++) { ModelBakery.addVariantName(itemBlock, Constants.MOD_ID + ":" + BlockMulti.NAME + i); } for(int i = 0; i<5; i++) { mesher.register(itemBlock, i, new ModelResourceLocation(Constants.MOD_ID + ":" + BlockMulti.NAME + i, "inventory")); } So basically adding variants of name modid:blockname<metadata value> and then registering each metadata with ModelResourceLocation's of the same name. So in my case I have blockMulti0.json-blockMulti5.json in my models/item folder, each using a respective block json as its parent. And this worked, but I'm not quite sure if this is the correct way. The log also shows that it still tries to search for a blockMulti.json file, even though I'm not registering that.

You've got a funny definition of "obvious" I must say -TGG Interesting...though I don't know enough about gradle's syntax to really know what that code addition does I was looking around the run configurations and it looked like it might be possible to write a short script that copies resources over, and have it run that script after make. Didn't look further into that though, since I have no problems with version 13. As for my definition of obvious...from experience, I've had different software versions cause strange behavior like this many times before, so it's left me feeling like I should have thought of it earlier lol

I see this line here: argo.saj.InvalidSyntaxException: At line 11, column 17: Expected object identifier to be followed by : but got [T] Which tells where it is finding an error. Try looking there and checking if something is out of place.

Try adding a comma after the description.

Well I figured it out. I knew I must have been missing something obvious, and I was...IntelliJ 14 places resources in it's own resource folder, while IntelliJ 13 places them in the classes folder. No tutorials I've seen mentioned a version, but I saw from screenshots that 13 was being used. I had just gone ahead and grabbed the latest though, and apart from the screen displayed when no projects are open, they look almost identical, so it took a while to notice. So yeah, fixed

Tried that too, no change

Gave it a try, but it didn't work.

After looking more closely at why it works in Eclipse, I noticed that Eclipse puts everything into a bin folder, both compiled classes and resources. This would make the class path and resource path the same, and so it works properly. So I guess now the question is, how can I set up IntelliJ to put classes and resources in the same directory?

Aside from just wanting to try something new, I was also having difficulty getting the code completion in Eclipse to work the way I wanted it to. In IntelliJ it's working perfectly but otherwise no particular reason. Yes Eclipse does have lots of features, but I never really used any of them that IntelliJ doesn't have. I actually like the less feature-cluttered workspace lol

I spent a while messing the the debugger to see how FML is loading the mod and it's resources. I was able to find out that it loads the mod with directory build/classes, which is fine...but then when loading resource packs in which to find textures, the same mod location is added as a resource path. Though both build/classes and build/resources are in the classpath, build/resources is never used because no mods were found in it, while build/classes is used as the resource path because it is the mod's class path. This would explain why compiling to a .jar works, because then the class path and resource path are the same. To test, I copied my resources to the build/classes folder, and it worked. How to fix this, though, I have no clue >.>

I think all the code and names are correct, since the jar file from gradlew build works with no problems.

fml-client-latest.log: https://gist.github.com/anonymous/6eac78b92971155a3a18 latest.log: https://gist.github.com/anonymous/ba582b76634e67d3dcea