Configuration

The three layers

Every ATG mod that supports this system builds its settings from three layers, each overriding the one before.

Layer 1 — defaults. Compiled into the mod. You get these if you change nothing.

Layer 2 — an override in your own mod. The ordinary Arma way: you cannot edit a mod’s own config file, because it arrives from the Workshop read-only and an update would overwrite you, so you make a mod of your own and override the file in it. This needs the Workbench tools.

Layer 3 — a JSON file on your server. What ATG Core adds. No tools, no mod, no rebuild.

Layer 3 is what the rest of this page is about.

The file

One file per mod, in your server’s profile directory:

<profile>/ATG/<mod-id>.json

The mod id is fixed by the mod — atg-scenario.json, atg-garmin-vitals.json. Each mod’s own configuration page names it.

A few things worth knowing before you write one:

• Core never creates or writes these files. It only reads them. An absent file is normal and means every setting keeps its layer-1/2 value.
• The file is read once, at startup. Editing it on a running server changes nothing until the server restarts.
• It is read on the server only. The server then sends the resulting values to every client, so you do not distribute anything to your players and they cannot override it locally.
• Booleans are true and false, not 1 and 0. A 1 is ignored and the setting keeps the value it already had.

Confirm it was picked up: the server log carries

[ATG-Core-Config] Applied JSON overrides for 'atg-scenario' from $profile:ATG/atg-scenario.json

Two warnings can appear instead, and both mean nothing was applied:

[ATG-Core-Config] $profile:ATG/atg-scenario.json could not be parsed as JSON, so none of it was applied.
[ATG-Core-Config] $profile:ATG/atg-scenario.json was read but changed nothing.

The first is a syntax error — a trailing comma or an unquoted key. The second means the file is valid but no value in it took effect, most often a boolean written as 1 rather than true. It also appears, harmlessly, when the file just repeats the settings the server already had.

No such line means the file was not found or not parsed, and the mod is running on its built-in settings.

Single values are applied key by key

Name only the settings you want to change. Everything you leave out keeps the value it already had, so a file that changes one number stays one line long and survives mod updates that change the rest.

{
  "m_fUpkeepPerHour": 40
}

Lists are replaced whole

Some settings are lists rather than single values — a mod’s set of objective types, its tier ladder, its garrison profiles. These behave differently, and it is the one rule on this page that catches people out.

Naming a list in the JSON replaces it entirely. There is no way to change one entry, or to add an entry, and leave the rest alone. A list you touch must be written out in full, including the entries you were happy with.

That is deliberate. Changing one entry in place would mean every entry needing a permanent identity, and you addressing them by index or by id in a text file where nothing checks your arithmetic. The result is harder to get right than restating the list, and much harder to see when it goes wrong. Wholesale replacement is blunt, but what you wrote is what you get.

A list you never name is left exactly as the mod’s own config set it, the same as any other setting.

Every entry needs a $type

An entry in a list carries a $type naming its class. This is what lets one list hold entries of different kinds — an objective list mixing Destroy, Kill and Clear area objectives is three different classes in one array:

{
  "m_aObjectiveTemplates": [
    {
      "$type": "ATG_Scenario_DestroyObjective",
      "m_sName": "Destroy",
      "m_fReward": 100
    },
    {
      "$type": "ATG_Scenario_ClearAreaObjective",
      "m_sName": "Clear area",
      "m_fReward": 150
    }
  ]
}

Write it on every entry, including where they are all the same kind.

Getting a $type wrong is silent. A misspelled or missing one produces an entry that loads without complaint and then does nothing at all — an objective that never comes up, a tier that is never reached. Nothing appears in the log, because as far as the game is concerned you asked for an empty thing and got one.

Two habits make that survivable:

• Start from the mod’s complete example, on its own configuration page, rather than writing a list from memory. That is what those examples are for.
• Change one list at a time and confirm the server behaves as though it took, before moving on to the next.

Where the complete files are

A working file names only what you are changing and leaves the rest alone:

<profile>/ATG/atg-scenario.json

{
  "m_fUpkeepPerHour": 40,
  "m_iMaxConcurrentObjectives": 4,
  "m_bCiviliansInNarrative": false
}

Each mod’s own page carries the complete file at its shipped values, which is the thing to start from rather than writing one out by hand:

• ATG Scenario — the large one, and the one with lists in it.
• ATG Garmin Vitals — twelve settings and no lists.