Choonster

Then I'm not too sure what's going on. The log should report any missing/invalid textures or models, but I can't see any errors in it. Could you upload your code to a site like GitHub/BitBucket and link it here? Create the Git repository in your mod's root directory (where build.gradle and src are) and use a gitignore file like this one (the first two lines ignore everything, the rest unignore the files we actually want in the repository).

No, just fix the syntax error.

There's no point in creating an instance yourself and assigning it to the field, FML will always overwrite it with an instance created from the @SidedProxy annotation.

You can subscribe to LivingSpawnEvent.CheckSpawn and set the result to DENY to prevent a passive mob spawn. This isn't fired for mobs spawned from a mob spawner. You'll probably want to maintain a list of locations that have this block using World Saved Data and iterate through them to check whether any are in range to prevent the spawn in your event handler.

Did you try looking at line 192 of BiomeGenBase to see what could be throwing the exception? I suspect it's being thrown because you used an ID of 765, but the BiomeList.biomeList array (where every biome is stored using its ID as the index) is only 256 long.

Call RegistryNamespaced#getNameForObject on Item.itemRegistry to get the name of an Item .

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.