[SOLVED][1.8]Changing block state from tile entity is causing problems

[jabelar]

Okay, so I'm making a simple "machine" block that is a tanning rack and converts hides (a custom item) into leather.  I am pretty confident in making container blocks with tile entities, but this time I thought I'd try to be fancy with the 1.8 models and have it so that the texture changes based on the progress of the tanning.  So I created a boolean property for the block called TANNING_COMPLETE and I was hoping that I could simply have my tile entity update the property value depending on what is happening in the associated inventory. 

 

So I thought I could just set the block state from the tile entity's update method.  The problem is that when I try to update the block state, it seems that it is actually replacing the whole block (and associated tile entity) since it (a) exits the GUI, (b) drops everything that was in the inventory.

 

So I guess I'm using the wrong method to set the state of the block.  I think I need a way to change the state without trigging a block replacement.

 

The code I have been using:

    public static void changeBlockBasedOnTanningStatus(boolean parTanningComplete, World parWorld, BlockPos parBlockPos)
    {
        parWorld.setBlockState(parBlockPos, BlockSmith.blockTanningRack.getDefaultState().withProperty(TANNING_COMPLETE, parTanningComplete));
    }

 

What is the proper way to just change a block property value without disrupting the block or associated tile entity?

 

EDIT: Looking at BlockFurnace's func_176446_a() it seems that they actually have to re-associate the tile entity to the position.  Is that the way to do it?

[jabelar]

There is a forge hook specifically for this: shouldRefresh in your TE. That determines if the TileEntity is re-created when the blockState changes (this has been so ever since btw.).

 

Thanks.  I think the reason I'm encountering this now is that previously if I had blocks with tile entities, I didn't tend to use metadata but rather used fields in the tile entity.  Now since the 1.8 block properties are so directly tied to models through the JSON, it seemed more appropriate to go the route of having the state kept in the block state rather than as a tile entity field.