Stop Your Hytale Server Lagging on Chapter 1 Launch Day: Inside Nitrado's Open Source Performance Saver Plugin, Its TPS Limiter, Its Dynamic View Radius and Every Config Default

Chapter 1 ships on 12 October 2026, seven days from now, and the servers that fall over mostly will not fall over because of a bad host. They will fall over because a few dozen people join at once and then walk in a few dozen different directions, each one pulling chunks that have never been generated before. There is an open source plugin built for precisely that failure mode, and unusually for Hytale tooling right now, its entire configuration surface is documented. The plugin is hytale-plugin-performance-saver on GitHub. The LICENSE file is an MIT style grant and its copyright line reads "Copyright 2025 marbis GmbH", the operating company behind the host Nitrado. It is a third party plugin. It is not made, blessed or endorsed by Hypixel Studios, and nothing in it is part of the official server. One honesty note before anything else. Nobody at this site has run this plugin, so every figure below is a documented default lifted from the project README rather than a result we measured. There are no before and after numbers here because we have none, and where the official Hytale documentation says nothing, we report that silence rather than filling it in. The Short Version What it is for, in the README's own words: "This plugin ensures stability of a Hytale server by lowering the resource consumption of the server when it is under resource pressure." Four mechanisms. A TPS cap, a dynamic view radius that shrinks and recovers, a garbage collection monitor feeding that view radius logic, and a chunk driven garbage collection trigger. Install is one step. Drop the JAR in mods/. The config file at mods/Nitrado_PerformanceSaver/config.json writes itself with defaults on first startup. Everything is on by default. All four sections ship with Enabled: true. The TPS cap defaults to 20 with players online and 5 when empty. That 20 is the plugin's default. It is not a statement about Hytale's native tick rate, which we have not verified. The view radius floor is 2. Pressure multiplies the current radius by 0.75, recovery adds 1 at a time after a 60 second wait. It does not raise your ceiling. MaxViewRadius in the official server config still tops out at 32. The plugin works downward from whatever you set, never upward past it. The claim it makes for itself on the view radius work: "This measure is able to prevent resource-related server crashes even under stress test scenarios." That is the project's claim, not our test result. Why Hytale Servers Lag Under Load The README opens with the clearest statement of the problem we have read anywhere, and it is worth quoting in full because it cuts against the instinct most owners have: The resource usage of a Hytale server, even without mods, can fluctuate heavily based on player behavior. For example, a large group of players in a small area has a relatively small resource footprint, whereas a small amount of players each independently exploring the world can cause a significant amount of CPU load and RAM consumption. Read that twice if you are provisioning hardware this week. Your worst case is not your peak player count. It is your peak spread. Forty players at a spawn hub are cheap. Eight players each cutting a fresh path through unexplored terrain are expensive, because every one of them is a separate chunk generation workload with its own memory footprint. That is exactly the shape of a launch week. New world, no generated terrain, everybody exploring, nobody yet settled. Our Chapter 1 server preparation checklist covers the rest of the launch day work, and the release date piece covers the timing. This article is only about what happens when the load arrives. The second argument follows from the first: hardware sized for the rare worst case sits idle almost all the time, and hardware sized for the average goes down in the rare case. The plugin's answer is to degrade gracefully instead of buying for it. What the Performance Saver Plugin Actually Does Installation is genuinely one step: place the plugin JAR into your server's mods/ folder. On first startup it creates mods/Nitrado_PerformanceSaver/config.json populated with defaults, so you can start the server once, stop it, and edit a real file rather than writing one from scratch. From there, four things run on timers. Three are listed in the README as the plugin's main features, and the fourth, the garbage collection monitor, is a detector feeding the view radius logic. All four are independently switchable, which matters more than it sounds: if you want the crash protection and not the TPS cap, you can have exactly that. TPS Limiting Explained The reasoning here is counter intuitive and the README states it plainly: Based on how networking and client prediction work, lower, but stable TPS is generally better for the player experience than high, but fluctuating TPS. So the plugin caps TPS rather than chasing the highest number it can reach. The default cap is TpsLimit: 20 with players online, dropping to TpsLimitEmpty: 5 when the server is empty, after EmptyLimitDelaySeconds: 300. Those five minutes stop a server throttling itself in the gap between one player leaving and the next joining. Be careful with what 20 means. It is the plugin's default ceiling, nothing more. It is not documentation of Hytale's native tick rate, and any blog that converts it into a statement about how Hytale ticks has made that leap on its own. OnlyWorlds is the option most owners will reach for. Left empty it applies to every world. Populate it and the TPS adjuster touches only those, with "__DEFAULT" referring to the server's default world. If you run a hub plus themed worlds, that is how you cap the heavy one without throttling the lobby. Dynamic View Radius, and the Ceiling of 32 It Does Not Touch This is the mechanism doing the real crash prevention work, and the README describes its detection half in one sentence: "The plugin detects CPU pressure through low TPS, and RAM pressure by observing the JVM's garbage collection attempts." If either detector fires, the view radius comes down. When pressure clears, it goes back up gradually. The numbers are asymmetric by design. Decreasing multiplies the current radius by DecreaseFactor: 0.75, so it falls in proportional steps and falls fast. Increasing adds IncreaseValue: 1 per step, and only after RecoveryWaitTimeSeconds: 60. Fast down, slow up. That is the right shape for a safety valve: you want relief immediately, and you do not want the server oscillating by rushing back to a setting that just hurt it. The floor is MinViewRadius: 2, a deliberately grim view distance, because a short view distance beats a crash. Now the distinction that gets mangled most often. The official server config has a MaxViewRadius setting with a hard ceiling of 32, which we documented in our piece on MaxViewRadius in the official docs. This plugin does not raise that ceiling and does not interact with it. It changes the effective radius at runtime, downward, from wherever your configured value sits, toward MinViewRadius. If you set 32 and your hardware cannot sustain it, the plugin will quietly run you at less than 32 under load and return you toward it afterwards. The ceiling is a configuration limit. The plugin operates on the live value underneath it. One player facing detail: view distance change notifications go to everyone by default, because RequireNotifyPermission is false. Set it to true and only players holding nitrado.performance_saver.notify.increase or nitrado.performance_saver.notify.decrease see them. The TPS monitor watermarks are ratios, not tick counts The TPS detector uses two thresholds: TpsWaterMarkHigh: 0.75, above which the view radius may recover, and TpsWaterMarkLow: 0.6, below which it decreases. The README calls both a "TPS ratio". They are ratios, not absolute tick figures. 0.6 does not mean 0.6 TPS, and we will not multiply them by anything to produce an absolute number, because that needs a native tick rate we have not verified. The gap between the two is itself the anti oscillation margin, and AdjustmentDelaySeconds: 20 adds a cooldown on top. The garbage collection monitor The memory detector watches the JVM rather than the game. It fires when heap usage crosses HeapThresholdRatio: 0.85 on TriggerSequenceLength: 3 consecutive high heap garbage collection events inside a WindowSeconds: 60 window. The three in a row requirement separates a real memory problem from one unlucky spike. Additional Garbage Collection The fourth mechanism is separate from the view radius work and rests on a blunt observation: "Java generally does not free up unused memory on its own." So the plugin watches loaded chunk counts, and when the count drops sharply it concludes that a lot of memory is now garbage and asks the JVM to collect it. The trigger is ChunkDropRatioThreshold: 0.8, a chunk reduction ratio, and it will not act below MinChunkCount: 128 loaded chunks, which stops it churning on a near empty server. GarbageCollectionDelaySeconds: 300 enforces five minutes between triggered collections. That last number matters most, because a forced collection is not free and a plugin firing them in a loop would be its own performance problem. Leave this section alone unless you have a specific reason not to. The Full config.json Reference Every option and every default from the README, in one place. The file lives at mods/Nitrado_PerformanceSaver/config.json. Tps OptionTypeDefaultWhat it does EnabledbooleantrueEnable or disable TPS limiting. TpsLimitinteger20Maximum TPS when players are online. TpsLimitEmptyinteger5TPS limit when no players are online. OnlyWorldsstring array[]Restrict TPS adjustment to specific worlds. Empty means all worlds. "__DEFAULT" refers to the server's default world. InitialDelaySecondsinteger30Delay before TPS adjustment starts. CheckIntervalSecondsinteger5How often to check and adjust TPS. EmptyLimitDelaySecondsinteger300Delay before applying the empty server TPS limit. ViewRadius OptionTypeDefaultWhat it does EnabledbooleantrueEnable or disable dynamic view radius adjustment. MinViewRadiusinteger2Minimum allowed view radius. DecreaseFactordouble0.75Factor the current view radius is multiplied by when decreasing. IncreaseValueinteger1Amount the view radius increases by when recovering. InitialDelaySecondsinteger30Delay before view radius adjustment starts. CheckIntervalSecondsinteger5How often to check resource pressure. RecoveryWaitTimeSecondsinteger60Time to wait before attempting to increase the view radius. RequireNotifyPermissionbooleanfalseSend view distance notifications only to players with nitrado.performance_saver.notify.increase or nitrado.performance_saver.notify.decrease. ViewRadius.GcMonitor OptionTypeDefaultWhat it does EnabledbooleantrueEnable or disable garbage collection based pressure detection. HeapThresholdRatiodouble0.85Heap usage ratio threshold that triggers pressure detection. TriggerSequenceLengthinteger3Number of consecutive high heap garbage collection events needed to trigger adjustment. WindowSecondsinteger60Time window for analysing garbage collection events. ViewRadius.TpsMonitor OptionTypeDefaultWhat it does EnabledbooleantrueEnable or disable TPS based pressure detection. TpsWaterMarkHighdouble0.75TPS ratio above which the view radius can recover. TpsWaterMarkLowdouble0.6TPS ratio below which the view radius should decrease. OnlyWorldsstring array[]Restrict TPS monitoring to specific worlds. Empty means all worlds. "__DEFAULT" refers to the server's default world. AdjustmentDelaySecondsinteger20Delay between TPS triggered adjustments. ChunkGarbageCollection OptionTypeDefaultWhat it does EnabledbooleantrueEnable or disable chunk based garbage collection triggering. ChunkDropRatioThresholddouble0.8Chunk reduction ratio threshold that triggers a collection. MinChunkCountinteger128Minimum loaded chunk count before triggering is considered. GarbageCollectionDelaySecondsinteger300Minimum time between triggered collections. InitialDelaySecondsinteger5Delay before chunk monitoring starts. CheckIntervalSecondsinteger5How often to check chunk counts. How to Tune It for Chapter 1 Launch Day Everything in this section is reasoning from the documented behaviour, not a benchmark. Weigh it accordingly, and test on your own box before launch rather than on launch. Install it this week, not on 12 October. Start the server once to generate the config, then read the file it wrote rather than trusting any article, including this one, about what your version defaults to. Change nothing on the first run. All four sections are enabled by default and the defaults are internally consistent. A plugin you have observed untouched is worth more than one you tuned blind. Decide about MinViewRadius deliberately. A floor of 2 trades a lot of visual quality for survival. Raise it and you accept more crash risk. That is a decision about your community, not a technical one. Use OnlyWorlds if you run more than one world. Launch load will not be evenly spread, and both the TPS adjuster and the TPS monitor take the list. Set RequireNotifyPermission to true before a public launch unless you want every player watching the view distance move. Unexplained messages in a busy first hour read as the server breaking, and first impressions are what our piece on why players leave servers is about. Leave the delays and intervals alone. The 5 second checks, the 30 second initial delays and the 300 second empty and collection delays are damping, and tightening damping turns a smooth system into a flapping one. Do not treat this as a substitute for sizing. If your host is too small, the plugin keeps you alive at a view radius nobody enjoys. Our self hosted versus managed hosting guide covers sizing, and the server setup guide covers everything upstream of it. Keep your crash handling in place anyway. The plugin's own claim is about preventing resource related crashes. There are other kinds. Our crash recovery config guide stays relevant. What the Official Hytale Docs Do Not Cover This is a verified negative finding, so here is the method rather than just the conclusion. We searched the official API documentation on docs.hytale.com at release 0.6.8 for five terms: TPS, tick rate, ticksPerSecond, viewRadius and view radius. Every one of those five returned zero hits. The official documentation therefore describes no runtime surface for reading or setting tick rate, and none for reading or adjusting view radius while the server is running. The static MaxViewRadius config key exists and is documented, with its ceiling of 32, but a config key is not a runtime API. The practical consequence: a third party plugin is currently the published route to runtime TPS and view radius control, with no documented first party equivalent to compare it against. Our coverage of Update 7 Part 5 is the latest on pre-release builds, and nothing in it changes that. What We Could Not Verify Hytale's native tick rate. We do not know it and we are not printing a figure. TpsLimit: 20 is a plugin default. Third party host blogs disagree, some stating 20 and others claiming a 30 TPS target, and no official source we checked states either. Until one does, any absolute TPS number you read about Hytale is somebody's assumption. Any performance gain. We have not run this plugin. There are no before and after numbers in this article because we have none. The line "This measure is able to prevent resource-related server crashes even under stress test scenarios" is the project's claim about its own stress tests, quoted as a claim. Repository metadata. Stars, downloads and release dates are absent on purpose. The GitHub API returned HTTP 403 through our proxy, so we could not verify any of it. Absolute values for the watermarks. 0.75 and 0.6 are ratios per the README. Converting them to tick counts needs a native tick rate, which is the first item on this list. How it behaves on Chapter 1 builds. The copyright line reads 2025. We have not confirmed compatibility with the 12 October build, and neither has anybody else we can cite. Test it yourself. Nitrado's exact relationship to the project. What we can state is narrow: the repository sits under the nitrado GitHub organisation and the licence copyright line reads "Copyright 2025 marbis GmbH". We are not characterising it further. Frequently Asked Questions Why does my Hytale server lag when only a few players are online? Because spread costs more than headcount. The README puts it directly: a large group in a small area has a relatively small resource footprint, while a small number of players each independently exploring the world can cause significant CPU load and RAM consumption. Eight players exploring in eight directions can be heavier than forty standing together. What TPS does a Hytale server run at? We do not know, and we have not found an official source that states it. The Performance Saver plugin defaults its cap to 20 TPS, but that is the plugin's own default ceiling and not documentation of Hytale's native tick rate. A search of the official API documentation at release 0.6.8 for TPS, tick rate and ticksPerSecond returned no hits at all. Does the Performance Saver plugin let me set a view radius above 32? No. MaxViewRadius in the official server config has a hard ceiling of 32 and the plugin does not change that. It adjusts the effective view radius at runtime in the other direction, downward from your configured value toward MinViewRadius, which defaults to 2, and then raises it back by 1 per step once pressure clears. Is the Hytale Performance Saver plugin official? No. It is a third party open source plugin published under the nitrado GitHub organisation, with an MIT style licence whose copyright line reads "Copyright 2025 marbis GmbH". It is not made or endorsed by Hypixel Studios. Will this fix a Hytale server memory leak? It is pressure management, not a leak fix. The plugin observes the JVM garbage collector to detect memory pressure and reduces the view radius in response, and separately triggers extra collections when loaded chunk counts fall sharply, on the stated basis that Java generally does not free up unused memory on its own. If your memory growth is a genuine leak in your own mod, this buys you time rather than solving it. Where is the config file and do I have to write it myself? It is at mods/Nitrado_PerformanceSaver/config.json and it writes itself. If the file does not exist it is created with default values on first startup, so start the server once and edit the file it produced. Should I change the defaults before Chapter 1 launch day? Mostly no. Everything ships enabled and the delays are deliberate damping. Two settings are worth a decision: MinViewRadius, because a floor of 2 is a harsh view distance, and RequireNotifyPermission, which you probably want on a public server so players are not shown view distance messages all launch evening. The Bottom Line Seven days out, this is a rare piece of Hytale server tooling documented well enough to act on. Every option has a stated type, default and purpose, and the asymmetry between a fast decrease and a slow recovery is the mark of somebody who has watched a server oscillate and did not enjoy it. What it is not is a benchmark, an endorsement or a substitute for right sized hardware. We have not run it. The 20 in TpsLimit tells you about the plugin and nothing about Hytale, the watermarks are ratios, and the official documentation still exposes no runtime TPS or view radius surface at all. That gap is the real story: on 12 October, the published answer to resource pressure on a Hytale server is a plugin from a hosting company, not anything from the game. Install it this week, read the config it generates, and decide one thing deliberately: how ugly you are willing to let the view distance get in exchange for staying up. Running a Hytale server through launch? Add your server to the HytaleCharts list and get it in front of players.