ServerBuilder provides a fluent API for constructing a ServerConfig:
| Field | Type | Default | Description |
|---|---|---|---|
address |
String |
"127.0.0.1:25565" |
TCP bind address |
tick_rate |
u64 |
20 |
Game ticks per second |
max_players |
i32 |
100 |
Maximum player count (shown in server list) |
view_distance |
i32 |
10 |
Maximum server-side view distance (in chunks) |
simulation_distance |
i32 |
10 |
Simulation distance sent to clients |
game_mode |
u8 |
1 (Creative) |
Default game mode (0=Survival, 1=Creative, 2=Adventure, 3=Spectator) |
spawn_position |
SpawnPosition |
{ x: 0.0, z: 0.0, y: None } |
World spawn location |
spawn_chunk_radius |
i32 |
10 |
Radius of pre-generated chunks around spawn |
initial_chunk_radius |
i32 |
3 |
Chunks sent to players during join (before streaming takes over) |
motd |
String |
"Welcome to Void Server!" |
Message of the day (shown in server list) |
hardcore |
bool |
false |
Hardcore mode flag |
metrics_debug |
bool |
false |
Enable TPS metrics collection and file output |
metrics_tps_output |
Option<String> |
None |
Optional TPS CSV output path (defaults to logs/tps-<timestamp>.csv) |
max_packets_per_tick |
usize |
1000 |
Cap the number of packets drained from the incoming channel each tick (0 = unlimited) |
packet_ingest_budget_ms |
u64 |
4 |
Time budget in milliseconds for packet ingest per tick (0 = unlimited) |
max_chunk_generations_per_tick |
usize |
8 |
Cap the number of new chunks generated per tick (0 = unlimited) |
slow_tick_ms |
u64 |
200 |
Log a warning when a tick exceeds this duration (ms) |
world_generator |
Box<dyn WorldGenerator> |
DefaultWorldGenerator |
Terrain generation implementation |
registries |
RegistryDataStore |
RegistryDataStore::default() |
Minecraft registry data sent during configuration |
When y is None (the default), the server automatically computes the spawn Y coordinate by calling WorldGenerator::surface_height_at(x, z) + 1. This ensures players always spawn on top of the terrain.
At runtime, a ServerConfigResource is inserted into the Bevy world as a plain-data ECS resource (no Box<dyn> fields). Systems and command handlers can read it:
Fields mirror ServerConfig except that SpawnPosition is flattened into spawn_x, spawn_z, and spawn_y: Option<f64>, and the world generator and registries are stored as separate resources (WorldGen and RegistryDataStore).