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%.
