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

Yeah, I did think of that. Sadly, when I tried it JDK 7 didn't work either...

Constants class is here: https://gist.github.com/anonymous/446017088f130204e382 fml-client-latest.log is here: https://gist.github.com/anonymous/247c2769ee21f9b6e31f latest.log is here: https://gist.github.com/anonymous/639403eea673e0b2c0d6 Why are the forge logs split up like that anyways? I don't remember it doing that before...

Gah. Well thanks anyways. Whenever I try to do something new with computers, I seem to be plagued by weird problems like this Do you know how forge knows where to look for the mod's assets? Maybe it's looking for them in the wrong place, and I need to configure it to look in the correct place?

Here it is: http://i.imgur.com/w2SpayL.png

Sadly, no change.

Got it. Sorry for my noob suggestions >.> Been trying to get this working all day, and haven't found any answers anywhere.

I see... I noticed that in the build folder, the classes are in classes\main\<rest of file path> and resources are in resources\main\<rest of file path>. Compared to the jar file from gradlew build, where the classes\main and resources\main parts of those file paths are not present (meaning, there is the contents of classes\main and resources\main together in the jar). Could those extra folders in the build folder be keeping the mod from reading the resources properly?

I know, right? I can see in the forge logs that it recurses through the resource folder while looking for mods, and it does say it found an mcmod.info file. At that point tutorialorange was already identified as a mod. Would that influence anything, with them being read at different times? ...Kind of running out of ideas

Yes, it is. That was set up automatically when the module was generated.

the en_US.lang file is in src\main\resources\assets\tutorialorange\lang and the texture is in src\resources\assets\tutorialorange\blocks (tutorialorange is the mod id). IntelliJ was setup by running gradlew setupDecompWorkspace --refresh-dependencies, importing the build.gradle file into IntelliJ as a project, and then running gradlew gIR to set up the run commands.