Ultra Fast Pregen

Ultra Fast Pregen 15.1 for Forge 1.20 to 1.20.4

Requires Forge 46 or later (Minecraft 1.20, 1.20.1, 1.20.2, 1.20.3 or 1.20.4) and Java 17+. Server side only (works in singleplayer). Everything of version 15, now in one jar for Minecraft 1.20 to 1.20.4; it replaces ultrafastpregen-forge-1.20.1-15.jar, which was for 1.20.1 only.

New: Minecraft 1.20, 1.20.2, 1.20.3 and 1.20.4

The Forge jar shares the Fabric 1.20.x jar's code and gets its fixes for the calls Minecraft changed:

• 1.20.2 and 1.20.3: a stored chunk's status and the save file are read without the NBT calls those versions changed; with those calls, runs over existing chunks failed and the server crashed at every start after a run.
• 1.20.2: the call that sends a regenerated chunk to the players who see it got another name at run time; the jar now finds it by its parameters.

Not supported: Forge for Minecraft 1.20.6 runs on Mojang's names instead of the SRG names this jar is built with, and there is no Forge for 1.20.5.

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

• Every version from 1.20 to 1.20.4, each on a dedicated server (Forge 46.0.14, 47.4.28, 48.1.0, 49.0.2 and 49.2.13): 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.20.2 and 1.20.4, block for block over 4,096 chunks in each dimension: the Nether and the End are identical; in the Overworld only bee nests differ, one block apart (they also move between two runs of the same jar), and 12 surface blocks (mud, sand), the same as with the Fabric jar on those versions.
• A player in the area: with skip_existing_chunks=false, a test client standing in the middle of a run got all 81 chunks around it sent again with the regenerated blocks, on all five versions; with the default, none. No error in any log.
• Chunks the server holds during a run on 1.20.1 and 1.20.4: 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,374 and 1,375 of the 1,408 chunks had the same blocks.
• skip_existing_chunks=false through the commands on 1.20.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.20.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