Block update

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 a mechanism such as a block update. 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.

Java Edition
$$, there are three types of block updates: NC update, PP update, and comparator update.

Priorities
When a block changes, it can send different block updates that have different priorities:

PP update
A PP update (i.e. update post placement, update neighbour 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). It almost always has a priority of 2.

Sending

 * General PP updates
 * When a block is placed, destroyed, replaced, or its blockstate is changed, the game sends PP update to its immediate neighbors, in order of west, east, north, south, down, up.


 * Exception
 * However, there are some exceptions:
 * Lighting a nether portal does not send PP update.
 * A nether portal generating does not send PP update.
 * Changing block state with debug stick does not send PP update.
 * Shulker boxes sends general PP updates when beginning to open/close or complete openning/closing.
 * When a redstone wire is placed, destroyed, replaced, or its blockstate is changed, for any block that the redstone wire points horizontally to, if it is not a redstone wire, then the game also sends PP updates to the block above it and the block below it. However, it does not send PP update to an observer.
 * Pistons and beds have more complex updates.

Receiving
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 following blocks can receive PP updates:

NC update
NC update (i.e. neighbor changed, update neighbors, redstone update) is the most widely known type of block updates, mainly used for redstone components.

Sending

 * General NC updates
 * Most blocks send NC updates to their immediate neighbors when they are placed, destroyed, or replaced, or their blockstates are changed, in order of west, east, down, up, north, south.


 * Exception
 * Some changes do not produce General NC updates:
 * Thickens when the upper bamboo thickens.
 * Grows into a bamboo.
 * and
 * Converts to each other.
 * ,, and
 * Turns into a golem.
 * Plants
 * Turns into a double-block plant.
 * Its water level changes.
 * and
 * Grows, ripens or changes its shape.
 * Grows.
 * Be lit or unlit.
 * Its signal or its mode is changed.
 * ,, and
 * Dies.
 * ,, , and
 * Grows.
 * ,, and
 * Opens, closes, actives, or deactives.
 * Transports to destination.
 * Gets hydrated or dry.
 * Melts gradually (but has not turned into water).
 * Inserts or ejects records.
 * Grows.
 * Be lit or unlit.
 * Be lit or unlit.
 * Increase its number using bone meals.
 * Absorbs water.
 * and
 * Grows
 * Remove the melon or pumpkin from it.
 * Grows
 * Its fruits are collected.
 * Its number decreases.
 * Grows, changes its shape, grow out a new vine block.
 * ,, and
 * Turns into a wither.
 * Be eaten by a sheep.
 * Be eaten by a rabbit.
 * Damaged.
 * The Eye of Ender is placed.
 * Generates.
 * Bottles or potions are added into it.
 * and
 * Changes its mode.
 * and
 * Grows.
 * Change its mode.
 * ,, and
 * Be activated or inactivated
 * Its age or shape changes.
 * Increases its stage.
 * Its "disarmed" value changes.
 * Be occupied or unoccupied.
 * and
 * Generates as a nether portal.
 * A nether portal be activated.
 * Add or remove hay bale below it.
 * ,, , , , and
 * Its shape changes.
 * ,, and
 * Be covered or uncovered by snow.
 * ,, and
 * Grows.
 * Add or remove kelp/vines above/below it.
 * Its signal changes.
 * All blocks
 * Change its blockstate using debug stick.
 * Placed by a command.
 * s, and
 * Have more complex behavior.
 * Change its mode.
 * ,, and
 * Be activated or inactivated
 * Its age or shape changes.
 * Increases its stage.
 * Its "disarmed" value changes.
 * Be occupied or unoccupied.
 * and
 * Generates as a nether portal.
 * A nether portal be activated.
 * Add or remove hay bale below it.
 * ,, , , , and
 * Its shape changes.
 * ,, and
 * Be covered or uncovered by snow.
 * ,, and
 * Grows.
 * Add or remove kelp/vines above/below it.
 * Its signal changes.
 * All blocks
 * Change its blockstate using debug stick.
 * Placed by a command.
 * s, and
 * Have more complex behavior.
 * Add or remove kelp/vines above/below it.
 * Its signal changes.
 * All blocks
 * Change its blockstate using debug stick.
 * Placed by a command.
 * s, and
 * Have more complex behavior.
 * Have more complex behavior.


 * Other NC updates
 * Some blocks (mainly redstone components) sends Sends more NC updates other than general NC updates when changing.

Receiving
When a block receives a NC update, the source of the NC update may be considered. For example, a rail accepts only NC updates from power components.

Only following blocks can receive NC updates:

Comparator update
Redstone comparators can use certain blocks and entities as power sources, and in turn, the blocks or entities send comparator updates (i.e. Block entity updates, Update neighbour for output signal) when changing.

When a block/entity that can be detected by comparators changes, it sends updates to surrounding comparators (include comparators separated by a solid block), in order of north, east, south, and west.

Only comparators can receive these updates. When receiving, they calculates and changes their signal.

Special blocks
Pistons and beds have complex behavior.

Block updates and DFS
Block updates follow the principle of 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.

Self update
When a block is placed, it maybe checks and adapts itself to its surroundings, in a priority of -1. Strictly speaking, this isn't a block update. However, there is a significant bug: When a block is placed/changed, if it changes again when self update, then the former change does not produce any updates that is in a priority of 0, 1, or 2. That's why self update is mentioned on this page.

Here is a list that self updates that can cause the bug.
 * When being placed, if it should be powered, becomes powered.
 * If in the nether, it turns into an dry sponge.
 * When being placed, it absorbs water and turns into an wet sponge.
 * and
 * When a powered target or observer is placed, it turns into an unpowered state.
 * When being placed, it updates the signal and connection.
 * When being placed, if it should be extinguished, removes itself.
 * When being placed, if it should explode, removes itself.
 * When being placed, it updates its shape.
 * When being placed, it checks whether it is pressed and updates its state.
 * When being placed, if it should turn into a golem, removes itself.
 * When being placed, if it should be extinguished, removes itself.
 * When being placed, if it should explode, removes itself.
 * When being placed, it updates its shape.
 * When being placed, it checks whether it is pressed and updates its state.
 * When being placed, if it should turn into a golem, removes itself.
 * When being placed, it checks whether it is pressed and updates its state.
 * When being placed, if it should turn into a golem, removes itself.
 * When being placed, if it should turn into a golem, removes itself.
 * When being placed, if it should turn into a golem, removes itself.

History
Blockupdate