[1.8.9][TileEntity] createNewTileEntity returning null slows the game

[Major Squirrel]

Hey boyz (and girls),

 

I'm playing with TileEntity for now, and something is happening when creating a new TileEntity.

 

I'm creating a barrel block that extends BlockContainer : I have to implement createNewTileEntity(World worldIn, int meta). I want to keep the TE logic for the server mod, so I implement all the TE code in the server mod, and in the client mod I'm returning null.

 

When I return null for this method, when the block is placed, the chunk updates increase from 0 to 40 chunk updates constantly ! FPS decrease too (when I destroy the block it will return normal). But when I return an empty TileEntity (just the class + an empty constructor) it works without any problem, why is that ?

[Draco18s]

Don't return null.

[diesieben07]

First of all, do not extend BlockContainer. Simply override hasTileEntity and createTileEntity.

Then, if you choose not to have a TileEntity on the client, make 100% sure that you do not reference it there, ever.

 

Show how you attempted it.

[Major Squirrel]

Here is my attempt

 

I suppose that in client mod I override hasTileEntity to return false and in server mod I override to return true and createTileEntity to return a new TE ?

 

Also, why should I not extend BlockContainer ? I followed GreyGhost and BedrockMiner tutorials but according to you it seems not ok for me.

[diesieben07]

Right now you just always return null. This is bad. BlockContainer tells Minecraft (using hasTileEntity) that your Block has a TileEntity. Always.

If you then return null it will constantly try to create a new TileEntity because your Block says it has one but then doesn't create one.

 

BlockContainer has no uses and produces bad behavior like this.

[Draco18s]

This is why you

Don't return null.

[Major Squirrel]

Yup, I just made the changes you indicate me and it works very well, thank you guys.

 

However, I still have some questions about server updating clients. What is the difference between this :

 

    private void        sendUpdateBarrelTexture() {
        IBlockState     blockState;

        blockState = this.worldObj.getBlockState(this.pos).getBlock().getStateFromMeta(this.currentCycle);
        this.worldObj.setBlockState(this.pos, blockState, 2);
    }

 

and this

 

    private void        sendUpdateBarrelTexture() {
        IBlockState     blockState;

        blockState = this.worldObj.getBlockState(this.pos).getBlock().getStateFromMeta(this.currentCycle);
        this.worldObj.setBlockState(this.pos, blockState);
        this.worldObj.markBlockForUpdate(this.pos);
        this.markDirty();
    }

 

For the first code, especially the setBlockState method, the javadoc says : "sets the block state at a given location. Flag 1 will cause a block update. Flag 2 will send the change to clients (you almost always want this). Flag 4 prevents the block from being re-rendered, if this is a client world. Flags can be added together."

 

In my case, I just want to tell clients that the state of the block has changed (other texture). Currently I'm using the first code, am I wrong doing this ?

[BusyBeever]

MarkDirty() tells minecraft that there have been changes that need to be written to disk when saving the game

[diesieben07]

First of all, you should never be calling getMetaFromState (or getStateFromMeta) yourself.

To the question, both of what you showed is kinda weird.

 

markBlockForUpdate re-sends the chunk data to the client.

markDirty updates comparators and tells minecraft that your TE's data has changed, so it will need to be saved to disk.

[Major Squirrel]

First of all, you should never be calling getMetaFromState (or getStateFromMeta) yourself.

To the question, both of what you showed is kinda weird.

 

markBlockForUpdate re-sends the chunk data to the client.

markDirty updates comparators and tells minecraft that your TE's data has changed, so it will need to be saved to disk.

 

Okay, so it seems that I'm doing something wrong here. I just want to tell players that the block has changed : the this.currentCycle has been incremented and the texture is properly set according to the currentCycle. (that is probably why I should save to disk, isn't it ?) I do not really see how can I change the block state if I don't have to access to getStateFromMeta myself. 

[diesieben07]

You set the block state using world.setBlockState.

[Major Squirrel]

Okay I will try that tomorrow. Thank you And what about updating clients properly ? Should I just set markBlockForUpdate ?

[diesieben07]

If you call setBlockState with flag 2 set it will update the client.

[Major Squirrel]

Just saw that I still need to get a BlockState to set it doing this.worldObj.setBlockstate(...), how could I do if I can't touch to getStateFromMeta ? I've overriden it, this should be ok no ? (take a look at the attempt above)

[diesieben07]

You pass in an IBlockState.

[Choonster]

Use

Block#getDefaultState

to get the default state of a block, then chain

IBlockState#withProperty

calls to get an

IBlockState

with the specified property values.

[Major Squirrel]

I don't see the point not to use my getStateFromMeta method if it is already doing it :

 

    @Override
    public IBlockState                  getStateFromMeta(int meta) {
        return (this.getDefaultState().withProperty(TYPE, EnumType.byMetadata(meta)));
    }

[diesieben07]

The point is you should not ever deal with metadata in your code, except in getStateFromMeta and getMetaFromState.

Magic numbers are bad.

 

Compare:

 

setBlockState(myBlock.getStateFromMeta(12)) // what does this do?!
setBlockState(myBlock.getDefaultState().withProperty(MyBlock.TYPE, MyBlock.Type.FOOBAR)) // very clear

[Major Squirrel]

The point is you should not ever deal with metadata in your code, except in getStateFromMeta and getMetaFromState.

Magic numbers are bad.

 

Compare:

 

setBlockState(myBlock.getStateFromMeta(12)) // what does this do?!
setBlockState(myBlock.getDefaultState().withProperty(MyBlock.TYPE, MyBlock.Type.FOOBAR)) // very clear

 

The byMetadata method inside the enum handles the meta by returning the correct enum :

 

        public static EnumType          byMetadata(int meta) {
            if (meta < 0 || meta >= META_LOOKUP.length) meta = 0;
            return (META_LOOKUP[meta]);
        }

 

The purpose to use metadata here is to get the correct enum according to the currentCycle/metadata, incremented in the TileEntity.

[diesieben07]

Again, don't deal with the metadata.

Use the Enum inside the TileEntity. Not some arbitrary number. Why do you have the enum if you then don't use it?

[Major Squirrel]

Again, don't deal with the metadata.

Use the Enum inside the TileEntity. Not some arbitrary number. Why do you have the enum if you then don't use it?

 

I use it, to get the correct texture block according to the currentCycle : the currentCycle corresponds to the metadata. It is then converted to the specific enum which gets the correct texture of the block.

 

BlockBarrel.java

TileEntityBlockbarrel.java (server)

 

If I don't have to deal with metadata, could you explain me how can I change my texture block according to an incrementing variable (dynamically) ?

[diesieben07]

If you have an incrementing variable, then you'd have that variable as a property in your block state. If it's an int, use a PropertyInteger. Why are you using an enum if the variable is then an int? It just doesn't make any sense.

[Major Squirrel]

That is because I wanted to associate an integer to a string so that the texture could be set according to the variants, for example :

 

{
    "variants": {
        "mode=normal": { "model": "questsystem:block_barrel" },
        "mode=fermented": { "model": "questsystem:block_barrel_fermented"}
    }
}

 

The mode is the enum, normal and fermented are strings of the enum associated with the int (the currentCycle/metadata)

[diesieben07]

If you say the world "metadata" again I will punch something.

 

Now you have mode normal and fermented. What is this int thing you are talking about now?

[jeffryfisher]

Actually, it looks like he should be using PropertyBoolean FERMENTED, which could be true or false (default false). Is there any need for an enum that has only two values?