Arma Reforger: config.json explained (every setting and safe values) Print

Every Arma Reforger dedicated server is driven by one file: config.json. The panel exposes the settings most people change, and the Workshop mod manager writes the mods block for you, but sooner or later you will want to tune something that only lives in the file itself. This guide walks through the sections of config.json, explains what each field does, and lists the values that are safe to change on a rented server.

Before you edit

1. Stop the server. Reforger reads the file once at launch and never re-reads it while running.
2. Open config.json in the panel's file manager and copy the whole thing into a text editor so you have a backup.
3. Keep the JSON valid: every string in double quotes, commas between entries, no comma after the last entry in a block. A single stray comma will stop the server from starting with no obvious error in-game. Pasting the file into any online JSON validator before saving takes ten seconds and saves a lot of guessing.

The network block

The top of the file sets bindAddress, bindPort, publicAddress and publicPort. On a hosted server these are set for you and tied to the ports allocated to your service. Leave them alone; changing a port here without changing the allocation in the panel means nobody can connect.

a2s is the Steam query protocol that lets the server browser show your player count. rcon enables remote console access and has its own password and permission level (admin or monitor). If you use an external admin tool, this is where it connects; otherwise leave rcon disabled or with an empty password.

The game block

This is where most of the useful settings live.

• name: the server name shown in the browser. Up to 100 characters.
• password: a join password. Leave it empty ("") for a public server.
• passwordAdmin: the password used with #login in chat to get admin rights. Set this even on private servers.
• admins: a list of player identities (Steam IDs or Bohemia IDs) who get admin automatically without a password. Example: "admins": ["76561198000000000"].
• scenarioId: the scenario the server loads. Vanilla IDs include Conflict Everon {ECC61978EDCC2B5A}Missions/23_Campaign.conf, Conflict Arland {C700DB41F0C546E1}Missions/23_Campaign_Arland.conf, Game Master Everon {59AD59368755F41A}Missions/21_GM_Eden.conf, Game Master Arland {2BBBE828037C6F4B}Missions/22_GM_Arland.conf and Combat Ops Arland {DAA03C6E6099D50F}Missions/24_CombatOps.conf. Modded scenarios publish their own ID on the Workshop page; copy it exactly, including the braces.
• maxPlayers: the player cap. Values from 1 to 128 are accepted, but the scenario and your hardware decide what actually plays well; 64 is the vanilla default for Conflict.
• visible: true lists the server in the browser, false hides it so players need the direct IP or an invite.
• crossPlatform and supportedPlatforms: set crossPlatform to true and list "PLATFORM_PC", "PLATFORM_XBL" and "PLATFORM_PSN" to allow console players. Note that console players can only join a modded server if every mod is console-compatible, so a PC-only modset forces a PC-only server.

gameProperties

These settings shape how the world behaves for everyone on the server.

• serverMaxViewDistance: the furthest any client may render, between 500 and 10000. Lower values protect frame rate for players on weaker machines; 1600 is the default.
• serverMinGrassDistance: 0 lets clients disable grass; a value between 50 and 150 forces grass to render out to that distance so prone players cannot be spotted by someone with grass turned off. Milsim groups usually set 50 or higher.
• networkViewDistance: how far away the server replicates other players and vehicles, 500 to 5000. Default is 500 for Conflict; raising it costs bandwidth but matters a lot for long-range engagements.
• disableThirdPerson: true forces first person. The single most requested setting on realism servers.
• fastValidation: leave at true. Turning it off makes the server verify clients much more strictly and is only intended for debugging.
• battlEye: anti-cheat, on by default. Keep it on for any public server.
• VONDisableUI, VONDisableDirectSpeechUI and VONCanTransmitCrossFaction: control the voice-chat overlay and whether opposing factions can hear each other over radio. Realism units typically disable the UI hints and keep cross-faction transmission off.
• missionHeader: scenario-specific overrides. For Conflict this is where you change things like the start time of day or the base capture settings; the exact keys are documented by the scenario author and vary between scenarios.

mods

The Workshop mod manager in the panel maintains this block for you. Each entry has a modId (the hex ID from the Workshop URL), an optional name for readability and an optional version. Leaving version out means the server downloads the latest version each start, which is what you want on a hosted server unless a specific mod update broke something. If you edit this block by hand, remember that the manager will rewrite it the next time you use it.

The operating block

• lobbyPlayerSynchronise: keeps the lobby player list in sync with the server. Leave it true.
• playerSaveTime: seconds between player state saves, default 120. Lower values save progress more often at a small CPU cost.
• aiLimit: a hard cap on the number of AI characters. -1 means no limit. If your Game Master sessions are tanking the server, setting this to 60 or 80 is a quick fix.
• slotReservationTimeout: seconds a slot is held for a player who disconnects, so they can rejoin into the same slot. Default 60.
• disableAI: true stops all AI from spawning. Useful for pure PvP events.
• joinQueue with maxSize: allows a queue of up to this many players when the server is full. 0 disables the queue.

A sensible starting point

For a 40-to-64 player community Conflict server, a common recipe is: maxPlayers 64, serverMaxViewDistance 2500, networkViewDistance 1500, serverMinGrassDistance 50, disableThirdPerson true, battlEye true, playerSaveTime 120 and a joinQueue of 10. Change one thing at a time, restart, and watch the server's console log for warnings; the log will tell you the exact line if the JSON failed to parse.

When something goes wrong

If the server does not come up after an edit, the cause is almost always one of three things: invalid JSON, a scenarioId that does not match a loaded scenario (check the braces and the path), or a mod entry with a wrong modId. Restore your backup copy, confirm the server starts, then reapply changes one block at a time.

Want this running in a minute? AP Gaming servers come with this set up out of the box: see plans or start a free 48-hour trial.