[Answered] Question about Tile Entites

[PegBeard]

Pretty simple question: Do I need a tile entity?

 

Specifically, if I make a functional block, such as a block breaker, but don't give it an inventory, do I still need a tile entity? I have looked at tutorials for functional blocks, but they have all used inventories and none of them discussed the necessity of tile entities.

[Choonster]

A

TileEntity

is needed for two basic reasons:

• To store data beyond a 4-bit integer (metadata), e.g an inventory
  
• To run code every tick or every X ticks (by implementing

  ITickable

  ). This can also be done via

  World#scheduleUpdate

  /

  Block#updateTick

  , but this may not be as reliable since Minecraft will only run up to 1000 scheduled updates per tick.

 

If you don't need either of these, you probably don't need a

TileEntity

.

[PegBeard]

That is what I thought. It just seemed silly to have a tile entity that does literally nothing.

Thanks

[jeffryfisher]

The difference is one of instantiation. There is only ever one actual object created of each block type. The world has a huge array of block IDs and metadata nibbles, not block objects. A block class's design must function on that tiny nibble of metadata (sometimes augmented by position and other contextual parameters passed into its methods). Millions of stone and air blocks need nothing more, but some blocks do. For those special blocks, we have helpers called tile entities.

 

By contrast, each tile entity gets an object (new TileEntity...) at each of its locations in the world. A tile entity operates while its chunk is loaded. Then (maybe) it writes its data to an NBT tag for storage (call super and then add data). When next the TE is loaded, it must similarly read NBT into an empty new object. Whenever that data changes, it must mark itself dirty to be sure it is (re)written.

 

Because of their abstractedness, block classes must only store data that applies to all blocks of the type. If you ever catch yourself adding persistent situational data to a block, stop; you'd be changing some data affecting every block of that type in the whole world. Ask yourself if the information can be reconstructed from context passed to each involved method call.

 

If so, then that's usually what you should do (even if the block already has a tile entity, you don't want to enlarge its NBT tag unnecessarily). If not, then you need to use a tile entity. If your block extends one that has a TE, then you usually want to extend its TE child class and add your own data (otherwise bad things may happen inside your block's parent).

 

I hope that helps you wrap your head around the block and tile paradigms.