IV · The world

Verified against Minecraft 26.3 · Part IV · The machinery that turns a place you have walked to into a place that exists: chunks asked for, made, lit, saved and forgotten, and the five pages off that line — what the place and the hour decide, and the four systems that make the world the line delivers feel alive.

Part III was one thread going round. This part is what it goes round on. A world is too big to hold, so the server holds a moving window of it, and almost everything in this part exists to decide the window’s edge: which chunks are worth building, how far past the edge to build them, which of them tick, which of them you are owed a copy of, and when one is finally written down and let go. A player recognises the part by its edge — the chunks that appear at the rim of render distance as you walk, the mobs that stop moving when you fly away from them, the Saving world bar. Almost none of that edge is one number: render distance, simulation distance and the mob-spawning radius are three different radii, answered by three different mechanisms, and only two of them are settings (two graphs, one store).

The shape of the part

Part IV is a conveyor with a vocabulary page in front of it — and the conveyor is a ring, because a chunk written out comes back in through the door it left by. One page defines the thing being handed; four more are the ring, and a chunk goes round it in order. The other five are not on the line at all — one is what the place and the hour decide, and four act on the chunk the ring delivers. Every box below is one of those ten lectures except the one in lower case, which is a chunk’s state rather than a page: the live LevelChunk the ring exists to produce.

flowchart TD
    CA["2 · Chunk anatomy: sections, palettes, heightmaps"]
    TL["3 · Tickets and loading: which chunk, at what level"]
    GP["4 · The generation pipeline: EMPTY to FULL"]
    LI["5 · Lighting: two 4-bit fields, off the tick"]
    CS["6 · Chunk storage: copy, encode, sectors"]
    LC["a live LevelChunk in a ticking world"]
    EA["1 · Environment attributes: the place and the hour"]
    ST["7 · Scheduled ticks: the appointment book"]
    FL["8 · Fluids: the book's biggest customer"]
    GV["9 · Game events and vibrations: what just happened"]
    PI["10 · Points of interest: what is worth going to"]
    CA -- "the vocabulary the ring spends" --> TL
    TL -- "a holder, a ceiling, three futures" --> GP
    GP -- "two of its ten statuses" --> LI
    LI -- "sections dirtied, one packet of them" --> LC
    LC -- "nobody needs it any more" --> CS
    CS -- "a ticket wants it back" --> TL
    LC -- "how anything happens later" --> ST
    ST -- "one customer, its own page" --> FL
    LC -- "what just happened, and who hears it" --> GV
    LC -- "what is worth walking to" --> PI
    EA -- "a value for a position and an instant" --> LC

The part numbered to the watch order: four pages and the live chunk make the ring, and five arrows run round it, the one into lighting an inclusion rather than a hand-off — two of the pipeline’s own ten statuses, run on a different executor. Chunk anatomy hands the ring its vocabulary, lecture one hands the live chunk its values, and the last four act on the live chunk, one of them through another page.

Follow the numbers rather than the arrows and the surprise is where they disagree: the first lecture is watched first and sits off the line, and the sixth hands back to the third.

Later parts hang off that line rather than feeding it: Part V’s blocks assume the sections and palettes of chunk anatomy, Part VI’s entities tick where the tickets say, and Part XII’s terrain is the cargo on the generation pipeline.

Before you start

The server tick and the level tick. Almost everything here happens on the Server thread inside that loop or on the worker pool beside it — the IO lane that chunk storage is about has threads of its own — and the level tick is where the chunk source is asked to do its five things. Part II’s codecs and registries are assumed wherever a chunk is written to disk or a type is looked up by name, and tags wherever a behaviour is defined by a set the data pack owns — which is most of what the last two pages do.

Nothing in this part needs Part V or beyond.

Watch in this order

Lectures two to six are the chain — nothing later in it can be watched first. The first is off the chain on purpose. Of the last four, fluids assumes scheduled ticks and must follow it; the other three can be watched in any order once you have the vocabulary page.

1. Environment attributes and timelines — off the conveyor, ahead of it, and the page Part III already asked you to watch. Whether lava flows fast, what colour the sky is and when a villager goes to work are one mechanism. The night does not set the sky’s colour — it multiplies whatever the biome produced.
2. Chunk anatomy — what a chunk is made of, down to the bit storage. The vocabulary the rest of the part spends. A section holding two distinct block states costs exactly what one holding sixteen costs.
3. Tickets and loading — a player takes one step east and, at view distance 10, a column twenty-one chunks wide is asked for. Nothing asks for a chunk because it is loaded: it asks for a level, and two graphs reading one ticket store answer different questions about it.
4. The chunk generation pipeline — one chunk from EMPTY to FULL through ten statuses and a pyramid of neighbour requirements. Asking for one chunk asks for 529.
5. Lighting — a torch is placed. Two 4-bit fields flooded on a worker and published as a copy. There is no light thread, and no light phase of the tick.
6. Chunk storage — a chunk nobody needs is copied, encoded and written, on three different lanes, and the unload waits for neither the encode nor the write. Almost every write of your world is one nobody asked for.
7. Scheduled ticks — how anything happens later: an appointment book of two queues per chunk, and a dedup rule that quietly drops the second appointment even when it is sooner.
8. Fluids — a bucket of water on flat stone. Water turns toward a hole four steps past the block it is about to fill, because every side runs its own search — and a side the water is not allowed to replace still votes on where the rest of it goes.
9. Game events and vibrations — a footstep reaches a sculk sensor, through a cascade of tests that is most of the lecture. The sensor never acts on a footstep in the game tick that stamped it, which costs a mob a tick and a player nothing.
10. Points of interest — a villager claims a bed from 48 blocks away, the moment a path to it exists. Sleeping in it sets the bed’s occupied flag and tells the index nothing, and the only behaviour that turns that flag into a change in the index can only take a claim away.

Where the part stops

4% of the part’s lines are named on no page in the book, and what it leaves over is mostly two small libraries of shapes the pages above teach: world/level/blockscan, a block search that asks each section’s palette first, as chunk anatomy describes, and the modifier classes an attribute’s arithmetic uses, the library environment attributes describes rather than enumerates.

Two omissions are deliberate. The world border has no lecture — a per-dimension SavedData answering a question about a position, with no chunk to follow and one step of the level tick to move its edge — so it sits on level data and rules. And sending a chunk stops at eligibility: the packet and its pacing are Part IX’s.

Reference this part uses

Level data and rules — who owns the seed, the spawn, the rules, the border and the dimensions, and which file remembers each; it is also where the border itself is explained, for the reason just given. Game rules — five of which this part reads. Math and primitives — ChunkPos and SectionPos, and the packings the conveyor pages assume. Block update flags — the flag word three pages here spend. Registries — most of this part’s vocabularies are registries: chunk statuses, ticket types, fluids, game events, point-of-interest types, environment attributes, timelines and world clocks. Threads — the worker pool and the IO lane. Diagram lanes.

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