Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
Why generation causes lag
When a player walks, flies, or teleports into ungenerated terrain, the server must create those chunks on the fly. Generating a chunk is real computational work: the world seed is fed through terrain, cave, and structure noise functions, biomes are resolved, and the result is written to disk. That work competes with the game tick for CPU time. If generation runs during active play, tick duration can exceed its 50 ms budget and the server drops below 20 ticks per second, producing the stutters players describe as 'lag'.
Exploration-heavy play is the classic trigger. Elytra travel, long boat voyages, random teleports, and players spreading out in different directions all force constant new chunk creation. Pre-generation reduces this by creating chunks ahead of time during a controlled maintenance window, when nobody is trying to play in that area, so the cost is paid once instead of mid-gameplay.
Pre-generation is disk- and time-intensive
Generating a large radius writes many chunk files and can take a long time. Confirm you have enough storage and that your plan supports the operation before starting. Victus storage limits, CPU behavior, and panel controls vary by product and plan — verify the current plan first.
How the chunk pipeline actually works
A useful mental model has three stages. Generation creates the chunk from the seed and writes it to the region files on disk. Loading reads an already-generated chunk back into memory when a player is near. Simulation ticks the active chunks according to the simulation distance. Pre-generation front-loads the first stage so that normal play mostly performs the cheaper loading and simulation stages, not the expensive generation stage.
- Generation is the expensive stage; pre-generation does it in advance.
- Loading from disk is cheaper than generating, but still costs I/O and memory.
- Simulation keeps active chunks ticking; distances control how many are active.
- Once a chunk exists on disk, exploring it should not trigger generation again.
Pre-generation vs runtime tradeoffs
Pre-generation is not free and is not always the right move. It trades upfront time and disk space for smoother later play. On a small private server where players rarely roam far, the cost may exceed the benefit. On a large survival server with frequent exploration, the opposite is true. The decision should follow how your players actually move, not a generic rule that 'more pregen is better'.
| Play style | Typical benefit | Watch out for |
|---|---|---|
| Exploration or survival with travel | Large reduction in exploration stutters | Disk usage and long first-run time |
| Build-focused, small area | Minor benefit | Probably not worth the time cost |
| Public server, many new players | Smoother first impressions | Must still size CPU and memory |
| Modded with worldgen mods | Avoids heavy on-demand worldgen | Generation can be far slower per chunk |
A controlled approach
- Take a verified backup before any world operation.
- Decide a practical radius based on how far players actually roam; bigger is not always better.
- Lower view and simulation distance during the pass if your software allows temporary changes.
- Run the generation while the server is quiet or empty to avoid compounding load.
- After completion, restore your normal distances and verify tick time with real movement.
- Keep the generated world backed up so the work is not lost on the next restore.
Choosing a radius that fits reality
A radius is the number of chunks (or blocks) generated around a center, often spawn. Reasonable radii vary widely: a few thousand blocks may cover a small friend group, while a large community may want tens of thousands. The disk footprint grows with the square of the radius, so doubling the radius roughly quadruples storage and time. Pick the radius that matches your players' real travel range, then stop — an enormous radius you will never visit wastes storage and may delay future maintenance.
If you use multiple worlds or dimensions, decide whether each needs pre-generation. The Nether and End have different travel scales than the overworld, and many servers pre-generate only the overworld plus a modest Nether border. Generate what players use, not every dimension by reflex.
Distances matter as much as pre-generation
Pre-generation does not eliminate the cost of simulating far areas. View distance controls how many chunks are sent to players; simulation distance controls how far game logic actively ticks. Keeping simulation distance modest and only pre-generating the area you expect players to use is usually more effective than generating an enormous radius you will never visit. A huge pre-generated world with an equally huge simulation distance can still create heavy tick load.
Measure distances against your plan
Higher distances increase both memory and CPU work per player. What counts as 'modest' depends on your real plan resources. Verify the current Victus plan limits and watch tick time as you adjust, rather than copying values from an unrelated server.
Storage, time, and plan limits
Before starting, check free disk space and estimate the footprint. Region files are compressed, but a large radius across multiple dimensions can still be substantial. Also estimate time: generation speed depends on CPU allowance, worldgen complexity, and whether other load is present. Running the pass during a quiet window reduces contention and makes the duration predictable. If the operation would exceed your storage, either reduce the radius or expand the plan first — do not generate until you are full.
Verification after the pass
Do not assume success because the command finished. After pre-generation, restart cleanly and have players move through the prepared area while you watch tick time. The meaningful test is exploring previously ungenerated space without generation spikes. If ticks stay healthy, the pass did its job. If you still see spikes, the radius may have been too small, players may be at its edge, or another cause (entities, plugins, redstone) is responsible.
- Confirm the generation task completed without errors in the log.
- Restart the server and restore normal distances.
- Have players walk or fly outward through the prepared area.
- Compare tick time inside prepared terrain versus beyond its border.
- Keep a backup of the generated world so the work survives a restore.
Combine pre-generation with lag diagnosis
Pre-generation is one tool in a larger lag-reduction strategy. Use the measurement habits from proper TPS diagnosis: watch tick time during exploration, not just average CPU. Pre-generation removes generation spikes, but entity counts, redstone, plugin overhead, and CPU limits can still cause lag. Treat pre-generation as a contributor to a healthy server, not a cure for every performance problem.