Ultra Fast Pregen

Ultra Fast Pregen 15.1 for NeoForge 1.21 and 1.21.1

Requires NeoForge 21.0 or later (Minecraft 1.21 or 1.21.1) and Java 21+. Server side only (works in singleplayer). Everything of version 15; it replaces ultrafastpregen-neoforge-1.21.1-15.jar, which asked for exactly 1.21.1.

New

• Minecraft 1.21: the jar now takes 1.21 as well as 1.21.1.

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.123 on 1.21.1: Overworld 101.6 → 118.0 chunks/s, Nether 165.0 → 271.2, End 600.2 → 612.9 (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.

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 1.21 and 1.21.1, each on a dedicated server (NeoForge 21.0.167 and 21.1.259): 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 1.21, block for block over 4,096 chunks in each dimension: the Nether and the End are identical; in the Overworld only 6 bee nests differ, one block apart (they also move between two runs of the same jar).
• With C2ME on 1.21.1: the same blocks and light as without the C2ME change, apart from 8 bee nests one block apart (they also move between two runs of the same jar) and one End city, laid out by the race this version fixes; with this jar and C2ME the city had its 88 pieces in 3 of 3 runs. The runs over existing chunks and across a restart passed with C2ME too.
• Chunks the server holds during a run on 1.21 and 1.21.1: 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,376 and 1,377 of the 1,408 chunks had the same blocks.
• skip_existing_chunks=false through the commands on 1.21.1: 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 1.21.1, 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