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

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

[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

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

[Major Squirrel]

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

[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)

[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)));
    }

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

[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) ?

[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)

[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?

[Major Squirrel]

Sorry, I'm updating my code anytime, I'm just discovering the Property concept. I'll lock this topic as it is solved now and, my bad, it derived to new questions.

 

The purpose of all of this is to change dynamically a block texture according to a fermentation cycle in the TileEntity : on block placed, the barrel starts its fermentation at cycle 0, then every X ticks the fermentation "levels up" and the cycle increments.

 

At first, I was using an EnumType called "type", associating a string (cycle0, cycle1, etc) to a value (0, 1, 2...). The purpose of using an enum was to correctly set the blockstates according to the enum properties :

 

(old code)

{
    "variants": {
	"type=cycle0": { "model": "questsystem:block_barrel_cycle_zero" },
	"type=cycle1": { "model": "questsystem:block_barrel_cycle_one" },
	"type=cycle2": { "model": "questsystem:block_barrel_cycle_two" },
	"type=cycle3": { "model": "questsystem:block_barrel_cycle_three" }
    }
}

 

According to the current type of the TileEntity, it set the correct texture associated to the correct model. I was passing the cycle value through blockstates changes, that is why I was talking about metadata.

 

Lately, I wanted to set the block according to the direction the player is facing (like the furnace). It is a that moment that I understood I had to handle the EnumDirection "facing" for each "type" cycle :

 

(current code)

{
    "variants": {
	"fermented=false,facing=north": { "model": "questsystem:block_barrel" },
	"fermented=false,facing=south": { "model": "questsystem:block_barrel", "y": 180 },
	"fermented=false,facing=west": { "model": "questsystem:block_barrel", "y": 270 },
	"fermented=false,facing=east": { "model": "questsystem:block_barrel", "y": 90 },
	"fermented=true,facing=north": { "model": "questsystem:block_barrel_fermented" },
	"fermented=true,facing=south": { "model": "questsystem:block_barrel_fermented", "y": 180 },
	"fermented=true,facing=west": { "model": "questsystem:block_barrel_fermented", "y": 270 },
	"fermented=true,facing=east": { "model": "questsystem:block_barrel_fermented", "y": 90 }
    }
}

 

There, I switched my EnumType to an PropertyBoolean for only two cycles (0 and 1) because the number of cycles is now limited to 10 (because directions use 6 bits on metadata). I suppose that I can go on a PropertyInteger to reach these 10 cycles, but I won't do it for now.

 

Currently, I'm looking for another way to change texture dynamically but it seems that I have to use blockstates to do this ... This will go on another topic I suppose. Anyway, thank you guys to enrich my knowledge.