Choonster

1.8.8 added generics to vanilla code. The OP has the correct method signatures. Edit: The title says 1.8.9, but the OP is actually using 1.8; so there aren't any generics.

I thought I did, but it doesn't seem to be a valid import; Eclips says that " The import org.apache cannot be resolved " I suggest running gradlew setupDecompWorkspace eclipse again to set up the ForgeGradle workspace and recreate the Eclipse project.

If you've set up your ForgeGradle workspace and IDE properly, you should already have log4j as a dependency. Just delete the java.util.logging.Logger import and replace it with a org.apache.logging.log4j.Logger import.

Minecraft uses log4j ( org.apache.logging.log4j.Logger ), not java.util.logging.Logger .

I'm pretty sure this is OptiFine screwing things up. OptiFine is only compatible with specific versions of Forge, but I can't see which version of Forge is needed by OptiFine 1.8 HD U C7. Side note: OptiFine has a very confusing version numbering system.

Create a model that extends ModelBiped and override Item#getArmorModel to return an instance of it.

Could you or cpw advise me if my code (in the OP) is correct? Edit: Fixed typo.

Minecraft only loads one model per item by default, the name of this model is the item's registry name (the name passed to GameRegistry.registerItem or Item#setRegistryName ). If you want to load a different model or multiple models, you need to call ModelBakery.registerItemVariants with the locations of those models. I would highly recommend using Forge's ModelLoader.setCustomModelResourceLocation and ModelLoader.setCustomMeshDefinition methods in preInit instead of the vanilla ItemModelMesher#register overloads in init. ModelLoader.setCustomModelResourceLocation will call ModelBakery.registerItemVariants with the model location for you. I would also recommend setting the registry names of your items with Item#setRegistryName and registering them with GameRegistry.registerItem(Item) . You can get an item's registry name in the "modid:name" format from Item#getRegistryName . This also applies to blocks. I have a whole bunch of model registration code for my item models here. I use Forge's blockstates format and Java 8 features quite a lot in my mod.

OreDictionary.OreRegisterEvent is fired when an item is registered with the Ore Dictionary.

This is true of the vanilla IBlockState implementation as well, it's immutable.

Upload the FML log (logs/fml-client-latest.log) to Gist and link it here.

EntityJoinWorldEvent is fired when an entity is spawned in the world. You can cancel it to prevent the entity from spawning.

Have you considered extending Entity instead of EntityLiving ? It doesn't seem like your entity is a living entity with AI, equipment, etc. I'm not entirely sure, but I think EntityLivingBase / EntityLiving may apply downward motion to any entity not on the ground.

Don't create new Item instances outside of the initial loading process. Each Item should be instantiated and registered once in preInit.

I think that's just how BlockFluidFinite flows. If you want a fluid that flows like the vanilla liquids, use BlockFluidClassic .

JARs are just ZIPs with a different extension and some metadata files.

If you override the method, make sure you call the super method. Or just don't override it.

The exception is being thrown because it's trying to update an object (the entity's health, index 6) that doesn't exist in the DataWatcher . This is added in EntityLivingBase#entityInit , but you've overridden this to do nothing.

It's possible that your world is corrupt. Does it work if you create a new world and load that?

Post the crash report.

Unless the list exists in vanilla, you'll need to use your own packet. Forge's Read the Docs site has a section on networking (including the Simple Network Implementation, which you should use) here.

Thanks, that was indeed the issue. Vanilla sets this for its own slabs, but this is done in Block.registerBlocks before mods are loaded. You'd think it would do this in the constructor of the appropriate classes. My slabs now render properly. Edit: You can see the working code here: BlockSlabTestMod3, BlockColouredSlab

You have a coremod built for 1.8+ installed (OpenComputers).

Haha, no worries. I tried manually specifying the up , down and side textures (the textures used by the slab models) but nothing changed. I also tried using the vanilla blockstates format with a vanilla model and the issue persisted, so I suspect it's something to do with the Block rather than the model.

My slabs aren't transparent, they use solid textures on a model that doesn't occupy the whole block. I did try returning each layer from Block#getBlockLayer , but nothing changed. Block#getRenderType already returns 3 and neither BlockSlab or my slab classes override it.