Hytale MaxViewRadius Is Hard-Capped at 32 — And the Official Server Docs Nobody Noticed

You read a hosting blog, opened config.json, set MaxViewRadius to 48, and told your Discord that render distance was now bigger. Maybe you even felt a difference. Here is the awkward part: Hytale now ships official server documentation, and it puts a hard ceiling on that value. The ceiling is 32 — with an engineering rationale attached that says, in plain English, that a larger server value buys you nothing. This is not a gotcha aimed at whoever wrote that guide — nearly all of that advice predates the documentation. The point is simpler: the argument is now settled by a primary source you can open yourself, and the same docs quietly expose most of the hytale server config surface for the first time. It is the most useful thing to come out of Update 6 Part 9, and nobody noticed, because it shipped as a one-line footnote under "Documentation Site Update". Wait, Hytale Has Official Server Docs Now? It does, and the announcement was easy to miss. The Update 6 pre-release patch notes for Part 9, dated July 23, 2026, said this and nothing more: "Documentation Site Update — We have updated our documentation site with a new theme and new domains. You can now find our documentation at https://pre-release.docs.hytale.com and https://docs.hytale.com" Sandwiched between a hardcore mode reveal and a pile of bug fixes, that read like housekeeping. It was not. The rebuilt stack includes generated Javadoc for the server itself — every configuration class, every launch option, and a machine-generated constants page listing the compiled-in values. The API overview calls itself "API documentation for the Hytale server: plugins, assets and everything the server exposes to mods" and points at three starting packages — com.hypixel.hytale.server.core.plugin, com.hypixel.hytale.component (the ECS) and com.hypixel.hytale.event — so plugin developers found it quickly. Server owners never got the memo, because the part that matters to them is not in the plugin packages at all. It is HytaleServerConfig, documented as "the configuration file containing the configuration values for HytaleServer and all ServerModule's." That is your hytale config.json, documented. If you read our Part 9 coverage for the gameplay changes, this is the line underneath it that turned out to matter more. The Quote That Settles MaxViewRadius HytaleServerConfig carries a constant called MAX_VIEW_RADIUS_LIMIT. Here is its field documentation, verbatim: "Hard ceiling on the configured MaxViewRadius. SphereOffsets.build(int) is O(R³), so an unbounded value would let a misconfigured (or hostile) config.json trigger a multi-gigabyte allocation on first chunk tracking. Matches the client's sphere-radius cap (MapModule.MaxClientSphereChunkRadius); a larger server value buys nothing because the client clamps its own sphere to that radius." Read it twice — there are three separate claims in there and each one matters. It is a hard ceiling, not a recommendation. The word used is "hard". The docs do not publish what happens when you exceed it — clamp, reject, error on boot — so we will not guess. What is documented is that the ceiling exists and its value is 32. The reason is memory, and it is cubic. SphereOffsets.build(int) is O(R³): the precomputed list of chunk offsets inside the view sphere grows with the cube of the radius, which is why an unbounded value is described as a path to a "multi-gigabyte allocation on first chunk tracking". The jump people casually recommend, 32 to 48, is not a 50% increase in anything that costs money — it is roughly 3.4x the volume. And the client clamps anyway. This is what turns "risky" into "pointless". The server-side cap matches the client's own sphere-radius cap, so even if you could push the server higher, every client would clamp its sphere back down — you would pay the memory cost to deliver a radius no player can see. One caveat rather than paper over it: MapModule.MaxClientSphereChunkRadius appears only inside that doc comment, is client-side, and is not a documented public API. Treat it as the author explaining their reasoning, not a second source. The Numbers, From the Constants Page The generated constant values page is the most useful page in the whole docs stack for a server admin, and the least linked. These are compiled-in values, not someone's blog post: ConstantValueWhat it means for you HytaleServerConfig.DEFAULT_MAX_VIEW_RADIUS32What you get if you never touch the setting HytaleServerConfig.MAX_VIEW_RADIUS_LIMIT32The hard ceiling. Same number. HytaleServerConfig.VERSION4Config schema version HytaleServer.DEFAULT_PORT5520Default bind port RateLimitConfig.DEFAULT_PACKETS_PER_SECOND2000Per-connection packet budget RateLimitConfig.DEFAULT_BURST_CAPACITY500Token bucket burst allowance BackupConfig.DEFAULT_FREQUENCY_MINUTES30How often worlds back up by default BackupConfig.DEFAULT_MAX_COUNT5Rolling backups retained BackupConfig.DEFAULT_ARCHIVE_MAX_COUNT5Archived backups retained UpdateConfig.DEFAULT_CHECK_INTERVAL_SECONDS3600Update check cadence CrashRecoveryConfig.DEFAULT_MAX_ATTEMPTS3Reload attempts before fallback CrashRecoveryConfig.DEFAULT_RETRY_DELAY_SECONDS5Pause between reload attempts CrashRecoveryConfig.MAX_ATTEMPTS_LIMIT100Ceiling on attempts CrashRecoveryConfig.RETRY_DELAY_SECONDS_LIMIT3600Ceiling on retry delay WorldMapConfig.ABSOLUTE_MAX_VIEW_RADIUS512World map only. Not chunk streaming. Notice the first two rows. The default and the maximum are the same number. That is the most practical fact in this article, and it reframes the setting entirely: MaxViewRadius is not a dial you turn up. Out of the box you are already at the ceiling, and the only direction it goes is down. The 512 That Is Probably Causing All the Confusion Now look at that last row. WorldMapConfig.ABSOLUTE_MAX_VIEW_RADIUS is 512, and it is a different thing entirely: it belongs to the world map, not chunk streaming. Skim a constants page looking for "max view radius" and you find a 32 and a 512 a few lines apart — easy to walk away believing the cap is far higher than it is. We suspect that is at least part of where "the range is 1-64" came from. The rule of thumb: if the number came from a class with "Map" in the name, it is not your render distance. For the record: BisectHosting publishes "How to Change the Max View Distance on a Hytale Server"; a widely-mirrored community docs page at hytale-docs.pages.dev/server/performance/ lists MaxViewRadius options as "16, 24, 32 (default), 48"; several config generators offer a 48 or a 64. None of those authors were careless — they wrote into a vacuum, before any of this was published. The docs simply arrived and settled it. So What Should You Actually Set? Since 32 is both the default and the ceiling, tuning MaxViewRadius means one thing: lowering it deliberately, and knowing what you are buying. Because the cost is cubic, cuts pay off faster than most admins expect — going from 32 to 24 is not a quarter off, it removes closer to 58% of the sphere volume, and 16 leaves about an eighth. On a memory-pressured box this is the highest-leverage number in the file, and it only works downward. Two caveats. View radius is a gameplay setting as much as a performance one: a survival server full of sprawling bases feels genuinely worse at 16, while a minigame server on a small arena will never notice. And change it in isolation, then measure — our server console tuning guide covers reading the live numbers so you can tell whether it helped, instead of changing five settings at once and declaring victory. Long sightlines are exactly what view radius pays for — and exactly why the cost scales with the cube of the number. This is a general official Hytale screenshot, not a render-distance comparison. How the sphere actually gets built One more quote, because it kills a common worry. getMaxViewSphereOffsets() returns "the shared SphereOffsets list built for the server's maximum-allowed view radius. Used by per-player SphereSpiralIterator instances; each iterator clamps this list to its own (smaller-or-equal) radius via a binary search at init... Building is a one-shot cost in the low milliseconds." So the expensive list is built once for the whole server and shared, and players clamp down from it. Your radius costs a one-time build plus the memory that list occupies — not a per-player CPU tax scaling with player count. What Else the Docs Just Exposed The accessors on HytaleServerConfig map out the top-level shape of the file: ServerName, Motd, Password, DisplayTmpTagsInStrings, MaxPlayers, MaxViewRadius, Defaults, ConnectionTimeouts, RateLimitConfig, Modules, LogLevels, ModConfig, DefaultModsEnabled, ModLoadOrder, PlayerStorageProvider, UniverseResourceStorageProvider, AuthCredentialStoreProvider, UpdateConfig, BackupConfig, FallbackServer and WorldMapConfig. The file is parsed by CODEC, a BuilderCodec. Four of these deserve attention on their own. Connection timeouts — the real cause of "players time out joining my modded server" TimeoutProfile is documented as "configuration for connection timeouts at various stages of the connection lifecycle. Each stage has a single timeout value used for both Netty read timeout and stage completion. Singleplayer defaults are more lenient since local connections don't need DoS protection." Twelve stages, and the list is the useful part: Initial (waiting for the Connect packet), AuxStreamPending, Auth, AuthGrant, AuthToken, AuthServerExchange, Password, Play (idle timeout during gameplay), SetupWorldSettings, SetupAssetsRequest, SetupSendAssets (sending assets) and SetupAddToUniverse. Now look at SetupSendAssets on a heavily modded server. Every joining player receives your asset pack before entering the world, and if that transfer misses its budget the join fails — which to the player looks identical to the server being down. Owners spend weeks blaming their host, their firewall or a player's ISP for what is really an asset payload outgrowing a stage timeout. Knowing the stage has a name is most of the fix. (No numbers here: the values are runtime Durations, not published constants, so any table of "correct" timeouts elsewhere is a guess.) Rate limiting RateLimitConfig is "configuration for packet rate limiting using a token bucket algorithm", with isEnabled(), getPacketsPerSecond() (2000) and getBurstCapacity() (500). Token bucket means burst capacity absorbs legitimate spikes — mass respawns, a big teleport, everyone loading in after a restart — while the sustained rate stops abuse. If players desync during exactly those moments, this is the pair to look at. Backups, and a precedence rule worth memorising BackupConfig is "configuration for automatic world backups. Settings can be overridden by command-line options (Options take priority)." Defaults: every 30 minutes, 5 rolling backups, 5 archives. That parenthesis is the important bit. Command-line options beat config.json. On a managed host, your panel may inject flags you never see, silently overriding the file. The docs anticipated the confusion: BackupConfig exposes both getDirectory() and getDirectoryConfig(), the latter returning "the raw directory string from config, ignoring CLI" — two accessors for one setting, precisely so you can see which layer won. If your backups are not where you think, that is your answer. Auto-update UpdateConfig.AutoApplyMode has three documented values: DISABLED — "Never auto-apply."; SCHEDULED — "Apply after AutoApplyDelayMinutes even with players online (warns them first)"; and WHEN_EMPTY — "Apply automatically when no players are online". Alongside them sit getPatchline(), isNotifyPlayersOnAvailable(), isRunBackupBeforeUpdate() and getCheckIntervalSeconds() (3600). For a community server, WHEN_EMPTY plus isRunBackupBeforeUpdate() keeps you current without interrupting a session, and getPatchline() is how you stay on pre-release or off it — worth being deliberate about, given everything here is pre-release surface. Crash recovery CrashRecoveryConfig is now the best-documented block in the file — see our CrashRecovery configuration guide for which Mode fits which hosting setup and the double-recovery trap when systemd or Docker already restarts your process. The docs add two ceilings the patch notes never mentioned: MaxAttempts tops out at 100, RetryDelaySeconds at 3600. Launch Options: What Is Actually Confirmed There is a documented Options class — "contains all the command line options that are parsed and can be received from OptionSet" — built on joptsimple. Here is where other guides go wrong, so: we are not printing a flag table. The Javadoc documents option behaviour without always publishing the literal string you type. The only spellings we can confirm are --log (example given: --log FINE,PacketLogging:OFF,WorldGenerator:OFF), -b for binding (-b 5520 or -b 127.0.0.1:5520), and the constant "allow-op". For everything else, run java -jar HytaleServer.jar --help against your own build — authoritative for the JAR you are actually running, which a blog post can never be. The behaviours worth knowing: BOOTSTRAP "runs the server in bootstrap mode, loading only the minimal plugin set required to authenticate and download the full server payload (JAR, assets, launcher scripts) into the current working directory. Intended for first-run installs where the user has just the HytaleServer.jar." It implies bare mode, which isBare() describes as skipping "loading worlds, binding ports, and creating stray directories on disk" — exactly what you want for a CI step that should not touch a live install. DISABLE_ASSET_COMPARE "can reduce the asset reload time on the server but may cause assets that have unchanged data... to be sent in updates" — a real speed-up for a tight iteration loop, but development convenience, not a production setting. And ALLOW_SELF_OP_COMMAND_STRING = "allow-op" controls whether /op self exists, documented as "intended for devs and cowboy server admins". Do not be the cowboy on a public box. The Best Feature in the Docs: Generate Your Own Schema Options exposes GENERATE_CONFIG_SCHEMA and GENERATE_ASSET_SCHEMA, each taking a filesystem path. That means you can generate a JSON schema for your exact build — every key, every type, as the server you are running understands them. That is the correct end to any argument about config keys, including this one. Documentation drifts and pre-release builds move weekly, but a schema generated from your own JAR cannot be out of date, and wired into your editor it gives you validation and autocomplete on config.json instead of a redeploy-and-pray loop. If you already run a build pipeline (our Maven and CI/CD guide covers setting one up), dumping the schema on every build is close to free. A Word on Which Docs You Are Reading Both domains from the announcement are live, and they are not the same. pre-release.docs.hytale.com serves 0.6.0-pre.10, matching the newest artifact on Hytale's Maven repository (last updated July 30, 2026); docs.hytale.com still serves Hytale Server API 0.5.4, three releases behind stable 0.5.7. Pre-release numbering maps onto the patch notes — 0.6.0-pre.N is "Update 6 Part N", so 0.6.0-pre.10 is the Part 10 build. Everything here comes from the pre-release docs. Check the version string on any page before you trust a number from it. What the Docs Still Don't Tell You Generated Javadoc is a reference, not a manual, and it shows. Straight about the gaps: What actually happens if you exceed the cap. No error string, no documented behaviour. Clamp, reject, refuse to boot — unknown. Anyone telling you which is guessing. The literal JSON key names for most of the file. The accessors give you the shape, not the spelling. Confirmed keys are the CrashRecovery set — CrashRecovery, Mode, MaxAttempts, RetryDelaySeconds, Fallback, GameModeTypeOnDeath — plus whatever the Asset Reference renders. For the rest, generate the schema. Numeric timeout defaults (runtime durations, not constants) and a full CLI reference (use --help on your build). Any guidance at all. Javadoc tells you a field exists and what it is called. It will never tell you that 24 is a sensible view radius for a 60-player survival server. That part is still on us, and on you. The Short Version Four things. 32 is the cap and also the default, so the setting only goes down. The cost is cubic, making reductions unusually effective and increases unusually expensive. 512 belongs to the world map, not chunk streaming, and confusing the two is probably where the bad numbers came from. And your own JAR is the final authority — --help for flags, GENERATE_CONFIG_SCHEMA for keys. None of this is exotic tuning. It is the unglamorous work that separates a server people stay on from one they quietly leave — the same category as understanding how cubic chunks changed world height before planning a build project around it. Once it is done, make sure people can find you: keep your HytaleCharts listing current with a live heartbeat reporting real player counts, so the performance you just tuned for shows up where players are choosing.