PlaceRuinedPortalPiece runs the template through the decoded processor
stack — positional Legacy streams per cell drive the gold-to-air,
lava-to-magma, netherrack-to-magma and block-age mossiness rolls, the
features-cannot-replace guard skips protected cells, and template lava
stays when it lands in existing lava. Drip columns below the portal
draw from a documented approximation of the shared decoration stream;
spreadNetherrack is not needed for the underground setups.
The placement chain is now proven end to end: chunk (1,0) reproduces
vanilla's saved start (portal_6, CLOCKWISE_90, NONE, air pocket at
(16,12,0)) and the fixture parity ticks up to 98.033% with biomes and
heightmaps still exact. generatorVersion bumps to 23.
Three fixes close the loop against the captured region file: the giant
roll precedes the template draw, surfaceY is the topmost non-air block
(getHeight already returns one past it), and structure biome refs
resolve through has_structure/ tags to the extracted tag files. The
weighted variant pick walks a fresh per-attempt GenerationContext
stream while failed entries drop from the pick stream without reseeding.
TestRuinedPortalStubMatchesVanillaStart pins chunk (1,0) to vanilla's
own saved start: portal_6, CLOCKWISE_90, mirror NONE, air pocket,
template position (16,12,0) — and asserts the neighbouring fixture
chunks stay portal-free.
generateBaseTerrain now factors the noise+surface stage out of chunk
generation so structure placement can read pre-carve heights exactly
like vanilla's STRUCTURE_STARTS stage. RuinedPortalGenerationPoint
replays the ruined_portals set: the weighted pick across all seven
variants on its own stream, each attempt's setup/template/rotation/
mirror draws on a fresh GenerationContext stream (makeRandom reseeds
per attempt, confirmed from bytecode), findSuitableY with corner-column
settle scan against those heights, and the post-draw 3D-biome filter at
quart-snapped coordinates.
Known gap, documented in STRUCTURE_NOTES.md: no variant is accepted in
the window around the fixture's portal yet while vanilla placed one;
the biome/surface inputs need a vanilla-side probe to bisect. Not wired
into the production replay until that closes.
Loads the 26.1.2 structure datapack: 20 structure sets, 34 structure
definitions, and the worldgen biome tags they reference. Random-spread
placement follows RandomSpreadStructurePlacement byte for byte — region
floorDiv by spacing, one Legacy stream salted per region, two
spread-type draws for the offset — and the four legacy frequency
reducers keep their exact draws, including the hardcoded buried-treasure
salt and the outpost's discarded full-range int.
Verified against the fixture: on seed 12345 the ruined_portals set
claims exactly chunk (1,0), the chunk whose captured blocks carry the
ruined portal's obsidian, gold, and crying obsidian. TestStructure-
PlacementGrid pins that plus village separation invariants.
Ports MonsterRoomFeature from bytecode with vanilla draw order and loop
structure: shell validation (solid floor and ceiling, one to five open
side columns), interior cave_air carving, cobblestone walls with the
mossy three-in-four floor roll drawn only where vanilla draws it, chest
placement faced away from its single opaque neighbour with the loot-seed
long consumed even though block entities are not modelled yet, and the
spawner's one-draw mob pick. Writes go through Feature.safeSetBlock
semantics against #minecraft:features_cannot_replace, captured verbatim
from the jar into the embedded datapack data.
The pass slots between geodes and the ores so the rooms' cave_air
pockets exist before ore ellipsoids roll their air-exposure discards.
The committed fixture's four chunks happen to contain no dungeons, so
measured parity holds at 98.028%, but the generator's output can differ
elsewhere: generatorVersion bumps to 22.
TestVanillaBaseTerrainParity compares our noise+surface+carver+aquifer+
vein pipeline against a vanilla capture whose biomes carry no features
and no structure sets: all 393,216 cells match. The plain-state fixture
mismatches the base-terrain diagnostic used to attribute to carver or
aquifer defects are therefore feature outputs wearing plain states —
monster-room cave_air, geode voids, lava-lake lava — and its doc comment
now says so.
Splits fixture mismatches into classes that name the responsible
subsystem: plain-vs-plain cells are direct base-terrain defects and come
with sample coordinates, single-side feature states count as flips per
family, and disk-shaped outputs land in an ambiguous bucket so they
cannot pollute the plain signal.
First run on seed 12345: 966 base cells (0.246%), dominated by vanilla-
carved cave segments missing from our carver output and deepslate-to-
water aquifer edges.
The combined stage-6 pass in placeScheduledUndergroundOresStage already
replays ores, underwater magma, and disks in datapack order; the separate
placeScheduledDisks and placeScheduledUnderwaterMagma passes have no
callers left. Keep the per-position helpers the combined pass and tests
use.
The router's noise caves are one kind of cave. The other kind -- the long
winding tunnels with rooms and side branches, and the ravines that cut down
through the terrain -- is walked, step by step, by a random source, and none of
it existed.
The shape of the work is unusual enough to state plainly. To carve one chunk,
vanilla replays every carver seeded in the 17x17 chunks around it and keeps only
what lands inside, so the same tunnel is walked up to 289 times across a world.
That redundancy is the point: it is what lets a chunk be carved without
generating its neighbours, which is the only way carving fits a generator that
produces one chunk at a time. A carve-once-write-into-neighbours design would be
cheaper and would not reproduce vanilla's mask and ordering.
Two primitives had to be right before any of it could be, and both are pinned
against values captured from the jar:
* setLargeFeatureSeed, which decides which chunks start a cave. It combines
its two products with XOR; setDecorationSeed, which it otherwise resembles,
uses addition and forces the low bit. Getting them the wrong way round moves
every tunnel in the world and nothing complains.
* Mth.sin and Mth.cos, which are a 65536-entry lookup table and not libm.
Mth.sin(-1.0) is -0.8414514 against Math.sin's -0.8414709848078965, and a
tunnel that walks by adding cos(yaw) a hundred times ends up somewhere else
entirely if that difference is smoothed away.
Carving lands between the surface pass and decoration, where vanilla puts it,
and both neighbours matter: the surface rules must already have placed grass for
a cave mouth to be retextured, and decoration must come after so nothing is
planted over a hole. The heights decoration plants against are recomputed
afterwards, which is why vanilla re-primes its heightmaps at the start of the
feature step.
The configs are extracted from the jar rather than transcribed, along with the
flattened #minecraft:overworld_carver_replaceables tag, so the probabilities and
Y ranges are data. Open volume below y=60 rises 28% over sixteen sampled chunks,
tunnels cut at or below y=-56 fill with lava rather than air (869 blocks, no
air), and the cost is inside the noise floor of the density pass.
The router has carried vein_toggle, vein_ridged and vein_gap since the whole of
it was parsed, and nothing read them. So the copper and iron mega-veins -- the
long branching sheets that run through the deepslate and the copper band, not
the small scattered ore blobs -- did not exist.
OreVeinifier is not a decoration feature. It is the second entry of the same
MaterialRuleList the aquifer heads: the aquifer answers first, and only where it
says the position is solid rock does the veinifier get a turn at what would
otherwise be plain stone. That is why a vein never opens into a cave, and it is
why this lands in the density pass rather than in decorate.
Three random draws per position, in a fixed order, from a factory hashed off
"minecraft:ore": solidness, then richness, then the rare raw-ore block.
Reordering them or hoisting the vein_gap compute above the second draw would
change every vein in the world, so the code follows the bytecode's order rather
than the one that reads better.
The Y windows are the sharp edge worth knowing about: a vein's type comes from
the sign of the veininess noise, but its window comes from the type, so
veininess <= 0 anywhere outside -60..-8 is simply not a vein. Over 49 sampled
chunks copper lands in 0..49 and iron in -57..-8, and raw ore comes out at 1.9%
of ore blocks against vanilla's 2%.
Our region files were not Anvil. Three things stood between them and vanilla's
deserializer, and each is enough on its own:
* everything was nested under a "Level" compound. Chunk data lived there until
1.18; SerializableChunkData builds a flat root and never looks for the key.
* a section's Y was an Int. Vanilla writes putByte and reads getByteOr, so
every section of ours decodes as index 0 and overwrites the one before it.
* block palettes were packed at ceil(log2(size)) bits. Strategy's tableswitch
routes bit counts 1 through 4 to the same four-bit configuration, so a
palette of 2..16 states is four bits wide on disk. Ours were one to three,
which makes the long array a quarter of the length vanilla computes, and
SimpleBitStorage rejects the section outright rather than misreading it.
Biome containers were already right: Strategy has no such floor for them, and a
Global configuration above three bits still stores palette indices, just at its
own width. The suspicion that biomes collapsed on save/load was unfounded --
what let it stand is that every round-trip test in this package set blocks and
asserted blocks, so nothing proved biomes survived. They do now, per cell, for
every palette width a section can hold.
Verified against vanilla rather than against our reading of it:
tools/VanillaChunkFormatCheck.java opens a region file we wrote using vanilla's
RegionFile, NbtIo, Strategy and SimpleBitStorage. Sixteen generated chunks pass.
Reverting either the Y type or the palette floor makes it fail with vanilla's
own message -- "Invalid length given for storage, got: 64 but expected: 256" --
so the check can fail, which is the only reason to trust it passing.
Reading a world the official server generated is what the surface-height parity
capture in CLAUDE.md has always needed, and this is half of it.
blocks.json lists a block's states in getPossibleStates() order -- the property
cartesian product -- and separately marks which one is the default. The parser
declared only id and properties, so the default flag was dropped on the floor
and nameToStateID returned states[0]. Those differ for 642 of the 1168 blocks.
What that produced, measured rather than guessed: every redstone vein in the
world was lit=true and glowing, every sunflower was placed as its own top half
with nothing under it, and oak stairs came out upside down and waterlogged. It
also quietly disagreed with the StateGrass, StateOakLog and StateOakLeaf
constants next door in encode.go, which are the real defaults.
Now it starts from the default state and applies the properties it recognises,
keeping the default's value for an unknown key or an illegal value -- which is
what vanilla does when it reads a palette entry. That matters on the disk path:
a chunk written with a property we no longer know used to decode to a random
corner state instead of something sane.
The signature grows an ok result, because air was doing double duty as both a
real block and "no such name".
Separately, blockPaletteEntry filled the Properties compound by ranging a Go
map. nbt.Compound preserves insertion order precisely so encoding is
deterministic, so saving one chunk twice produced different region-file bytes
for every multi-property block. Keys are sorted now.
LevelChunkSection puts two shorts in front of every section: nonEmptyBlockCount
and fluidCount. We wrote the first and then a literal 0 for the second, under a
comment claiming it was a reserved field that vanilla always leaves at zero.
It is not reserved and vanilla does not.
So every client was told every section is fluid-free, in a world where the
aquifer now fills oceans, lakes and flooded caves. The golden test did not catch
it because its fixture is a superflat chunk whose real fluid count is zero.
The count is per block state, not per block: a waterlogged stair holds a fluid
while a dry one does not, and the flag for that comes from the block-state dump
added with the heightmaps.
writeHeightmaps computed "highest non-air" once and wrote the same 37 longs
under all three ids, on the stated assumption that our terrain has no leaves or
transparency. That stopped being true the moment the generator grew trees and
flowers.
Vanilla's three client heightmaps stop at different blocks: WORLD_SURFACE at the
first thing that is not air, MOTION_BLOCKING at the first that blocks motion or
holds fluid, MOTION_BLOCKING_NO_LEAVES at the first such thing that is not a
LeavesBlock -- an instanceof, not the minecraft:leaves tag. The client places
rain and snow particles off MOTION_BLOCKING and lands a fishing bobber on it, so
a tree canopy reported as solid ground rains under itself.
Neither blocksMotion() nor the leaves test is derivable from blocks.json: the
first reads cached VoxelShape collision geometry and the forceSolidOn/Off
properties, the second is a Java class check. So the Java dumper grows three
flag bits and the whole thing is renamed for what it now is -- block state
properties, not just lighting. tools/VanillaBlockStateDump.java writes
internal/world/block_properties.bin at format 2; the light bytes are unchanged
byte for byte and only the previously unused high flag bits moved.
Verified the dumper round trip while doing it: recompiling the old
VanillaLightDump against the jar reproduces the committed binary exactly, so the
data really does come from the runtime registry and not from a stale checkout.
CLAUDE.md now carries the command to rebuild it.
set_time was declared nowhere and sent never, so the client's sky was frozen
wherever it started: the sun did not move, night did not fall, and nothing in
the world had a time.
26.1.2 replaced the old (gameTime, dayTime, doDaylightCycle) triple with a
registry of named clocks. The packet now carries a fixed-width game time plus a
map from world clock to (totalTicks, partialTick, rate); the client advances
each clock locally at its rate and drives the minecraft:day timeline -- a
keyframe track over a 24000-tick period -- from the overworld clock. The clock
registry is already among the 28 we sync, so the id is looked up rather than
hardcoded and the server refuses to start if it is missing.
The counter rides the entity tick loop because that is the only loop already
running at 20 TPS. It belongs on the single authoritative tick the engine still
needs; putting a sixth ticker beside the five that exist would make that worse.
Broadcast every second, which is what vanilla does -- the client interpolates in
between, so the resend only corrects drift.
The clock also persists now. The world metadata file was written once and never
touched again; it is atomically rewritable, carries gameTime and dayTime, and a
file written before those fields existed still opens and resumes at dawn as it
did. Saved every 30 seconds alongside the chunk autosave, and once more on
shutdown after the final flush.
The bandlands rule cycled four terracotta colours off a per-column random draw.
Vanilla generates a 192-entry band table once per world, from a random source
named clay_bands, and reads it at the block's height shifted by the
clay_bands_offset noise. Brown, red and light grey terracotta were never placed
anywhere; the stripes were the wrong thickness and did not line up between
neighbouring columns. All seven colours now appear.
The temperature condition matched a hand-written list of eleven biome names.
Replacing it with the temperature field read out of the jar's 65 biome JSONs
fixes one of them: deep_frozen_ocean reads cold by name but its base
temperature is 0.5, so vanilla does not freeze it. taiga and the pine taigas
were the other way round -- excluded by name, and correctly so, but by
coincidence rather than by data.
Two parts of the vanilla calculation are left out and documented where they
belong: the height adjustment that cools peaks, and the "frozen" modifier that
warms scattered patches of frozen ocean. Both need PerlinSimplexNoise. Neither
is reachable from the overworld tree in a way that shows: the single condition
that consults temperature sits under a frozen_ocean biome check, below a water
check, and decides whether a hole in the ocean floor ices over. The snowy
mountain tops come from biome selection, not from here -- which is not what the
plan for this commit assumed.
The per-column *rand.Rand threaded through SurfaceContext goes away with the
old bandlands rule; nothing needs it now that vertical_gradient rolls
positionally.
