...made TileEntityRedChest#writeToNBT return NBTTagCompound, renamed BlockRedChest#onBlockEventReceived to eventReceived...

 

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...

 

 

super() only handles the basic TE info.  You need to call myStacks.writeToNBT()

Or the capability.writeToNTB()

I haven't poked 1.9 yet.

super() only handles the basic TE info.  You need to call myStacks.writeToNBT()

Or the capability.writeToNTB()

I haven't poked 1.9 yet.

...made TileEntityRedChest#writeToNBT return NBTTagCompound, renamed BlockRedChest#onBlockEventReceived to eventReceived...

 

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.

 

super() only handles the basic TE info.  You need to call myStacks.writeToNBT()

Or the capability.writeToNTB()

I haven't poked 1.9 yet.

The OP is doing this in their latest code.

...made TileEntityRedChest#writeToNBT return NBTTagCompound, renamed BlockRedChest#onBlockEventReceived to eventReceived...

 

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.

 

super() only handles the basic TE info.  You need to call myStacks.writeToNBT()

Or the capability.writeToNTB()

I haven't poked 1.9 yet.

The OP is doing this in their latest code.

I think you're using 1.9, not 1.9.4 as your title says.

 

You're absolutely right! I switched to 1.9.4, and did the changes you recommended, and now the block holds items via hopper.

 

I have one more question though.  Do you have any advise on how I can set the block up such that it will drop the stored items upon destruction?

I think you're using 1.9, not 1.9.4 as your title says.

 

You're absolutely right! I switched to 1.9.4, and did the changes you recommended, and now the block holds items via hopper.

 

I have one more question though.  Do you have any advise on how I can set the block up such that it will drop the stored items upon destruction?

I have one more question though.  Do you have any advise on how I can set the block up such that it will drop the stored items upon destruction?

 

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.

I have one more question though.  Do you have any advise on how I can set the block up such that it will drop the stored items upon destruction?

 

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.

So I added the code into my own, though I had to do some editing, since the getTileEntity(world, pos) no longer accepted those parameters.  The program does not work as expected.

 

Here's the TileEntityRedChest class:

 

http://pastebin.com/WucCAgcy

 

And the BlockRedChest class:

 

http://pastebin.com/cXUjshQ6

 

And finally the Chest (Main) class:

 

http://pastebin.com/BgSudHca

So I added the code into my own, though I had to do some editing, since the getTileEntity(world, pos) no longer accepted those parameters.  The program does not work as expected.

 

Here's the TileEntityRedChest class:

 

http://pastebin.com/WucCAgcy

 

And the BlockRedChest class:

 

http://pastebin.com/cXUjshQ6

 

And finally the Chest (Main) class:

 

http://pastebin.com/BgSudHca

So I added the code into my own, though I had to do some editing, since the getTileEntity(world, pos) no longer accepted those parameters.

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?

 

The program does not work as expected.

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.

So I added the code into my own, though I had to do some editing, since the getTileEntity(world, pos) no longer accepted those parameters.

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?

 

The program does not work as expected.

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?

 

No, since the world variable in the getDrops method is of type IBlockAccess, and not of the World type, which is what the BlockRedChest#getTileEntity method takes as a parameter. 

 

The program does not work as expected.

That doesn't tell me much. What actually happens?

 

Sorry for the lack of clarity.  The block takes the items from the hopper, but upon destruction, does not drop them.

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?

 

No, since the world variable in the getDrops method is of type IBlockAccess, and not of the World type, which is what the BlockRedChest#getTileEntity method takes as a parameter. 

 

The program does not work as expected.

That doesn't tell me much. What actually happens?

 

Sorry for the lack of clarity.  The block takes the items from the hopper, but upon destruction, does not drop them.

No, since the world variable in the getDrops method is of type IBlockAccess, and not of the World type, which is what the BlockRedChest#getTileEntity method takes as a parameter. 

Ah, my version of the method takes an

IBlockAccess

argument.

 

Sorry for the lack of clarity.  The block takes the items from the hopper, but upon destruction, does not drop them.

I can't see any obvious issues. I suggest you step through the code in a debugger.

No, since the world variable in the getDrops method is of type IBlockAccess, and not of the World type, which is what the BlockRedChest#getTileEntity method takes as a parameter. 

Ah, my version of the method takes an

IBlockAccess

argument.

 

Sorry for the lack of clarity.  The block takes the items from the hopper, but upon destruction, does not drop them.

I can't see any obvious issues. I suggest you step through the code in a debugger.

I solved it!  I kept destroying the block with my fists in creative mode, which is why nothing dropped.  However, when I harvested it using an axe, then the items stored in the block were dropped as expected.

I solved it!  I kept destroying the block with my fists in creative mode, which is why nothing dropped.  However, when I harvested it using an axe, then the items stored in the block were dropped as expected.