Choonster

First, delay the removal of the TileEntity until after Block#getDrops has been called (see Forge's patches to BlockFlowerPot for an example of this. Then override Block#getDrops to call the super method, add the inventory contents to the returned list and then return the list. I do this for my chest here, here and here. This splits the stacks randomly to mimic the InventoryHelper.dropInventoryItems method used by vanilla inventories.

First, delay the removal of the TileEntity until after Block#getDrops has been called (see Forge's patches to BlockFlowerPot for an example of this. Then override Block#getDrops to call the super method, add the inventory contents to the returned list and then return the list. I do this for my chest here, here and here. This splits the stacks randomly to mimic the InventoryHelper.dropInventoryItems method used by vanilla inventories.

Read the stacktrace, something was null on line 16 of TileEntityHolyStone . If you can't figure out what was null , set a breakpoint in the method and step through it in a debugger.

Read the stacktrace, something was null on line 16 of TileEntityHolyStone . If you can't figure out what was null , set a breakpoint in the method and step through it in a debugger.

How are we meant to know what the problem is now if you don't post the new log?

How are we meant to know what the problem is now if you don't post the new log?

It looks like AnimationAPI is trying to access a client-only class on the server, this is an error. Make sure you're using the latest version, then report this to the author if it persists. They may or may not be making fixes in 1.7.10 at this point.

It looks like AnimationAPI is trying to access a client-only class on the server, this is an error. Make sure you're using the latest version, then report this to the author if it persists. They may or may not be making fixes in 1.7.10 at this point.

I don't quite understand. The writeToNBT method in the TileEntity super class returns void, and there is no eventReceived method in the Block class... I think you're using 1.9, not 1.9.4 as your title says. The changes I mentioned were made in 1.9.4. The OP is doing this in their latest code.

I don't quite understand. The writeToNBT method in the TileEntity super class returns void, and there is no eventReceived method in the Block class... I think you're using 1.9, not 1.9.4 as your title says. The changes I mentioned were made in 1.9.4. The OP is doing this in their latest code.

I copied your code into a fresh 1.9.4-12.17.0.1922-1.9.4 MDK, updated it to 1.9.4 (made TileEntityRedChest#writeToNBT return NBTTagCompound , renamed BlockRedChest#onBlockEventReceived to eventReceived and CreativeTabs.tabBlock to [TT]CreativeTabs.BUILDING_BLOCKS[/TT]) and hoppers could put items in and take items out without issue.

I copied your code into a fresh 1.9.4-12.17.0.1922-1.9.4 MDK, updated it to 1.9.4 (made TileEntityRedChest#writeToNBT return NBTTagCompound , renamed BlockRedChest#onBlockEventReceived to eventReceived and CreativeTabs.tabBlock to [TT]CreativeTabs.BUILDING_BLOCKS[/TT]) and hoppers could put items in and take items out without issue.

That's the correct log, but I can't see any obvious errors.

That's the correct log, but I can't see any obvious errors.

TileEntitySpecialRenderer Use World#getBlockState to get the current state and IBlockState#getValue to get the facing from that state.

TileEntitySpecialRenderer Use World#getBlockState to get the current state and IBlockState#getValue to get the facing from that state.

That's not the full FML log. Upload the file called fml-client-latest.log in the logs folder of your Minecraft directory to Gist and link it here.

That's not the full FML log. Upload the file called fml-client-latest.log in the logs folder of your Minecraft directory to Gist and link it here.

Nobody said anything about crash reports. We want the FML log.

Nobody said anything about crash reports. We want the FML log.

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.

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.