Choonster

eAngelusCards#onItemUse (called when the item is right clicked on a block) tries to instantiate one of the card Item s using a constructor that takes a World argument, but O_card_Fire doesn't have this constructor. It also never calls a method on this new instance. eAngelusCards doesn't override Item#onPlayerStoppedUsing , so it does nothing when the player stops using it. It also has several override methods without @Override , you should always use this annotation so the compiler ensures that the methods actually override a super method. That said, your design is a mess. You shouldn't be creating Item s on the fly or using Item s that haven't been registered. What you should do is create a Card class with all the necessary methods and then have each card type extend this and override the appropriate methods to implement their functionality. You should then have a single card Item that stores an instance of each card type and overrides various Item methods to call the corresponding Card method. If you wanted to make this system more extendable, you could create a registry for Card s using Forge's registry system ( IForgeRegistry / IForgeRegistryEntry ) and store the card type in either the NBT (as its registry name) or in a Capability of the ItemStack . Edit: Fixed the formatting.

getTileEntity is a method from the BlockTileEntity class extended by BlockModChest , it's not a vanilla method. It is just a wrapper around World#getTileEntity though. BlockRedChest has a copy of this method, did it not work? That doesn't tell me much. What actually happens? Side note: BlockRedChest#removedByPlayer is missing the @Override annotation, I suggest you add it so the compiler ensures that it actually is an override method.

getTileEntity is a method from the BlockTileEntity class extended by BlockModChest , it's not a vanilla method. It is just a wrapper around World#getTileEntity though. BlockRedChest has a copy of this method, did it not work? That doesn't tell me much. What actually happens? Side note: BlockRedChest#removedByPlayer is missing the @Override annotation, I suggest you add it so the compiler ensures that it actually is an override method.

Post your code and the FML log (preferably using Gist), which should contain some indication as to what's going wrong. You should be using Forge's ModelLoader.setCustomModelResourceLocation (for metadata-based models) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mappings) methods in preInit rather than ItemModelMesher#register in init.

Post your code and the FML log (preferably using Gist), which should contain some indication as to what's going wrong. You should be using Forge's ModelLoader.setCustomModelResourceLocation (for metadata-based models) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mappings) methods in preInit rather than ItemModelMesher#register in init.

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.