Configure view distance and simulation distance in Paper

Why these two settings matter

These settings control different parts of chunk processing:

• what the client can receive from the server
• what the server actively simulates and ticks

That is why view-distance and simulation-distance are not the same knob.

What Paper says

Paper documents:

• view-distance as the amount of world data the server sends the client
• simulation-distance as the maximum distance where living entities are updated by the server

If your problem is heavy entity ticking or active game logic, simulation-distance usually matters more than view-distance.

Safe starting values

For many small servers, these are reasonable starting points:

Test these starting values with your player count, farms, and hardware.

When to lower simulation-distance first

Start here if:

• villagers or mobs dominate tick time
• farms are heavy
• bases with many entities cause lag
• Spark points to server-side activity rather than pure network or chunk send cost

Example:

view-distance=10
simulation-distance=5

This often preserves the feel of the world better than cutting both values harshly.

Set the values in Docker Compose

With itzg/minecraft-server, keep the Compose environment as the source of truth:

services:
  mc:
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
      VIEW_DISTANCE: "10"
      SIMULATION_DISTANCE: "5"

Apply the changed service configuration and verify the effective values:

docker compose up -d
docker compose exec mc grep -E '^(view|simulation)-distance=' /data/server.properties

If these environment variables are present, do not also maintain different values manually in server.properties; the next container start can make the Compose values effective again.

When to lower view-distance as well

Lower view-distance if:

• exploration or wide terrain visibility is expensive
• player count is rising
• the server is spending too much effort sending chunk data

A practical second step:

view-distance=8
simulation-distance=5

How to test changes correctly

Test while players reproduce the activity that caused lag.

Use this sequence:

1. capture a baseline with Spark
2. change one setting
3. recreate or restart the service so the setting is active
4. verify the effective value in server.properties
5. reproduce the same load
6. compare the result

What not to do

Do not slash both to the minimum immediately

Yes, that may reduce lag. It may also create a worse player experience than necessary and hide the real bottleneck.

Do not use them as a substitute for profiling

These settings are safe first levers, not a substitute for understanding your workload.