[1.8] Why does my block have 2 tile entities?

[KriszDev]

Hello everyone

 

I've tried to create a basic tile entity which stores an array of values. This is not relevant because it works ,but when I place the block it created 2 tile Entities and when I get that tile entity there are two different one depending on when I get it.

 

public class BlockOreFarm extends BlockContainer
{
    public BlockOreFarm(Material materialIn, String name)
    {
        super(materialIn);
        setUnlocalizedName(name);
        setBlockUnbreakable();
        setLightLevel(12);
        setCreativeTab(ModMicroTech.tab);
    }

    @Override
    public int getRenderType()
    {
        return 3;
    }

    @Override
    public TileEntity createNewTileEntity(World worldIn, int meta)
    {
        ModMicroTech.log.info("TILE ENTITY CREATED");
        return new TileOreFarm().set(ApiFarm.get());
    }
}

 

 

[09:02:19] [Client thread/INFO]: TILE ENTITY CREATED
[09:02:19] [Client thread/INFO]: Constructed farm:  ContainedWithin{Diamond, 496696/496696}  ContainedWithin{Iron, 790747/790747}  ContainedWithin{Emerald, 371361/371361} 
[09:02:20] [server thread/INFO]: TILE ENTITY CREATED
[09:02:20] [server thread/INFO]: Constructed farm:  ContainedWithin{Iron, 555640/555640}

 

As you see there are two create call for each block placed in my world. What causes this? and what should I do now?

[Draco18s]

The log knows all.

One on the client, one on the server.

SSP does still have both.

[KriszDev]

The log knows all.

One on the client, one on the server.

SSP does still have both.

 

So I have to check whether I'm on client or server side and only create in on server side?

[N247S]

Nope, the serverSide TileEntity is for all the logic behind a block. The clientSide one is for rendering, since values can be shared between server and client through the read/writeToNBT methods. That way there is no need for a complex packet system.

 

ClientSide rendering can either be a gui (chest items, furnace progress etc.) Or an animated block model(which animation is dependend on the tileEntity values. (Smelting furnace etc.).

 

So no, no need to prevent the initializing of a tileEntity on either side. Even if you dont use it on the clientSide.

[Draco18s]

In fact, returning null is a bad idea.

[jeffryfisher]

If you read other recent TE and BlockContainer threads, you'll see D7 telling modders to avoid extending BlockContainer. I don't know what it's issues are, but you may have run into another one.

 

Instead, you should probably implement ITileEntityProvider. Not only will you be forced to override the create method, but class Block will detect you and return true from hasTileEntity.

 

Remember to put NBT write and read methods in your TE, and register your TE in your main mod class. Also, if your host block ever does anything with states, you'll probably need to override shouldRefresh.

[Major Squirrel]

In fact, returning null is a bad idea.

 

 

If you read other recent TE and BlockContainer threads, you'll see D7 telling modders to avoid extending BlockContainer. I don't know what it's issues are, but you may have run into another one.

 

Instead, you should probably implement ITileEntityProvider. Not only will you be forced to override the create method, but class Block will detect you and return true from hasTileEntity.

 

Remember to put NBT write and read methods in your TE, and register your TE in your main mod class. Also, if your host block ever does anything with states, you'll probably need to override shouldRefresh.

 

For my part, I didn't have to implement the ITileEntityProvider interface : I simply overrode hasTileEntity and createTileEntity (and not createNewTileEntity) methods, and it seems to work very well ! I suppose it would be different according to different user cases. 

[jeffryfisher]

@jeffry: No, both BlockContainer and ITileEntityProvider suck. ITileEntityProvider gives you the metadata instead of the IBlockState. Why? I don't know, but it sucks.

I feel your pain (every time I need a TE for one of my mods). What I finally realized is that the create method can't legitimately do anything more than instantiate a TE of a particular child class. That's all it's supposed to do. A TE's data-setting must wait until later, which is why TE constructors never take parameters.

 

This is a consequence of some creates being real-time block-placement acts, but other creates are chunk-loading, NBT-reading acts. The former offer niceties such as blockstate and placer entity via an override of onBlockPlacedBy, which can fetch the newly-allocated but empty TE and finally provide it with data by calling the TE's setter methods. Chunk-loading employs a TE's own NBT methods, which should save and restore all of a TE's data, so no block-state (or pos or worldIn etc) is needed until there's an update (and heaven help you if you haven't overidden "shouldRefresh" to return false for most state changes not replacing the containing block).