frasmacon

Brilliant, thanks very much!

So when I choose the build gradle task it will be replaced with the correct version from build.gradle? On a side note, is there any way to synchronise this between the version specified with the @Mod annotation?

I followed the guide here: http://www.minecraftforge.net/forum/index.php?topic=21354.0 to set up IntelliJ to make a mod however when I run my mod using the "Minecraft Client" run configuration, in the Mods menu in Minecraft the version just reads $(version) as if it isn't being filled the the version from the build.gradle . mcmod.info: http://pastebin.com/jbQE1dHR build.gradle: http://pastebin.com/fYtXQ88N When I run using the Minecraft Client run configuration, the mods menu looks like this (The version in brackets I assume comes from the @Mod annotation): http://s19.postimg.org/opn5ttwoj/Minecraft_mods_menu.jpg[/img]

This may already exist I'm not sure... Nonetheless: I've noticed in lots of different mod packs that there are lots of metals that are all pretty similar. Like in Tekkit and Voltz and stuff there are like 3 steels or 5 tin or 2 bronze and stuff like this. I was thinking that each mod could register it's metal with the Forge API, then if another mod registers the metal, like for instance, 2 mods have a tin ingot, instead of using mod specific code and stuff it is a universal ingot. So like each mod uses the same item ID. I know I haven't really explained it very well but I think people will get the gist. So a better example than above: [*]Mod A wants tin and wants to generate it in the world [*]Mod B also wants tin and wants to generate it [*]These metals are registered with the Forge API, through something like forge.registerMetal('tin', true) (I don't code in Java so that may be massively incorrect) to tell forge it wants a tin ingot and it wants it generated in the seed. If I haven't really made this very good to understand I'll happily try to explain it. Thanks!