Choonster

build/libs in your mod's directory.

It may or may not be the source of the issue, but packet handlers are run on a separate thread where you can't safely interact with normal Minecraft classes. You need to schedule a task to run on the main thread, as explained here.

The Elysium and another mod are both configured to use dimension ID 2. You need to change this in the config files of The Elysium or the other mod (assuming they've added a config option for the ID).

The file should be called mcmod.info, not mc.modinfo.

Did you try looking at WorldGenMinable ? In both 1.8.x and 1.9, the two-argument constructor calls the three-argument constructor with a default Predicate . In 1.8.x, this was BlockHelper ; in 1.9 it was renamed to BlockMatcher .

Environment variables are part of the OS, not Java. This page explains how to edit environment variables in Windows 7 (it was the first search result).

IExtendedEntityProperties was deprecated (though never actually marked as such in the code) in 1.8.9 when Capabilities were added. Capabilities completely replace IEEP .

I suspect you have the JAVA_OPTIONS environment set to that, I suggest you delete it. The .gradle directory mentioned in the tutorial I linked is in your home directory (~ on Unix-like OSes, %USERPROFILE% on Windows), not your mod's directory.

Item#getArmorTexture changed signature in 1.9 ( int slot became EntityEquipmentSlot slot ), you'd already know this if you'd used the @Override annotation. If you give your ArmorMaterial a name that includes your resource domain (e.g. mineworld:ruby_armor ), you don't need to override Item#getArmorTexture at all.

This tutorial explains how to set up a ForgeGradle workspace and how to give Gradle more memory.

GameRegistry.registerItem(Item, String) registers the item with the specified name. GameRegistry.registerItem(Item) registers the item with its registry name, which can be set with Item#setRegistryName . You haven't set the item's registry name, so GameRegistry.registerItem(Item) throws an exception.

Did you click the Make Project button (the green down arrow next to the Run Configuration dropdown) after making the changes? Did a message pop up saying that X classes were reloaded or hotswap wasn't implemented?

Exactly what he said: You never actually reference the proxy field (at least in the code you've posted), so it's not doing anything. If you want its methods to be called, you need to call them yourself.

Your models couldn't be found. Are they in the right location? You also posted the console output rather than the FML log. The log contains finer-grained messages that explain what's going on.

There should be some errors in the FML log (logs/fml-client-latest.log), upload it to Gist and link it here. Like diesieben07 said, you should also post the code; preferably on Gist with syntax highlighting.

/give will always be able to give the player any registered Item , but not every Block has an Item form. Calling an overload of GameRegistry.registerBlock that has a Class<? extends ItemBlock> argument and passing null as that argument will register the Block without creating an ItemBlock for it. Vanilla does this for its signs: there's no ItemBlock form for either sign Block , there's a completely separate Item (an instance of ItemSign ) that places the appropriate Block depending on where the player clicked.

You're using a developer version of Forge Multipart, this only works in the development environment. Download the universal version instead.

I didn't know it recorded any logs. I don't see any anywhere. Gradle outputs to stdout (the console you're running the command in) and saves the most recent output to .gradle/gradle.log in your ForgeGradle workspace directory (i.e. where build.gradle is).

You didn't post logs, though.

You need to understand Java and OO programming in general before you can make a mod. There won't be a tutorial for everything, so you need to know how to read existing code and use it. The registry already has the methods you need, you just need to call one of them with the appropriate arguments. Create an ItemStack each for your input, ingredient and output items and call BrewingRecipeRegisty.addRecipe with these three ItemStack arguments. That's all you need to do.

Do you actually understand Java? You don't need to create a new method, just call one of the existing ones. The methods expect ItemStack or String (ore dictionary name) ingredients and outputs, not Item s.

Change the minecraft.version property in your build.gradle to the new version, run setupDecompWorkspace and refresh your IDE project. If you're updating to 1.8.9, you'll need to update to ForgeGradle 2.1 from 2.0 by changing the version in the buildscript.dependencies section of your build.gradle and update your MCP mappings by changing the minecraft.mappings property. Look at the build.gradle of the latest 1.8.9 MDK download to see what you need.

Make sure you're using the latest version, preferably for 1.8.9. Brewing recipes were introduced in 1.8-11.14.2.1440.

If you're using 1.8+, Forge provides the BrewingRecipeRegistry class that allows you to add brewing recipes. If you're not, update. Simply call one of the BrewingRecipeRegistry.addRecipe overloads to add a recipe, they all have doc comments explaining their inputs.

If you look for usages of the Blocks.bedrock field, you'll see that it's used in BiomeGenBase#generateBiomeTerrain . This is called from BiomeGenBase#genTerrainBlocks , which is called from ChunkProviderGenerate#replaceBlocksForBiome . Each biome generates its own terrain (including bedrock) from this method.