[1.8.9] Inventory Persistence after Breaking Block [Solved]

[lynchiem]

Hi All,

 

I am an experience developer, but very new to mod development (enjoying it a lot though!), so please bear with me. Any help you can offer would be extremely appreciated.

 

I am trying to build a portable chest, and item that you can place in the world and use like a chest, but that you can also "pick up" (return to player inventory) and move around without the chest losing its inventory.

 

I have the item working as a chest perfectly. When I put items in the chest, they stay there. Even after quitting. (At least in single player, I haven't got around to server testing yet). In other words, I have figured out enough to know to override [readFromNBT] and [writeToNBT] on my [IInventory].

 

What I am struggling with is how to "pick up" the block and have the inventory retained.

 

I have been able to figure out that if I override [onBlockPlacedBy] and [breakBlock] on my [Block], I have an opportunity access and play around with the [TileEntity] before it is added to/removed from world completely...

 

...but I am really struggling to figure out how to transfer inventory in to an item I can pick up (and that can persist NBT data).

 

I am sure I will figure it out with enough persistence, but figured it would be a good question to jump in to these forums and engage with more experienced folk.

[coolAlias]

Write the TileEntity to a new NBT tag compound and then add that compound to the ItemStack that is dropped in #dropBlockAsItemWithChance.

 

Then in #onBlockPlacedBy, you have the ItemStack used to place the block - fetch the NBT tag back and pass it to your TileEntity's #readFromNBT method.

[lynchiem]

Thank you very much coolAlias. I will give it a shot.

[lynchiem]

Thank you again coolAlias, your advice has put me well and truly on the path to a solution.

 

I am still having a few quirks (it seems temperamental moving to a new location), but I am fairly certain this will have something to do with copying more NBT than I need to, or maybe just a weird synchronicity bug...

 

...but it is definitely a massive step forward, and I am confident I can nut out the rest.

 

I have provided the solution so far below for the future curious (sans the bulk of some safety and sanity checks for brevity).

 

I did have some difficulty accessing the TileEntity from the dropBlockAsItemWithChance function, which I will continue to investigate, but I was able to take your advice more broadly to arrive at this solution (after learning a little about EntityItems).

 

Firstly, I disabled the default drop behaviour:

 

    @Override
    public void dropBlockAsItemWithChance(World worldIn, BlockPos pos, IBlockState blockState, float chance, int fortune)
    {
    	// Disable super to prevent standard drop.
    	// super.dropBlockAsItemWithChance(worldIn, pos, blockState, chance, fortune);
    }

 

Then I captured the NBT data as suggested, but in the breakBlock function, which seems to have cleaner access to the TileEntity.

 

    @Override
    public void breakBlock(World world, BlockPos pos, IBlockState blockState)
    {   	
        NBTTagCompound tag = new NBTTagCompound();
    	
    	TileEntity blockTileEntity = world.getTileEntity(pos);
    	blockTileEntity.writeToNBT(tag);
    	
    	ItemStack blockItem = new ItemStack(Item.getItemFromBlock(this), 1, this.damageDropped(blockState));
    	
    	EntityItem entityitem = new EntityItem(world, pos.getX(), pos.getY(), pos.getZ(), blockItem);
    	entityitem.getEntityItem().setTagCompound(tag);
   
    	world.spawnEntityInWorld(entityitem);  
        
        super.breakBlock(world, pos, blockState);
    }

 

And lastly I write the NBT back to the chest as I place it (this is where the quirks currently reside - but quirks aside it works).

 

    @Override
    public void onBlockPlacedBy(World world, BlockPos pos, IBlockState blockState, EntityLivingBase entityliving, ItemStack itemStack)
    {              
        TileEntity blockTileEntity = world.getTileEntity(pos);
        if (blockTileEntity != null && blockTileEntity instanceof TileEntityPortableChest)
        {
        	TileEntityPortableChest chestTileEntity = (TileEntityPortableChest)blockTileEntity;
            chestTileEntity.wasPlaced(entityliving, itemStack);
            
            if(itemStack.hasTagCompound())
            {
            	NBTTagCompound tag = itemStack.getTagCompound();
            	
            	chestTileEntity.readFromNBT(tag); 
            }
            
            world.markBlockForUpdate(pos);
        }
    }

[coolAlias]

One possible reason for the 'quirks', as you describe it, is that TileEntities also store their BlockPos in NBT, so while calling those methods on the TE is a handy way to transfer data, it also means you may be transferring some data you shouldn't be.

 

You can probably get around that easily by re-setting the block position after reading the TileEntity from NBT, but there could be other things going on, too.

 

Also, you probably don't need to mark the block for an update unless you have data in your TileEntity that is required for rendering.

[lynchiem]

One possible reason for the 'quirks', as you describe it, is that TileEntities also store their BlockPos in NBT, so while calling those methods on the TE is a handy way to transfer data, it also means you may be transferring some data you shouldn't be.

 

You can probably get around that easily by re-setting the block position after reading the TileEntity from NBT, but there could be other things going on, too.

 

Thank you I presumed it would be something like this, though I hadn't yet thought of a way to tackle it.

 

Also, you probably don't need to mark the block for an update unless you have data in your TileEntity that is required for rendering.

 

Handy to know, though in this case I do have some data that is required for rendering as I have a orientation based texture.