Choonster

Your init method is still handling FMLPreInitializationEvent Your ClientProxy#renderRegisterBlock method is using a hardcoded model name, so every block you register with it will use the same model. You're also creating a new Item to access the static method Item.getItemFromBlock , this makes no sense.

Yes, you should call them in the preInit phase from your @Mod class. If you don't call them anywhere, how do you expect the biomes to be registered?

The idea { module { inheritOutputDirs = true; } } line hasn't been required since this commit in ForgeGradle 2.0.

Your MyModBase.init method actually handles FMLPreInitializationEvent instead of FMLInitializationEvent , so it's being called in the preInit phase rather than init. The RenderItem instance is only created between preInit and init, so you can't use it in preInit. I highly suggest using ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition instead of the ItemModelMesher#register overloads. You should also use the sided proxy system (i.e. @SidedProxy ) instead of checking the event's side.

Does your block have an item model? If you name your block's item model the same as the block's registry name, it will automatically be loaded without having to be registered manually. Please post the FML log (from logs/fml-client-latest.log, not your IDE's console), it will almost certainly tell you what went wrong.

You can try using a single texture with both greyscale and pre-coloured parts, but I'm not sure it would work properly (I don't know much about OpenGL). If that doesn't work, you'll need to separate the greyscale and pre-coloured parts into separate textures and render your item in multiple passes. Override the following methods: Item#requiresMultipleRenderPasses to return true Item#getRenderPasses to return the number of render passes you need (only if you need more than 2) Item#getIconFromDamageForRenderPass to return the appropriate IIcon for the render pass Item#getColorFromItemStack to return the appropriate colour for the render pass (or return the super method's result for no colour)

Again, the error tells you exactly what went wrong and which file it looked for. There's no model at the location minecraft:models/block/unstable_ore.json ( minecraft is the default resource domain if you don't specify one), presumably there is one in the at that path in the um resource domain.

If you have a greyscale texture, you can override Item#getColorFromItemStack(ItemStack stack, int renderPass) to colour it at runtime.

Your block model still has the same problem as before. You've used an invalid texture path in your model. Your resource domain is um (your mod ID), not items/um . The path of the texture (relative to assets/um/textures) is items/unstable_metal.png , not just unstable_metal.png . Use um:items/unstable_metal.png as the texture path. The log is telling you exactly what's wrong, you just need to read it.

TooMuchTNT is trying to load a client-only class on the server. Report this to the author.

You can achieve this by emulating key presses from ClientTickEvent (you'll probably want the PRE phase). Call KeyBinding.onTick with a key code to press that key for one tick. KeyBinding#getKeyCode returns the key code of a key binding, vanilla key bindings are stored in the GameSettings instance (the Minecraft#gameSettings field).

You didn't post the FML log. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). It's much easier to read code with syntax highlighting.

Are you definitely calling BiomeRegistry.init and BiomeRegistry.register ? Override BiomeGenBase#genTerrainBlocks to call the super method and put a breakpoint in it. When the breakpoint is hit, take note of the x and z coordinates.

Post the new FML log and all of the affected models using Gist.

Managing an owner like this could be a potential use-case for the new Capability system.

IBlockState s are converted to and from their IDs using Block.BLOCK_STATE_IDS . This is populated each time a Block is registered: The registry iterates through all of the possible states and adds each one to the map using blockId << 4 | block.getMetaFromState(state) as the ID. If multiple states share an ID, whichever one was added last will be returned from ObjectIntIdentityMap#getByValue .

Minecraft uses Netty to send data between the client and server. Netty doesn't know how to send complex objects like IBlockState s over the network and recreate them on the other side, so they need to be broken down into simpler types that Netty does know about (this is a similar concept to storing data in NBT, both are forms of serialisation). In this case Minecraft sends the ID of the IBlockState , which is just an int derived from the Block 's ID and the state's metadata.

I'm not an expert on log4j, but I don't think it's possible to configure an individual Logger . You can include a log4j config file in your mod, but this overwrites the existing configuration provided by Forge.

I'm pretty sure that doc comment is outdated, the method that loads logging configuration files was removed when Minecraft and Forge/FML switched to log4j from Java's Logging API.

This page explains the block model format. For a full cube model with a single texture, just use minecraft:block/cube_all as the parent and set the all texture.

The error tells you exactly what's wrong: Your block model has no elements or parent and your item model has a syntax error.

Post the full error message or upload the full FML log to Gist and link it here.

CodeChickenCore doesn't support 1.8.9.

You need to check that the state's Block ( IBlockState#getBlock ) is Blocks.log , then use IBlockState#getValue to get the value of the BlockOldLog.VARIANT property. If it's BlockPlanks.EnumType.SPRUCE , the log is a Spruce log.

Mojang's Minecraft launcher comes with its own JRE (Java Runtime Environment, the program that actually runs Java code), it doesn't rely on you having Java installed system-wide. I suspect you actually did have Java installed, it just wasn't set as the default program for JAR files. Forge's Windows installer bypasses this by being an EXE (Windows executable) that launches Java itself instead of relying on you to open it with Java. Once a launcher is running, it also knows how to launch Java itself when you run Minecraft.