[1.10.2] Tile Entity not saving/loading data

[Nomnomab]

Ok so, I can successfully set data on my TileEntity for my ModelTanningRack, but for some reason if I reload the world, the data is not loaded up at all and only reset. 

 

My TileEntity:

public class Tile4PieceVerticalBlock extends TileEntity implements ITickable {

    private boolean isMaster, hasMaster;
    private int masterX, masterY, masterZ;

    // reset info when master is gone
    public void reset(){
        masterX = masterY = masterZ = 0;
        isMaster = hasMaster = false;
    }

    // check that the master exists
    public boolean checkForMaster(){
        TileEntity tile = worldObj.getTileEntity(getMasterPos());
        return (tile != null && (tile instanceof Tile4PieceVerticalBlock));
    }

    @Override
    public NBTTagCompound writeToNBT(NBTTagCompound compound) {

        System.out.println("WRITE:" + getMasterPos() + "\n");

        compound.setInteger("masterX", masterX);
        compound.setInteger("masterY", masterY);
        compound.setInteger("masterZ", masterZ);

        compound.setBoolean("isMaster", isMaster);
        compound.setBoolean("hasMaster", hasMaster);

        super.writeToNBT(compound);

//        if(hasMaster() && isMaster()){
//            masterWriteToNBT(compound);
//        }

        return compound;
    }

    @Override
    public void readFromNBT(NBTTagCompound compound) {

        this.masterX = compound.getInteger("masterX");
        this.masterY = compound.getInteger("masterY");
        this.masterZ = compound.getInteger("masterZ");

        this.isMaster = compound.getBoolean("isMaster");
        this.hasMaster = compound.getBoolean("hasMaster");

        super.readFromNBT(compound);

        System.out.println("READ:" + getMasterPos() + "\n");

//        if(hasMaster() && isMaster()){
//            masterReadToNBT(compound);
//        }
    }

    public boolean hasMaster(){
        return hasMaster;
    }

    public boolean isMaster(){
        return isMaster;
    }

    public int getMasterX(){
        return masterX;
    }

    public int getMasterY(){
        return masterY;
    }

    public int getMasterZ(){
        return masterZ;
    }

    public BlockPos getMasterPos(){
        return new BlockPos(getMasterX(), getMasterY(), getMasterZ());
    }

    public void setHasMaster(boolean bool){
        hasMaster = bool;
    }

    public void setIsMaster(boolean bool){
        isMaster = bool;
        hasMaster = bool;
    }

    public void setMasterPos(int x, int y, int z){
        masterX = x;
        masterY = y;
        masterZ = z;
        setHasMaster(true);
    }

    public int xCoord(){
        return pos.getX();
    }

    public int yCoord(){
        return pos.getY();
    }

    public int zCoord(){
        return pos.getZ();
    }

    @Override
    public void update() {

    }
}

 

Any ideas? (I could very well be missing something)

[Nomnomab]

  On 6/16/2017 at 9:59 PM, diesieben07 said:

What makes you think the data is not loaded? What are the symptoms?

Expand  

Considering when I debug before I reload the world, it contains the data I set. But then when I reload the world and then debug, the data is completely reset. (I debug through onBlockActivated btw to do quick checks)

[Nomnomab]

  On 6/17/2017 at 12:17 AM, diesieben07 said:

Show that code.

Expand  

First off, I am setting the tile entitie's data here:

@Override
    public void onBlockPlacedBy(World worldIn, BlockPos pos, IBlockState state, EntityLivingBase placer, ItemStack stack) {
        System.out.print("BlockMultiTanningRack set in world.\n");

        // set this data
        getTileEntity(worldIn, pos).setIsMaster(true);
        // grab direction
        EnumFacing enumFacing = BlockPistonBase.getFacingFromEntity(pos, placer);
        // grab positions
        BlockPos right = getDirectionalOffset(pos, enumFacing.getIndex(), 1, 0, 0);
        BlockPos topLeft = getDirectionalOffset(pos, enumFacing.getIndex(), 0, 1, 0);
        BlockPos topRight = getDirectionalOffset(pos, enumFacing.getIndex(), 1, 1, 0);
        // set blocks
        worldIn.setBlockState(pos, state.withProperty(FACING, enumFacing).withProperty(PIECE, Enum4Piece.BOTTOMLEFT));
        worldIn.setBlockState(right, ModBlocks.TANNING_RACK.getDefaultState().withProperty(FACING, enumFacing).withProperty(PIECE, Enum4Piece.BOTTOMRIGHT));
        worldIn.setBlockState(topLeft, ModBlocks.TANNING_RACK.getDefaultState().withProperty(FACING, enumFacing).withProperty(PIECE, Enum4Piece.TOPLEFT));
        worldIn.setBlockState(topRight, ModBlocks.TANNING_RACK.getDefaultState().withProperty(FACING, enumFacing).withProperty(PIECE, Enum4Piece.TOPRIGHT));
        // set tiles
        Tile4PieceVerticalBlock rightEntity = (Tile4PieceVerticalBlock)createTileEntity(worldIn, state);
        Tile4PieceVerticalBlock topLeftEntity = (Tile4PieceVerticalBlock)createTileEntity(worldIn, state);
        Tile4PieceVerticalBlock topRightEntity = (Tile4PieceVerticalBlock)createTileEntity(worldIn, state);
        // set masters
        rightEntity.setMasterPos(pos.getX(), pos.getY(), pos.getZ());
        topLeftEntity.setMasterPos(pos.getX(), pos.getY(), pos.getZ());
        topRightEntity.setMasterPos(pos.getX(), pos.getY(), pos.getZ());
        // set tile in world
        worldIn.setTileEntity(right, rightEntity);
        worldIn.setTileEntity(topLeft, topLeftEntity);
        worldIn.setTileEntity(topRight, topRightEntity);
        super.onBlockPlacedBy(worldIn, pos, state, placer, stack);
    }

 

And then debugging here:

@Override
    public boolean onBlockActivated(World worldIn, BlockPos pos, IBlockState state, EntityPlayer playerIn, EnumHand hand, @Nullable ItemStack heldItem, EnumFacing side, float hitX, float hitY, float hitZ) {

        TileEntity tile = worldIn.getTileEntity(pos);

        if(tile != null && tile instanceof Tile4PieceVerticalBlock) {
            Tile4PieceVerticalBlock tileTanningRack = (Tile4PieceVerticalBlock)tile;

            playerIn.addChatMessage(new TextComponentString("Master = " + tileTanningRack.isMaster() + ", Slave = " + tileTanningRack.hasMaster()));
        }

        return super.onBlockActivated(worldIn, pos, state, playerIn, hand, heldItem, side, hitX, hitY, hitZ);
    }

 

[Nomnomab]

  On 6/17/2017 at 12:44 AM, diesieben07 said:

Never call createTileEntity or setTileEntity yourself.

Only check the data on the server, not both sides.

Expand  

Then how would you suggest I do this?

[draganz]

Place the block, if the block does have an associated tile entity, then use the world to get the tile entity, then use a setter method in the tile entity to set the value. So get rid of the create and setTileEntity calls you have, just get the tile entity from the world and set the specific value; this can be done all in one call (no intermediate reference objects).

[Nomnomab]

  On 6/17/2017 at 1:14 AM, draganz said:

Place the block, if the block does have an associated tile entity, then use the world to get the tile entity, then use a setter method in the tile entity to set the value. So get rid of the create and setTileEntity calls you have, just get the tile entity from the world and set the specific value; this can be done all in one call (no intermediate reference objects).

Expand  

Ah ok, I'll give it a try.

[Nomnomab]

Ok, code is changed correctly for that part. Also, the data seems to save and load properly if I check with !worldIn.isRemote. Am I able to just set the Active State from the Server data? @draganz @diesieben07

[Nomnomab]

  On 6/17/2017 at 7:59 AM, diesieben07 said:

What is the "Active State"? What is "from server data"? 

Expand  

Like, the getActiveState from a block and the "server data" is the tile entity's nonremote data I guess. Not even sure how to go about this haha @diesieben07

[V0idWa1k3r]

TileEntity loading from NBT only happens on server, the client doesn't load anything from any files. The client can only read the data server sends to it. If your tile depends on some data being present on both server and client you need to sync it by overriding getUpdatePacket and getUpdateTag(optional, you only need to do so if you want non-capability related stuff to be synced) to send the data and onDataPacket and handleUpdateTag(most likely you don't need to override this one unless you want to do something more than just reading NBT of the tile) to recieve the data.

  On 6/18/2017 at 1:38 AM, Nomnomab said:

the getActiveState from a block

Expand  

there is no such method as getActiveState. Did you mean getActualState? If you want to get tile's common data from that one on the client you will need to sync the data first.

Edited June 18, 2017 by V0idWa1k3r

[Nomnomab]

  On 6/18/2017 at 8:30 AM, V0idWa1k3r said:

TileEntity loaading from NBT only happens on server, the client doesn't load anything from any files. The client can only read the data server sends to it. If your tile depends on some data being present on both server and client you need to sync it by overriding getUpdatePacket and getUpdateTag(optional, you only need to do so if you want non-capability related stuff to be synced) to send the data and onDataPacket and handleUpdateTag(most likely you don't need to override this one unless you want to do something more than just reading NBT of the tile) to recieve the data.

there is no such method as getActiveState. Did you mean getActualState? If you want to get tile's common data from that one on the client you will need to sync the data first.

Expand  

Ah, thanks I'll try that, and yeah I meant getActualState sorry haha. Been a bit tired recently  

[jeffryfisher]

  On 6/18/2017 at 8:30 AM, V0idWa1k3r said:

TileEntity loading from NBT only happens on server

Expand  

I thought the server sent NBT data to the client, so at some level wouldn't the client load from NBT in response to a packet from the server?

  On 6/18/2017 at 8:30 AM, V0idWa1k3r said:

you need to sync it by overriding getUpdatePacket and getUpdateTag

Expand  

My TE's haven't needed those (yet), but I haven't ported beyond MC 1.10.2. Are they something new? I seem to be getting away with just reading and writing to and from NBT (and marking dirty / for update). The packet mechanism seems to work invisibly in the background (so far). If that stops working in 1.11 or later, then I'm not looking forward to needing explicit packet handling in mods that haven't needed it before.

 

I'll confess that I still have difficulty wrapping my mind around tile-entities. That's why I follow threads like this.

[V0idWa1k3r]

  On 6/18/2017 at 6:35 PM, jeffryfisher said:

I thought the server sent NBT data to the client, so at some level wouldn't the client load from NBT in response to a packet from the server?

Expand  

Well if you put it like that sure, the client can load TE's data from an NBT but I ment from-disk loading

  On 6/18/2017 at 8:30 AM, V0idWa1k3r said:

the client doesn't load anything from any files

Expand  

 

---

 

  On 6/18/2017 at 6:35 PM, jeffryfisher said:

My TE's haven't needed those (yet), but I haven't ported beyond MC 1.10.2. Are they something new? I seem to be getting away with just reading and writing to and from NBT (and marking dirty / for update). The packet mechanism seems to work invisibly in the background (so far). If that stops working in 1.11 or later, then I'm not looking forward to needing explicit packet handling in mods that haven't needed it before.

Expand  

getUpdatePacket and onDataPacket methods have existed for a while, but I can't tell you by how much. By default they do not do anything(onDataPacket is an empty method and getUpdatePacket returns null). They are needed for... erm, I would call it "on-demand tile entity changes". Basically if you look at PlayerChunkMapEntry::update method you will see that this packet gets sent in 2 cases(really it is more like 1 case with a sub-case ):

1. There has been a single change for the ChunkMapEntry involving a tileentity

2. There have been less than ForgeModContainer.clumpingThreshold(64) amount of block changes for the entry. Then every tile that got changed sends this packet.

 

On the other hand, when the chunk data is fully sent to the client(a player loads a chunk) or there are a lot of changes within the chunk entry(>= 64) all tile data gets 'clumped' into a single NBT which is sent. That NBT is composed of TileEntity::getUpdateTag for each tile that gets synced that way. By default TileEntity::getUpdateTag writes tile's X/Y/Z, ID, extra data and all capabilities into the tag and handleUpdateTag simply invokes TileEntity::readFromNBT, thus deserializing all that data. As far as I can tell those are the only conditions for those two methods to be used, as getUpdateTag is only ever called while initializing a new SPacketChunkData packet.

 

The changes are recorded to the chunk entry when the blockChanged method gets called and that gets called from ServerWorldEventHandler::notifyBlockUpdate which is a IWorldEventListener for the server. notifyBlockUpdate gets called when World::notifyBlockUpdate is called, respectively. That for example is called at World::addTileEntity, and under certain conditions when you invoke World::setBlockState. So long story short that keeps chunk data(blocks+tiles) in sync. You pretty much want to override both methods, although due to default implementation getUpdateTag and handleUpdateTag are optional and you might not need to override those.

 

getUpdateTag/handleUpdateTag are for initial sync and big changes. getUpdatePacket/onDataPacket are for "on-demand" sync.

 

  On 6/18/2017 at 6:35 PM, jeffryfisher said:

The packet mechanism seems to work invisibly in the background (so far). If that stops working in 1.11 or later, then I'm not looking forward to needing explicit packet handling in mods that haven't needed it before.

Expand  

You can still let vanilla handle everything. Just make getUpdatePacket return a packet that is your NBT data serialized and onDataPacket simply deserialize the data. After that you can still use World::notifyBlockUpdate/whatever you were using. I've had issues with that method being unreliable sometimes but I was unable to reliably debug it so i'd say that it should be safe to use it.

 

A small disclamer: All that I have written above is something that I was able to trace with the debugger/code inspections, it might not actually be exactly the way things work. I also can't say anything about 1.10.x or lower as I've only started modding at 1.11 (all knowledge I have of previous versions is theoretical) and I do not know if those methods were changed at some point in the past.

[jeffryfisher]

  On 6/18/2017 at 7:04 PM, V0idWa1k3r said:

can't say anything about 1.10.x or lower as I've only started modding at 1.11

Expand  

Aha -- good disclaimer in a 1.10.2 context thread. @Nomnomab will need to be flexible.