Posted March 2, 20169 yr 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.
March 2, 20169 yr 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.
March 2, 20169 yr Author That is what I thought. It just seemed silly to have a tile entity that does literally nothing. Thanks
March 2, 20169 yr 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.
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.