Ultra Fast Pregen

Ultra Fast Pregen 15.1 for NeoForge 26.1.2 and 26.2

Requires NeoForge 26.1.2 or 26.2, and Java 25+. Server side only (works in singleplayer). Everything of version 15; it replaces ultrafastpregen-neoforge-26.1.2-15.jar, which was for 26.1.2 only.

New: Minecraft 26.2

26.2 changed what the fast terrain path hooks: density functions are mapped by one walk in DensityFunction#mapAll, the surface rules keep the block's biome in a field and test biomes against a set, and the surface step takes other parameters. The jar carries the hooks of both versions, the ones tested with each in 15, and applies those of the version it runs on.

Not supported: NeoForge for 26.1 and 26.1.1 exists only as betas, which bundle MixinExtras 0.5.3; it fails on this mod's @Redirect mixins (the 15 jar too), where the 0.5.5 of NeoForge 26.1.2 and 26.2 reads them.

Faster with C2ME

15 lit each batch on the worker threads unless another mod changes Minecraft's light engine, and C2ME changes it in two places that keep the light the same. With C2ME, batches were therefore lit on the server's single light thread. 15.1 recognizes both changes and keeps lighting on the worker threads. With C2ME 0.4.0-alpha.0.100 on 26.1.2: Overworld 143.2 → 181.7 chunks/s, Nether 184.9 → 358.0, End 362.1 → 591.3 (Xeon E5-2670 v2, 20 threads, 1,000 × 1,000 blocks).

Fixed: End cities and Nether fortresses

Minecraft lays these two structures out with code that keeps its state in static fields (for End cities whether the city has its ship yet, for fortresses how many of each kind of room it has), one structure at a time. Ultra Fast Pregen creates a batch's structures on all worker threads, so two End cities or two fortresses laid out at the same moment could change each other's layout: a city could lose its ship or get one it does not have in Minecraft, and the rest of it was then built differently. Both are now laid out one at a time, as strongholds already were. In the tests on Fabric 1.21, an End city that has its ship and 88 pieces in Minecraft came out without the ship and with 78 pieces in 3 of 3 runs before this fix, and whole in all 7 runs of 15.1.

Fixed: chunks the server holds during a run

Chunks the server had only part-generated around players and force-loaded chunks came out incomplete when a run replaced them. They lost their scheduled ticks, so water and lava springs there did not flow, and leaves and falling blocks were not updated, until something changed next to them. The mobs placed when a chunk is generated, and those of structures, were lost: with chunks held around the center of a run, 5 to 7 of the 112 mobs of the chunks around them were left. Features that cross a batch edge into such a chunk were dropped, so ore and stone blobs ended at the edge. All of this now reaches the server's chunk. Chunks made by older versions stay as they are unless they are generated again.

Fixed

• skip_existing_chunks=false goes over the whole area: chunks in the save file were skipped, whole batches and single chunks, although the setting, the README and the log said the area is regenerated; /pregen reset was needed first. A new run now forgets what the save file has for its area. /pregen resume and the automatic continuation after a restart still keep what that run saved.
• Features across a batch edge through caves: a kept copy of a saved chunk turned cave air into plain air, so a block a later batch placed in a cave there was taken for a block changed meanwhile and left out.
• A run could leave the fast paths at its first structures: Minecraft fills a rotation's table of directions on first use, and with many threads a jigsaw structure could read it half filled. The batch failed with a NullPointerException in FrontAndTop, and the rest of the run went on the way Minecraft generates, much slower. The chunks were right. The tables are now filled before a run starts.
• A fast path could turn off at random: before using a fast path, the mod asks Mixin what other mods change in the code it replaces. Mixin 0.17, which current Fabric Loader and NeoForge 26 use, can answer nothing for a class while another thread is adding it, and the class then counted as changed by an unknown mod: the log said other mods modify density functions [unknown (NullPointerException)] with no such mod installed. The chunks were right. The mod now asks again.

New: API version 2

PregenApi.worlds() gives other mods what they need to bring chunks into a world from elsewhere, in plain Java types: the world's folders, what generation depends on, separate worlds that generate like a dimension, chunks read and written through the server's own storage, and commands. PregenRequest.withBatchSize and keepingExistingChunks, and the events onServerStarted and onServerStopping, are new too.

Tested on this build

• Minecraft 26.1.2 and 26.2, each on a dedicated server (NeoForge 26.1.2.122 and 26.2.0.93): a fresh 1,000 × 1,000 block area in the Overworld, the Nether and the End; 1,000 × 1,000 blocks around spawn in 4 batches over the chunks saved before, the same area again, and a restart with /pregen resume; and a server stopped once the first batch was saved, whose run continued by itself after the restart. Every chunk was fully generated, lit and readable, on the fast terrain path, with no error from Ultra Fast Pregen in any log.
• The fast terrain path against Minecraft's own terrain steps on 26.1.2 and 26.2, block for block over 4,096 chunks in each dimension: every block is identical in all three dimensions.
• With C2ME on 26.1.2: every chunk has the same blocks and light as without the C2ME change, in all three dimensions; the runs over existing chunks and across a restart passed with C2ME too.
• Chunks the server holds during a run on 26.1.2 and 26.2: the same run with nothing held and with 1,408 part-generated chunks held, compared chunk by chunk. All mobs and all fluid ticks were there, and 1,385 of the 1,408 chunks had the same blocks.
• skip_existing_chunks=false through the commands on 26.2: a run saved 4,096 chunks, the same area with the setting off generated all 4,096 again, and /pregen resume kept them.
• In the game with a real client on 26.2, as a server and in singleplayer: a player in the area during a run, caves dark as Minecraft lights them in the chunks around the player, and a second run with skip_existing_chunks=false.

Full results: https://github.com/Pongsapat3791/Ultra-Fast-Pregen/blob/main/COMPATIBILITY.md#version-151