Jump to content

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


Major Squirrel

Recommended Posts

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 ?

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

Don't return null.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

This is why you

Don't return null.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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 ?

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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.  :-\

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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.

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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)

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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?

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

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.

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.