ntzrmtthihu777

use the forgesrc zip from files.minecraftforge.net, then do the setup with gradle (gradle setupDecompWorkspace), then find forgeSrc-version.jar under libraries in your IDE.

To put it simply we can't help with such vague information. Check how vanilla json files assign textures, when you GameRegister.register(block, "block") assets/modid/blockstates/block.json is automagically used to do the heavy lifting, ergo, study vanilla.

@Lex man, tough beans as soon as I heard about this even *maybe* happening I was on edge. Really wish I was a better coder, I've got all sorts of ideas that I think could be of use, and would love to lend a hand. But, since I'm not `that guy', I suppose at least I can help with the common questions (diagnosing PEBCAK, lol). All in all, I wish you (and whoever else is left on the Forge team) the best of luck and all my good wishes. This game is a bonding point between me and my little sister, and we love modded minecraft. I'd hate to see that ruined

Actually damage is also used like block metadata, in that you can jam alot of subitems into one single item. Spawn eggs, for instance, are all ItemMonsterPlacer, but with different damage values.

Agreed, lang files > by a huge degree than LanguageRegistry.

I've seen something like this before, apparently it doesn't like you having your array brackets on separate lines, try slimming it down a bit and see about that.

well, as far as the dev.json issue goes, copy the lwjgl versions from your working (I hope) client's version.json; as far as building goes, gradlew build should do it all for you, unless you made some derpy changes to build.gradle on that front, as such, could you post your build.gradle?

Totally agree, lang files > LanguageRegistry. Lets you localize the mod without touching a single line of java code, excellent for collaborative work on github. I've gotten quite a few pull requests for no other reason than for the person to graciously supply the lang file for their language.

This works for me, but how do you package this file in the .jar file when you distribute the mod? Or is it still too early in the 1.7 forge for that? No. if assets exist at src/main/resources running gradle build will bundle that into the final mod jar.

If you're using git/github you can set up branches for more than one mc version, that's how forgegradle's git manages to be for both snapshot 1.0 and 1.1.

same as before in general. The update touched on items, blocks, networking and audio, not so much on entities afaik. Granted, since forge produces func_ names for now you'll have to use those in the model code.

This.

@Nzkiwi: you need to register your nickname with nickserv, google is your friend here, its pretty simple Also, the issue with the obfuscated names is not so much the mappings as getting srg2source up to speed with gradle. It currently uses python but will be rewritten in java so it can interface with gradle properly or sommat. Untill then you can join #mcp on esper and talk to MCPBot

Job aint to be nice to noobies. If you can't properly install and configure a jdk then youve little business modding and or programming.

If you're using 1.6.4 mods on 1.7.2 you fail.