Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[Answered] Question about Tile Entites


PegBeard
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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

.

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

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.

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

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.