Best Hytale Server Settings for Large Multiplayer Communities

Best Hytale Server Settings for Large Multiplayer Communities

Running a Hytale server for a few friends needs almost no tuning. A community of 50 or 100 players does: terrain generation, entities and view distance decide how the server holds up. This guide lists the settings the server really has, read from the server files of build 0.7.3, and what each one does. Nothing here is a made-up number: where a default exists, it is the shipped default.

Prefer to see it in a panel? This two-minute video walks through every setting on a Supercraft Hytale server. Our servers start with a view radius of 10 and backups every 60 minutes, keeping 24; the game's own defaults are the ones listed below.

The Two Config Files

There are two kinds of settings file. config.json sits in the server's working directory and holds server-wide settings. Each world has its own config.json in universe/worlds/<name>/ with that world's rules. Stop the server before editing either by hand, keep valid JSON (a missing comma stops the server starting), and back up the file first.

The main server-wide keys are ServerName, MOTD, Password, MaxPlayers (default 100), MaxViewRadius (default 32), RateLimit, ConnectionTimeouts, Backup, Mods and Defaults (the default world name and game mode).

Since 0.7.3 there is also SentryDsn, for the server's error reports. Left out, the server reports its errors to Hytale's own Sentry as before. Set to the DSN of your own Sentry project, the errors go there instead, errors from third-party plugins included. Set to an empty string, error reporting is off. A DSN that Sentry cannot parse logs a warning and leaves reporting off, and the --disable-sentry start option turns it off whatever the key says.

View Distance

Chunk loading is the heaviest job a voxel server has: for every player the server loads, generates and streams the chunks around them. MaxViewRadius in config.json caps the view radius in chunks (a chunk is 32 blocks wide). The default is 32 and values from 1 to 32 are accepted; anything outside that range is clamped with a warning in the log.

{
  "MaxViewRadius": 12
}

A radius of 12 chunks is 384 blocks, and for a big server it is a sensible ceiling: it costs far less memory and CPU than 32 while looking good. Lower it further if the server struggles when many players spread out.

Spawning, Ticking and Saving Per World

These keys are in a world's own config.json, and most can be changed while the server runs: /world settings <setting> shows a value, /world settings <setting> set <value> changes it and reset puts the default back. Add --world <name> for a world other than the one you are in. Setting names include spawningnpc, ticking and chunkunloading:

• IsSpawningNPC (on by default), IsBlockSpawnersEnabled, IsSpawnMarkersEnabled and IsAllNPCFrozen control NPCs and spawners. Switching spawning off in a hub or lobby world saves a lot of work.
• IsTicking and IsBlockTicking turn world ticking and block ticking on or off.
• IsUnloadingChunks lets unused chunks unload, and KeepLoadedRegion names a region that must never unload automatically, such as a spawn area (/world settings keeploaded).
• IsSavingChunks, SaveNewChunks and IsSavingPlayers control what gets saved.

To see what is using the server, /entity count prints the entity count in a world, and /world perf shows tick performance (/world perf graph draws it). If entities pile up, /npc clean and /entity clean remove NPCs and entities.

Tick Rate

Worlds tick at 30 ticks per second by default. /world tps <rate> changes it for one world (for example 30tps, 33ms or just 30) and /world tps reset goes back to the server default. Only change it after measuring with /world perf: a lower rate saves CPU on a quiet world, and a higher one costs more than it gives on most hardware.

Network

Hytale uses QUIC over one UDP port, set with --bind (5520 by default), so the server file has no TCP, buffer or compression settings. The setting that exists is RateLimit in config.json: Enabled, PacketsPerSecond (default 2000) and BurstCapacity (default 500). If players on busy builds are dropped, check this and the ConnectionTimeouts section before blaming the network.

Pre-Generating the World

Generating terrain is the most CPU-heavy thing a server does, so generating the area your players will use before they arrive pays off on a large server. The world setting PregenerateRegion names a region of chunks that is generated when the world starts. Set it from the console:

/world settings pregenerate set <minX> <minZ> <maxX> <maxZ>

The four numbers are block coordinates, the X and Z of two opposite corners; the server walks the area chunk by chunk at start and logs Pregenerated n/m chunks as it goes. /world settings pregenerate reset clears the region. Start with a small area to learn how long it takes, because the cost grows with the square of the radius. A generated region takes disk space, so plan for fast storage.

Saves and Backups

The server writes to disk as it runs and keeps its own backups when you ask. Start it with --backup, set the interval with --backup-frequency (minutes, default 30), the folder with --backup-dir, and how many to keep with --backup-max-count (default 5) and --backup-archive-max-count (default 5). The same options exist under Backup in config.json. /world save saves worlds on demand and /backup runs a backup now. Keep a copy of the backups off the machine.

Memory

Give the JVM a fixed heap, for example -Xms8G -Xmx8G for a mid-sized community, and leave RAM free for the operating system. The right size depends on view radius, player count and mods, so watch usage under real load; see the memory guide.

Conclusion

For a large community: cap MaxViewRadius, turn off what a world does not need, watch /world perf and /entity count, pre-generate the area players will use, and keep scheduled backups. No setting makes up for weak hardware. For a server with fast CPUs and NVMe storage, see Supercraft Hytale server hosting.