Changes

Tile entities are like simplified entities that are bound to a <code>Block</code>. They are used to store dynamic data, execute tick based tasks and for dynamic rendering. Some examples from vanilla Minecraft would be: handling of inventories (chests), smelting logic on furnaces, or area effects for beacons. More advanced examples exist in mods, such as quarries, sorting machines, pipes, and displays.

Tile entities are like simplified entities that are bound to a <code>Block</code>. They are used to store dynamic data, execute tick based tasks and for dynamic rendering. Some examples from vanilla Minecraft would be: handling of inventories (chests), smelting logic on furnaces, or area effects for beacons. More advanced examples exist in mods, such as quarries, sorting machines, pipes, and displays.

 

A <code>TileEntity</code> isn’t a solution for everything, and they can cause lag when used wrongly. When possible, try to avoid them.

{{Colored box|title=Tip|content=A <code>TileEntity</code> isn’t a solution for everything, and they can cause lag when used wrongly. When possible, try to avoid them.}}

== Creating a <code>TileEntity</code> ==

== Creating a <code>TileEntity</code> ==

These methods are called whenever the <code>Chunk</code> containing the <code>TileEntity</code> gets loaded from/saved to NBT. Use them to read and write to the fields in your tile entity class.

These methods are called whenever the <code>Chunk</code> containing the <code>TileEntity</code> gets loaded from/saved to NBT. Use them to read and write to the fields in your tile entity class.

{{Colored box|title=Tip|content=Whenever your data changes you need to call <code><nowiki>TileEntity#markDirty()</nowiki></code>, otherwise the <code>Chunk</code> containing your <code>TileEntity</code> might be skipped while the world is saved.}}

Whenever your data changes you need to call <code><nowiki>TileEntity#markDirty()</nowiki></code>, otherwise the <code>Chunk</code> containing your <code>TileEntity</code> might be skipped while the world is saved.

The tag names <code>id</code>, <code>x</code>, <code>y</code>, <code>z</code>, <code>ForgeData</code> and <code>ForgeCaps</code> are reserved by the super methods.

 

The tag names <code>id</code>, <code>x</code>, <code>y</code>, <code>z</code>, <code>ForgeData</code> and <code>ForgeCaps</code> are reserved by the super methods.}}

== Ticking <code>TileEntity</code> ==

== Ticking <code>TileEntity</code> ==

ITickableTileEntity#tick()

ITickableTileEntity#tick()

</syntaxhighlight>

</syntaxhighlight>

 

This method is called each tick. Therefore, you should avoid having complicated calculations in here. If possible, you should make more complex calculations just every X ticks. (The amount of ticks in a second may be lower than 20 (twenty) but won’t be higher)

{{Colored box|title=Tip|content=This method is called each tick. Therefore, you should avoid having complicated calculations in here. If possible, you should make more complex calculations just every X ticks. (The amount of ticks in a second may be lower than 20 (twenty) but won’t be higher)}}

== Synchronizing the Data to the Client ==

== Synchronizing the Data to the Client ==

Again, this is pretty simple, the first method collects the data that should be send to the client, while the second one processes that data. If your <code>TileEntity</code> doesn’t contain much data you might be able to use the methods out of the [[#storing_data|Storing Data]] section.

Again, this is pretty simple, the first method collects the data that should be send to the client, while the second one processes that data. If your <code>TileEntity</code> doesn’t contain much data you might be able to use the methods out of the [[#storing_data|Storing Data]] section.

{{Colored box|title=Important|content=Synchronizing excessive/useless data for tile entities can lead to network congestion. You should optimize your network usage by sending only the information the client needs when the client needs it. For instance, it is more often than not unnecessary to send the inventory of a tile entity in the update tag, as this can be synchronized via its GUI.)}}

Synchronizing excessive/useless data for tile entities can lead to network congestion. You should optimize your network usage by sending only the information the client needs when the client needs it. For instance, it is more often than not unnecessary to send the inventory of a tile entity in the update tag, as this can be synchronized via its GUI.

=== Synchronizing on block update  ===

=== Synchronizing on block update  ===

SimpleChannel#send(PacketDistributor.TRACKING_CHUNK.with(() -> chunk), MSG);

SimpleChannel#send(PacketDistributor.TRACKING_CHUNK.with(() -> chunk), MSG);

</syntaxhighlight>

</syntaxhighlight>

{{Colored box|title=Alert|content=It is important that you do safety checks, the TileEntity might already be destroyed/replaced when the message arrives at the player! You should also check if the area is loaded using (<code><nowiki>World#isAreaLoaded(BlockPos, int)</nowiki></code>)}}

It is important that you do safety checks, the TileEntity might already be destroyed/replaced when the message arrives at the player! You should also check if the area is loaded using (<code><nowiki>World#isAreaLoaded(BlockPos, int)</nowiki></code>)