Configuring Vintage Story chunk loading and world generation for a small group

VS performance tuning often gets ported from Minecraft tutorials, which doesn't quite work. VS has its own knobs, in different places, with different effects.

This is a tour of the settings that actually matter for a small-group VS server, what each one does, and reasonable starting values.

Where the settings live

Most server-side performance settings are in:

~/.config/VintagestoryData/serverconfig.json
~/.config/VintagestoryData/Saves/<world>/worldconfig.json

serverconfig.json is global to the server. worldconfig.json is per-world.

The most impactful settings

TickTime

In serverconfig.json:

"TickTime": 33.333332

This is the target time between server ticks in milliseconds. VS's default is ~33.3 ms (about 30 ticks per second), faster than Minecraft's 20 TPS rhythm.

Raising this lets the server take longer ticks at the cost of a slower simulation pace. For a CPU-starved server, going from 33 ms to 37 or 40 can buy stability. Most players won't notice. Going past 50 (20 TPS) starts to feel sluggish.

MaxChunkRadius

In serverconfig.json:

"MaxChunkRadius": 12

This is the maximum chunk radius any client may request from the server. One VS chunk is 32 blocks, so a radius of 12 chunks is roughly 384 blocks of sight.

Players set their own view distance client-side (the .viewdistance command in chat, given in blocks) but cannot exceed this server cap. For small groups on solid hardware, 12 to 16 is comfortable. For struggling servers, drop to 8 or 10 and tell players why.

Mob spawn rate (via playstyle)

VS does not expose a single "mob multiplier" key in serverconfig.json. Mob density is set at world creation under the playstyle's creature-hostility and spawn-rate options. Once a world is generated, changing these is awkward; pick at creation.

For a tick-budget-constrained server, lower creature-hostility and spawn rates noticeably reduce mob AI cost. The trade is a less dense world.

Per-role land claim caps

Claim limits live inside each entry of the Roles array in serverconfig.json, not as a single top-level key. Each role has fields like MaxLandClaim and MaxLandClaimAreas that bound that role's total claimed volume and number of claims.

Larger claims that contain dense block entities (firepits, bloomeries, querns) cost real tick time. For large communities, tightening these caps on lower roles reduces the chance one player drags the whole server.

World generation settings

These are mostly set at world creation and hard to change later. Key ones:

LandformScale

Controls how big terrain features are. Default is fine for most worlds.

TemperatureVariance

How dramatically temperature changes by region. Higher means more biome variety; lower means more uniform climate.

OreDensity

Higher means easier mining, lower means more challenging progression. For a friend group that wants to "just play," default is fine. For a long-form server, lower density makes mining matter more.

TemporalStability

Leave it on. It's a core VS mechanic.

Performance levers, ranked by impact

Reasonable starting values

Server situation	MaxChunkRadius	TickTime	Mob spawn rate
Small group, modest hardware	10	33.3 (default)	moderate playstyle
Small group, strong hardware	14	33.3 (default)	default
Server struggling	8	37 to 40	low if world is new

A diagnostic process

If players complain about stutter or slow simulation:

1. Check the server console for tick-time warnings. VS logs when ticks exceed budget.
2. Use any VS profiler mod or in-game admin tools to identify hot chunks.
3. Visit those chunks. Are they near a player's high-activity base? Sometimes one player's setup is dragging the whole server.
4. Negotiate with the player or apply per-chunk soft limits.

Tools for VS server profiling are less matureTools for VS server profiling are less mature than Minecraft's. Manual investigation and reading logs is still common.

Common misconceptions

"More RAM = smoother server."

Not really. VS doesn't use a lot of RAM. Once you've allocated enough (4 to 8 GB for most servers), more doesn't help. CPU is the real lever.

"Lower view distance = less network."

True but small. View distance affects mostly loaded chunks (memory and tick) rather than network traffic, which is dominated by player actions and entity updates.

"Faster disk fixes lag."

Only if your disk was the bottleneck. SSDs are essentially mandatory; faster SSDs don't usually help further.

Don't tune blind

VS is sensitive to its world. A heavy-automation 8-player base loads differently than 8 players spread thin across a continent. Settings that "should" work in theory sometimes don't. Test under your actual load.

The right workflow:

1. Pick reasonable defaults from this article.
2. Play for a week.
3. Note any lag complaints; investigate.
4. Adjust the single most-impactful lever.
5. Re-evaluate.

Tuning is iterative.

Conclusion

VS performance tuning is its own art. The Minecraft instincts mostly transfer (less view distance, fewer mobs, fewer entities) but the specific knobs and their behaviors are different. Know which file each setting lives in, what each one trades, and don't make multiple changes at once.

A well-tuned VS server is a quiet gift to your players. They probably won't notice it. They will notice if you don't tune it.