V · Blocks

Verified against Minecraft 26.3 · Part V · Everything that happens at the moment one block state replaces another: the click that asks for it, the write that performs it, and the four kinds of answer a block can give back.

You open a door and both halves swing. You flip a lever and the lamp across the room stays dark for a moment longer than you expected. Both are the same event underneath — a position in a chunk section stops holding one block state and starts holding another — and everything here is either choosing the state that goes in, performing the write, or being a block that answers one. A block has four ways to answer that this part teaches (a fifth, the game event, is Part IV’s), and the part is organised around them rather than around the three hundred block classes that use them: a neighbour update (something near you changed), a shape update (your neighbour’s state is now this — do you still fit?), a block event (do this at a named moment later in the tick) and a scheduled tick (do this in n ticks). A reader who has those four, and Part IV’s game events, can read any block in the game.

Two of them are the two channels a write can leave by, and that is where the door and the lamp part company: the neighbour channel exists only on the server, and the shape channel runs on both sides. The door’s other half comes down the channel your own client also runs, so it moves before the server has been asked; the lamp waits on the channel that exists only on the server. Half the surprises in this part are that sentence in another costume.

The shape of the part

Counting the two packages the atlas lists for this part, that is 484 files and 58,507 lines — and seven lectures is the fewest of any part with as many lines, on purpose. Most of those files are one Block subclass each, filling in a few of the hooks BlockBehaviour and Block declare (blocks and states).

Part V is a hub and six spokes. The hub is blocks-and-states, and what each spoke takes from it is not the state table — it is a piece of the write, drawn there in two flowcharts and pointed at from every other page. The six arrows out of the hub below are labelled with what it hands that spoke; the five between spokes are the places two lectures share a mechanism.

flowchart TD
    BS["1 · Blocks and states"]
    BI["2 · Block interaction"]
    BB["3 · Block breaking"]
    BE["4 · Block entities"]
    SD["5 · Signal and dust"]
    PE["6 · Pistons and block events"]
    DO["7 · Diodes and the observer"]
    BS -- "the shape channel" --> BI
    BS -- "the tail of an UPDATE_ALL write" --> BB
    BS -- "when a block entity lives and dies" --> BE
    BS -- "the neighbour channel" --> SD
    BS -- "the flag word's rarer bits" --> PE
    BS -- "an UPDATE_CLIENTS write's side effects" --> DO
    BI -- "one click each, one ledger" --> BB
    SD -- "what powers a piston" --> PE
    SD -- "what a diode reads" --> DO
    BE -- "redstone's one loose int" --> DO
    BE -- "the moving block's entity" --> PE

The part as a hub and six spokes, numbered to the watch order. Six arrows leave blocks-and-states carrying the piece of a write that lecture is about; the five arrows between spokes are the mechanisms two spokes share, and every one of them runs from an earlier lecture to a later one.

Before you start

Five pages are load-bearing, each for one reason. Chunk anatomy is the first half of every write here. The level tick matters because half of this part’s surprises are really claims about which phase of a tick something ran in, and the server tick sits behind it for the two claims about what happens outside one: a packet handler runs before the levels do, a connection is flushed after. Scheduled ticks is how a block gets a turn later, which each of the diode lecture’s three blocks uses. And fluids owns the FluidState that shares a StateHolder with every block state. Identifiers and registries is assumed rather than used: the hub rests throughout on every block state having been built into one table before any world existed.

One dependency runs the other way. Prediction and acknowledgement is Part X, and the two click lectures use three of its six windows — but its own scenario is a block placed against a wall, which needs this part’s vocabulary. So watch Part V first: both click pages state the contract in the same four sentences near their top, which is all either lecture needs. Part X is also where the third thing a player notices about this part lives, after the door and the lamp above — the block that appears under the crosshair before the server has heard about it.

Watch in this order

1. Blocks and states — a right-click on stone puts one of oak stairs’ eighty states into the world. Every state the game will ever have was built before the world was, and the world only ever points into that table. The second half — what the write does — is the pair of figures the other six lectures point back at.
2. Block interaction — the right click, in full: a door opened by hand. It fires no neighbour update at all, and the top half follows anyway.
3. Block breaking — the same lecture’s other half: two clocks that agree without either telling the other its count, because the one comparison that matters happens in the packet drain rather than in the tick. Finish too early and the block usually comes back, then vanishes again, and nothing the player does with the button stops it.
4. Block entities — a furnace smelts while nobody is looking. It tells nobody anything: the fire is a block state, the arrow is four ints from a menu, and both are a tick late by construction.
5. Signal and dust — a lever, two dust, and the cascade. A line turning off is visited again at every intermediate value it passes through, none of which is ever sent to anybody, and the game ships a second implementation behind a flag that does not do it at all.
6. Pistons and block events — the part’s deferral with no delay in it: the work waits for one named phase of the level tick rather than for a number of ticks, and usually gets it in the same tick — and the one place the client is handed a re-simulation rather than a result.
7. Diodes and the observer — the part’s closer. Three blocks that learn about their neighbours three different ways, and the one whose entire job is noticing change turns out not to be listening on the channel that carries it.

Where the part stops

Part V owns the write’s tail and three of the four answers; it does not own most of the blocks. 47% of the part’s lines are named on no page in the book, and of the blocks that are taught, many are taught elsewhere: a block is usually the place some other system surfaces, so it is taught where its scenario is — the sculk family with game events and vibrations, LiquidBlock with fluids, the containers with Part VII, signs and chests as things drawn with Part XI, the structure block with jigsaw and templates, the command block with Part XIII. What comes back here is the moment any of them writes a state.

Of what belongs to nobody, three lecture-sized mechanisms are declared here, and this is the sentence that says so rather than leaving the silence to be found. The hopper is the first — HopperBlockEntity is named on one other page, for its cooldown, and the transfer itself is explained on none. Sculk spread is the second: SculkSpreader’s charges walking through SculkBehaviour, SculkBlock and SculkVeinBlock, where the page that owns the catalyst owns it only as a listener. The third, and the largest, is a family — BeaconBlockEntity, ConduitBlockEntity and the trial-spawner and vault sub-packages, the last two of which other pages name in passing while their state machines go unexplained. Each waits for a second edition.

Reference this part uses

Block update flags is the one to open first, because every page here spends at least one flag word: the ten bits of Level.setBlock’s argument and what reads each. Then registries for Registries.BLOCK and Registries.BLOCK_ENTITY_TYPE, packets for every block update, block event and acknowledgement in one table, data components for DataComponents.TOOL, game rules for GameRules.BLOCK_DROPS, and math and primitives for BlockPos, Direction and the packings every page here assumes. The glossary defines the four answers and the two things they act on, all but the scheduled tick from pages in this part, and diagram lanes explains the abbreviations these figures use.

Rules: names, never code · how the system works, not how the code reads · newest version only · every backticked name passes tools/verify_names.py.