II · Foundations

Verified against Minecraft 26.2 · Part II · The machinery every later part assumes: how anything becomes data, gets a name and a number, is loaded, and reaches into code.

Part II is the vocabulary the other twelve parts speak without pausing to define it. Nothing here is a thing a player does; everything here is what happens underneath the things a player does. A player recognises this part by its symptom: the square brackets after an item name in a /give, the #minecraft:logs in a recipe file, the type line at the top of most of the JSON files in a data pack, and the fact that a world made of JSON loads in seconds.

The shape of the part

Part II is not a stack but a fan. Codecs and registries are underneath everything else here, and the five pages above them are largely independent of one another — which is why the figure has two roots and no single column. Watch it bottom-up all the same: every arrow points from the machinery to what takes it for granted, and the last page is the pattern the rest exists to make possible.

flowchart BT
    C["Codecs, NBT and JSON: one object, four formats"]
    R["Identifiers and registries: a name, a number, a Holder, and the freeze"]
    S["The resource system: a stack of packs, a snapshot, prepare then apply"]
    T["Tags: data-pack JSON reaching into hard-coded behaviour"]
    D["Data components: a prototype on the registry entry, a patch on the stack"]
    X["Text components: text as data, worded on the client"]
    P["The data-driven type pattern: a type field is a lookup in a registry packs cannot extend"]
    C -- "every data-pack registry element is decoded by a codec" --> R
    R -- "dynamic registries are loaded from the pack stack" --> S
    S -- "tags are read from the same stack, before the listeners" --> T
    R -- "the tag table is swapped on a registry already frozen" --> T
    R -- "prototypes bind onto Holder.Reference at reload" --> D
    C -- "every persistent component value has a codec" --> D
    C -- "ComponentSerialization holds the whole text matrix in one class" --> X
    T -- "a tag-shaped HolderSet in any file" --> P
    D -- "a component type is a key in a file, not a kind" --> P
    R -- "the type registry is built-in, the elements come from the packs" --> P

Before you start

Anatomy, for the threads: registries are frozen before either program exists, data-pack loading runs on the worker pool with hops back to the owning thread, and a reload’s apply phase runs on whichever thread owns the state being replaced.

Watch in this order

1. Codecs, NBT and JSON — one ItemStack written four ways: into a chunk file, into a packet, as a checksum in a click, and out of the text of a /give. The click sends no component data at all, only hashes.
2. Identifiers and registries — how minecraft:diamond_sword becomes an Item before the game exists, and how a data-pack biome becomes a Holder the client is told about. The wire id of a sword is the line number of its registration.
3. The resource system — F3+T as a pipeline: a stack of packs, a snapshot of the list, every listener preparing at once, applying in order; /reload as the same pipeline on the server. On the client a failed reload deselects every pack, not the bad one.
4. Tags — #minecraft:logs from a JSON file to the set a parrot checks before it perches. A frozen registry’s contents never change, and yet /reload changes what the tag contains.
5. Data components — the prototype an item type supplies and the patch a stack carries. The prototype is built on every reload, with the world’s registries in hand, not in the constructor.
6. Text components — a death message built on the server, sent as a translation key, and worded by the client’s language file. The client receives it before anyone knows what it says.
7. The data-driven type pattern — the type field at the top of a data-pack file is a lookup in a built-in registry of kinds, and the fifty-six registries of that shape are why a pack can compose the game’s behaviours without adding one.

Reference this part uses

Math and primitives — the coordinate spaces, packings, shapes and random sources every page assumes; it was a Part II page and is now looked up, not watched. Registries — every registry key: built-in, data-pack, synced. Data components — every DataComponentType. Naming drift — Identifier was ResourceLocation. Diagram lanes. The glossary is worth more here than in any other part: this is where most of the book’s vocabulary is defined, and it is the page to check when a later part uses one of these words in a second sense.

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