Choonster

There is always a log, even when nothing goes wrong. Upload the FML log (logs/fml-client-latest.log) to Gist and link it here.

RedChestBlock#createTileEntity creates a new CrateTileEntity , not a RedChestTileEntity . Side note: The standard naming convention used by MCP (in vanilla code) and most mods is to have the parent class as a prefix rather than a suffix (e.g. TileEntityRedChest , not RedChestTileEntity ). I'd recommend following this convention, though it's not required.

RedChestBlock#createTileEntity creates a new CrateTileEntity , not a RedChestTileEntity . Side note: The standard naming convention used by MCP (in vanilla code) and most mods is to have the parent class as a prefix rather than a suffix (e.g. TileEntityRedChest , not RedChestTileEntity ). I'd recommend following this convention, though it's not required.

If you're just recolouring a greyscale texture with a single colour, you don't need to generate a texture. Simply override Block#getBlockColor , Block#getRenderColor and Block#colorMultiplier . If the colour should be determined at runtime, store it in a field.

If you're just recolouring a greyscale texture with a single colour, you don't need to generate a texture. Simply override Block#getBlockColor , Block#getRenderColor and Block#colorMultiplier . If the colour should be determined at runtime, store it in a field.

See this thread.

See this thread.

You never initialise the myStacks field. You also never read it from or write it to NBT, do this using the INBTSerializable methods implemented by ItemStackHandler . I suggest you remove the ItemStack array field and the IInventory methods.

You never initialise the myStacks field. You also never read it from or write it to NBT, do this using the INBTSerializable methods implemented by ItemStackHandler . I suggest you remove the ItemStack array field and the IInventory methods.

I think this is caused by your getMetaFromState method. Metadata should simply be radius - 1.

I think this is caused by your getMetaFromState method. Metadata should simply be radius - 1.

Don't implement IItemHandler on your TileEntity , create a field storing an implementation of it (e.g. ItemStackHandler ) and expose it as a capability (by overriding the ICapabilityProvider methods inherited by TileEntity ). I do this in [url=https://github.com/Choonster/TestMod3/blob/d326040ffd81cf942de5ddaebc9c5ed866f1dd33/src/main/java/com/choonster/testmod3/tileentity/TileEntityItemHandler.java]TileEntityItemHandler[/url] .

Don't implement IItemHandler on your TileEntity , create a field storing an implementation of it (e.g. ItemStackHandler ) and expose it as a capability (by overriding the ICapabilityProvider methods inherited by TileEntity ). I do this in [url=https://github.com/Choonster/TestMod3/blob/d326040ffd81cf942de5ddaebc9c5ed866f1dd33/src/main/java/com/choonster/testmod3/tileentity/TileEntityItemHandler.java]TileEntityItemHandler[/url] .

Yes, the class I linked does that. IRecipe#getRecipeOutput returns the recipe's output, but each recipe type has a separate way to get the input.

Yes, the class I linked does that. IRecipe#getRecipeOutput returns the recipe's output, but each recipe type has a separate way to get the input.

Override Block#getBlockLayer to return CUTOUT or TRANSPARENT . The Grey Ghost explains each layer here. Block#isOpaqueCube is used by Block#doesSideBlockRendering / Block#shouldSideBeRendered to determine whether the faces of adjacent blocks should be rendered (opaque blocks block rendering, transparent blocks don't).

I have a class that replaces vanilla/Forge recipes here, though it's for 1.7.10. Each recipe class needs to be handled individually and I specifically prevent it from replacing subclasses because they may have their own custom behaviour.

I have a class that replaces vanilla/Forge recipes here, though it's for 1.7.10. Each recipe class needs to be handled individually and I specifically prevent it from replacing subclasses because they may have their own custom behaviour.

I can't see any obvious errors in your code, try stepping through the IInventory methods or the NBT reading/writing methods in a debugger and see if anything goes wrong. Side note: You shouldn't be using IInventory in 1.8.9+, you should be using the IItemHandler capability. I have an example of a chest that uses IItemHandler here (all other classes used are in the same repository). This includes the naming and loot generation features of vanilla chests, but not the animated model. You also shouldn't be using the deprecated GameRegistry.registerBlock or registering your blocks in init. Use GameRegistry.register in preInit to register all IForgeRegistryEntry implementations (e.g. Block , Item , Biome , SoundEvent ). This won't register an ItemBlock for your Block , you need to do that yourself.

I can't see any obvious errors in your code, try stepping through the IInventory methods or the NBT reading/writing methods in a debugger and see if anything goes wrong. Side note: You shouldn't be using IInventory in 1.8.9+, you should be using the IItemHandler capability. I have an example of a chest that uses IItemHandler here (all other classes used are in the same repository). This includes the naming and loot generation features of vanilla chests, but not the animated model. You also shouldn't be using the deprecated GameRegistry.registerBlock or registering your blocks in init. Use GameRegistry.register in preInit to register all IForgeRegistryEntry implementations (e.g. Block , Item , Biome , SoundEvent ). This won't register an ItemBlock for your Block , you need to do that yourself.

EntityLivingBase#getItemStackFromSlot

EntityLivingBase#getItemStackFromSlot

In 1.9, block/block defines the standard display transformations for block models. This is extended by all full cube models (e.g. block/cube and block/cube_all ). Similarly, item/generated extends builtin/generated and defines the standard display transformations for simple item models. You only need to define display transformations yourself when your model has a custom shape or you want it to be displayed differently to normal models.

In 1.9, block/block defines the standard display transformations for block models. This is extended by all full cube models (e.g. block/cube and block/cube_all ). Similarly, item/generated extends builtin/generated and defines the standard display transformations for simple item models. You only need to define display transformations yourself when your model has a custom shape or you want it to be displayed differently to normal models.

As it says in the error message, it's using the JAVA_HOME environment variable; not PATH . Set this to your JDK path.