Set networkViewDistance to 3000 in your Arma Reforger config and it will read 1600 the next time you look. That is not a bug and it is not the engine. On a Loafhosts server the value is clamped to 1600 on every start, because a high network view distance is one of the most reliable ways to make a busy server unplayable for everyone on it, and the setting looks harmless while doing it.
That clamp is a good introduction to Reforger tuning generally: most of the knobs that feel like “more is better” are trading server frame time for client convenience, and the trade gets worse as your player count rises. This guide covers the settings that actually move the needle, their real ranges, and what each one costs.
Measure Before You Change Anything
Tuning without a measurement is guessing, and Reforger gives you the numbers for free. The server logs performance statistics on an interval, which on a Loafhosts server is set by the Log FPS Interval startup variable and defaults to 600 seconds.
Read the server frame rate out of the console or logs first and decide what you are actually fixing:
- Server FPS is fine, players report rubber-banding and pop-in. This is a network streaming problem. The budget settings below are what you want.
- Server FPS drops as players join. This is simulation load. Look at AI count and view distance, not streaming budgets.
- Server FPS drops with no players. Something is wrong that tuning will not fix. Check the crash and error guide and your modlist.
- Frame time spikes in bursts rather than a steady low FPS. Usually spawning, teleporting or a mod doing work on a timer.
Tip: Server stats gives you live graphs rather than log scraping, which makes it much easier to correlate a dip with what was happening in game
View Distance: Two Settings, Very Different Costs
These two get confused constantly and they are not the same thing.
| Setting | Range | Default | Cost |
|---|---|---|---|
serverMaxViewDistance | 500-10000 | 1600 | Client rendering |
networkViewDistance | 500-5000 (capped 1600) | 1500 | Server CPU + bandwidth |
serverMinGrassDistance | 0, or 50-150 | 0 | Client; 0 = client decides |
serverMaxViewDistance is how far clients may render. Raising it is largely a client cost and is reasonable on a low-population server where people want the vistas.
networkViewDistance is the maximum range at which the server replicates entities to a client. Every metre you add means more entities in scope for every connected player, and the cost scales with player count rather than being fixed. This is the one we clamp at 1600, and it is why a server that ran fine at 20 players falls over at 60 after someone “improved” it.
Warning: If you set
networkViewDistanceabove 1600 inconfig.json, it is rewritten to 1600 on the next start. The edit is not rejected or logged, the value is simply corrected, which looks like the file not saving
Note:
fastValidationis forced on for every server here. Bohemia’s own documentation says to always enable it on a public server, and it is not something worth leaving to chance
The Network Budget Settings
These live in the Reforger config editor under Network, and every one of them is a paired control: an enable switch and a value. When the enable is off, the value is ignored entirely and the engine uses its own default.
| Setting | Range | Default | Lower vs higher |
|---|---|---|---|
| NDS diameter | 0, 1, 2 | 2 | Lower: shorter net view, better perf |
| NWK resolution | 100-1000 m | 500 | Lower: less pop-in, shorter net view |
| RPL timeout | 1000-60000 ms | 10000 | Lower: drops lagging clients sooner |
| Staggering budget | 1-10201 /tick | 5000 | Too low: pop-in. Too high: spawn lag |
| Streaming budget | 100-10000 | 500 | Lower: better perf, slower load-in |
| Streams delta | 1-1000 | 100 | Higher: better for slow connections |
There is one trap in that table worth calling out on its own.
Turning the NDS enable switch off is not the same as setting NDS to 0. Leaving the toggle off means the engine falls back to its own default, which is diameter 2 and the feature enabled. To actually switch Network Dynamic Simulation off you set the value to 0 and turn the enable on. People who wanted the feature disabled and just flipped the toggle off have generally achieved nothing.
Tip: Change one knob at a time and give it a real session with real players. These interact, and a batch of six changes tells you nothing about which one helped
Replication Encoding
Replication: encode as long jobs is on by default here and should usually stay on. It spreads replication encoding across several engine frames, which smooths frame time under load.
Turning it off removes the flag and returns the engine to its default behaviour. On a small, low-population server that can lower replication latency slightly. On anything busy it invites frame-time spikes, which is the opposite of what most people are trying to fix. It needs a restart either way.
AI Is Usually the Real Cost
On a Conflict server, AI is typically a larger share of server load than players are, and it is the axis with the most headroom.
aiLimit in the operating block sets a ceiling on how many AI can exist. It defaults to -1, which means no limit. A negative value is ignored rather than treated as zero.
"operating": {
"aiLimit": 120,
"playerSaveTime": 120,
"slotReservationTimeout": 60,
"joinQueue": {
"maxSize": 0
}
}
| Key | Range | Default | Notes |
|---|---|---|---|
aiLimit | integer | -1 (no limit) | AI ceiling. Negative is ignored |
disableAI | true/false | false | Kills AI entirely. PvP-only servers |
playerSaveTime | seconds | 120 | How often player data is written |
slotReservationTimeout | 5-300 | 60 | Slot held for a kicked player |
joinQueue.maxSize | 0-50 | 0 (off) | Size of the join queue |
disableNavmeshStreaming is the interesting one. Disabling streaming loads the whole navmesh into memory, which gives slightly better server performance and faster AI reactions, at a cost of up to several hundred MB of memory depending on terrain. On a build with memory to spare that is a reasonable trade. On a tight build it is how you run out of memory.
Tip: A join queue is worth enabling on a popular server. Without one, a full server simply refuses people, and they retry in a loop that costs you connection handling
Max FPS
The Max FPS startup variable defaults to 165, which is also the ceiling. Bohemia’s documentation notes it regulates both server performance and network traffic.
Lowering it is a legitimate tool. A server pinned at 165 FPS is spending CPU on frames nobody observes, and dropping it frees headroom for simulation. Many busy servers run comfortably lower. It is worth testing rather than assuming, because the right value depends on your AI count and player load.
What 1.8 Improved on Its Own
Before you tune anything, note that 1.8.0.10 shipped a substantial round of stability and performance work, and some of it removes reasons people previously tuned aggressively:
- Voice over network performance improved
- Fixed a crash releasing a navmesh tile while loading it
- Fixed crashes and memory leaks in AI pathfinding, including a leak when removing unnecessary path points
- Dormant group AI spawning changed, and far-away groups can now be despawned properly
- Enemy AI no longer spawns on captured bases
- The resource subscription replication budget rose from 10 to 100 per frame
If your tuning notes predate 1.8, re-measure on defaults before reapplying them. Some of what you were working around is fixed.
The Order To Work In
- Measure. Get a server FPS figure under real load before touching anything
- Check AI count first, because it is usually the largest single cost
- Leave
networkViewDistancealone. It is clamped here for a reason - Change one network budget at a time, with a real session between each
- Only then consider Max FPS
- Write down what you changed, because in three weeks you will not remember
Note: Every Loafhosts build runs on AMD Ryzen 9 7950X3D CPUs with DDR5 and NVMe. Reforger leans hard on single-thread performance, which is why that specification matters more here than a higher core count would
Note: Game servers come with a 3-day money-back guarantee. Dedicated servers are non-refundable
Frequently Asked Questions
Why does my networkViewDistance keep resetting to 1600?
Because it is clamped to 1600 on every start. A higher network view distance multiplies replication work by the number of connected players and is one of the most common causes of a server that performs fine when quiet and badly when busy. serverMaxViewDistance is the setting to raise if you want longer sight lines.
What is the difference between serverMaxViewDistance and networkViewDistance?
serverMaxViewDistance caps how far clients render, which is mostly a client cost. networkViewDistance caps how far the server replicates entities to each client, which is a server CPU and bandwidth cost that scales with player count.
Does turning the NDS toggle off disable Network Dynamic Simulation?
No. With the enable switch off, the engine uses its own default of diameter 2 with the feature on. To disable it you set the diameter value to 0 and turn the enable switch on.
How do I limit AI on a Reforger server?
Set aiLimit in the operating block of config.json to the ceiling you want. It defaults to -1, meaning no limit, and any negative value is ignored rather than treated as zero. For a PvP-only server, disableAI switches AI off entirely.
Should I lower Max FPS on my server?
Often yes. It defaults to its maximum of 165, and a server holding that frame rate spends CPU on frames nobody sees. Lowering it frees headroom for simulation. Test rather than guess, because the right figure depends on your AI count and population.
What does “encode as long jobs” do?
It spreads replication encoding across several engine frames, which smooths frame time under load. It is on by default and should stay on for most servers. Turning it off can slightly reduce replication latency on a small server but invites frame-time spikes on a busy one.
Why is my server fine when empty and bad when full?
That is simulation and replication load scaling with players, not a fixed setting being wrong. Look at AI count and network view distance first. A setting that is harmless at 10 players can be decisive at 60.
Will more CPU cores fix a slow Reforger server?
Usually not much. Reforger does its heaviest work on a small number of threads, so single-thread speed matters more than core count. That is why we run Ryzen 9 7950X3D across the fleet. If the server is slow with memory and cores to spare, the fix is reducing what it simulates.
Persistence settings are covered in persistence and save games, and the full file is broken down in config.json explained.