Jump to content

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


KriszDev

Recommended Posts

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?

Link to comment
Share on other sites

The log knows all.

One on the client, one on the server.

SSP does still have both.

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

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.

Projects:

Discontinued:

- N2ConfigAPI

- Meachanical Crafting Table

 

Latest:

- CollectionUtils

 

Coöperations:

- InGameConfigManager

Link to comment
Share on other sites

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

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.

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

 

8)

 

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.  ;D

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

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

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

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

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