 |
VOOZH | about |
|
VOOZH | about |
A block update is an in-game mechanism that occurs when a block is modified in some way. Limited to the computing power of a computer, the game can not process all blocks at all times, which is why the game needs such mechanism. When a block changes (due to a player, an entity, or a chunk tick, etc.), it notifies nearby blocks that they should check if they need to respond to the change.
In Java Edition, there are two main types of block updates: post placement (PP) and neighbor changed (NC).
This article uses the priorities listed in the table below to categorize the various block updates. However, keep in mind that these values are not actually present in the game's code.
| Priority | Description | Method in code |
|---|---|---|
| -3 | Updates before the change. | N/A |
| -2 | Some updates after the change. | Blockstate.onRemove()[more information needed]
|
| -1 | Some updates after the change. | BlockBehaviour.onPlace(...)
|
| 0 | General NC updates. | Level.sendBlockUpdated(...)
|
| 1 | General comparator updates. | BlockBehaviour.updateNeighbourForOutputSignal(...)
|
| 2 | General PP updates. | BlockBehaviour.updateNeighbourShapes(...)
|
| 3 | Later updates. | N/A |
Most players only use -3 to 3 priority values to describe scheduled ticks, so it is recommended not to use these values for the update sequence in order to avoid ambiguity with scheduled tick priorities.
A post placement (PP) update (aka update post placement, update neighbor shapes, update shape) is the most common type of block updates, mainly used for connected blocks changing their shapes (e.g. stairs, fences) and attached blocks dropping into items (e.g. torches, cactus, wheat).
When a block receives a PP update, the direction of the PP update may be considered. For example, a wheat block accepts only PP updates from beneath.
Only the following blocks can receive PP updates:
| Block | What to do when receiving a PP update |
|---|---|
| Support-requiring blocks (e.g. torches, snow, carpets, doors, fire, etc.) | Checks if it should break and drop as an item. |
| Connective blocks (e.g. fences, stairs, chests, redstone wires, nether portals, etc.) | Checks if it should change its shape. |
| 👁 Image Redstone repeater |
Checks for being locked or unlocked. |
| 👁 Image Note block |
Tries to update its instrument type. |
| 👁 Image Leaves |
Calculates the distance to logs. |
| 👁 Image Concrete powder |
Solidifies if contacted with water. |
| 👁 Image Water and waterlogged blocks |
Requests a scheduled tick for flowing. |
| 👁 Image Observer |
Requests a scheduled tick for pulsing. |
| 👁 Image Gravity-affected blocks |
Requests a scheduled tick for checking for falling. |
| 👁 Image Dirt path |
Requests a scheduled tick for checking whether it is covered by a solid block. |
| 👁 Image Farmland | |
| 👁 Image Cactus |
Requests a scheduled tick for checking if it should drop. |
| 👁 Image Coral |
Requests a scheduled tick for checking whether it is outside of water. |
| 👁 Image Magma block |
Tries to request a scheduled tick to generate bubble columns. |
| 👁 Image Soul sand |
Neighbor changed (NC) updates (aka neighbor changed, update neighbors, redstone update) are the most widely known type of block updates (for historical reasons), and are mainly used for redstone components.
| Block | Change | Priority | Range and order | Schematic diagram | ||
|---|---|---|---|---|---|---|
| Lever / Button / Pressure plate / Tripwire hook | Destroy an activated lever/button/pressure plate/tripwire hook. | -2 | Their immediate neighbors (in order of west, east, down, up, north, south). Then the immediate neighbors (in order of west, east, down, up, north, south) of the block they're attached to. | |||
| Active or deactive them. Change pressure plate's signal. Tripwire hook connects to a tripwire. |
3 | |||||
| Repeater and Comparator | Place or its blockstate changes. | -1 | The block they're facing. Then the immediate neighbors (without the repeater/comparator itself. In order of west, east, down, up, north, south) of the block they're facing. | |||
| Remove. | -2 | |||||
| Comparator's signal changes. | 3 | |||||
| Chest | Begin to be open/closed | N/A (the block is not changed) | Its immediate neighbors (in order of west, east, down, up, north, south). | |||
| Trapped chest | Begin to be open/closed | N/A (the block is not changed) | Its immediate neighbors (in order of west, east, down, up, north, south). Then the immediate neighbors (in order of west, east, down, up, north, south) of the block below it. | |||
| Observer | Lit or unlit. | 3 | The block it's facing. Then the immediate neighbors (without the observer itself. In order of west, east, down, up, north, south) of the block it's facing. | |||
| Destroy or replace an activated observer. | -2 | |||||
| Place an activated observer. | -1 | Set itself to unactivated without any update. Then update the block it's facing. Then the immediate neighbors (excluding the observer itself. In order of west, east, down, up, north, south) of the block it's facing. | ||||
| Redstone torch | Place or its blockstate changes. | -1 | The immediate neighbors (in order of west, east, down, up, north, south) of the immediate neighbors (in order of down, up, north, south, west, east) of the torch. | |||
| Destroy, replace, or its blockstate changes. | -2 | |||||
| Redstone wire | Destroy or replace. | -2 | The immediate neighbors (in order of west, east, down, up, north, south) of the immediate neighbors (in order of down, up, north, south, west, east) of the wire.
|
👁 Image When removing "R"
👁 Image When removing "R" | ||
| Place. | -1 | Updates the immediate neighbors (in order of west, east, down, up, north, south) of the block above the wire.
|
👁 Image When removing "R"
👁 Image When removing "R" | |||
| Its signal changes | 3 | Update the immediate neighbors (in order of west, east, down, up, north, south) of the datum points. Datum points include the wire and the immediate neighbors of the wire, in random order. | ||||
| Changes between dot and cross | 3 | Update the immediate neighbors (without the wire itself, and in order of west, east, down, up, north, south) of the solid block next to the wire (in order of north, east, south, west). | ||||
| Rails | [more information needed] | |||||
| Any block | Placed with a command. | 3 | Update the immediate neighbors (in order of west, east, down, up, north, south). |
When an NC update is received, the block that caused that update may taken into consideration. For example, a rail accepts only NC updates from power components.
Only the following blocks can react to NC updates:
| Block | What to do when receiving an NC update |
|---|---|
| 👁 Image Frosted ice |
Tries to melt. |
| 👁 Image Redstone dust |
Tries to change its state. |
| 👁 Image Redstone repeater | |
| 👁 Image Redstone comparator | |
| 👁 Image Redstone torch | |
| 👁 Image Rail | |
| 👁 Image Detector rail | |
| 👁 Image Activator rail | |
| 👁 Image Powered rail | |
| 👁 Image Command blocks | |
| 👁 Image Dropper | |
| 👁 Image Dispenser | |
| 👁 Image Note block | |
| 👁 Image Redstone lamp | |
| 👁 Image TNT | |
| 👁 Image Piston | |
| 👁 Image Trapdoors | |
| 👁 Image Fence gates | |
| 👁 Image Doors | |
| 👁 Image Water |
Tries to change itself to be in the correct state. |
| 👁 Image Lava | |
| 👁 Image Sponge |
Tries to absorb water. |
The comparator update (i.e. Block entity updates, Update neighbor for output signal) is a subtype of the neighbor update that is only sent to comparators. Redstone comparators can read certain blocks and produce an output signal, and in turn, these blocks can send comparator updates when changing, to notify the comparators. Comparators can also read some entities (item frames and glow item frames), as such, these entities can send comparator updates too, even though they are not blocks.
When a block that can be detected by comparators changes, it sends updates to surrounding comparators (including comparators separated by a solid block), in this order: north, east, south, west.
After receiving a comparator update, comparators attempt to calculate and change their output signal.
Block updates follow the principle of depth-first search (DFS).
For example, when Block A changes, it maybe sends block updates to B and C one by one. Receiving the update, B maybe changes and sends updates to D and E. Receiving update from B, D changes and sends updates to some block. Then E receives the update from B. Then C receives the update from A.
When a block is placed, it checks and adapts itself to its surroundings by Blockstate.onPlace() or similar methods. Strictly speaking, this isn't a block update; however when a block is placed or changed, if it changes again when self-updated, then the former change does not produce any general update (this is a bug).
Here is a list of self updates that can cause this bug.
| Unknown | |||||||
|---|---|---|---|---|---|---|---|
| ? | Neighbor Changed updates have been added to the game. | ||||||
| Java Edition | |||||||
| 1.5 | 13w05a | Comparator updates have been added to the game. | |||||
| 1.11 | 16w44a | Post Placement updates have been added to the game. At this point in time only observers react to them. | |||||
| 1.13 | 18w47a | The update system has been overhauled: many blocks that used to react to NC updates now react to PP updates instead, also some blocks can now react to both and will behave differently depending on which type of update they receive. | |||||
| Minecraft: Java Edition | |||
|---|---|---|---|
| Versions | |||
| Development |
| ||
| Technical | |||
| Game customization | |||
