Home

Disabling & Overriding Content

Part of modding is removing and replacing what's already there - turning off base-game buildings that don't fit your setting, swapping an icon, or shipping a compatibility patch that overrides another mod. Because all content is discovered and layered at runtime, this is well supported and doesn't involve editing the base game's files.

Two ways to switch content off

There are two levels at which content can be switched off, and the difference between them is scope. The first is pack-level, declared in mod.json under content.disable, and it disables content whenever your pack is enabled, right across the game. The second is campaign-level, declared in a map's Info.json, and it disables content only while that particular campaign is being played.

Pack-level is the right choice for a mod that fundamentally changes the game everywhere. Campaign-level suits a scenario that should be self-contained - a historical map that shouldn't offer content from an unrelated setting, while that same content stays available in other campaigns.

Pack-level: content.disable

In mod.json, a content block can carry a disable list. Each rule turns off either a group of content or a single item by its type and key:

JSON
"content": {
  "disable": [
    { "group": "SiegeEngines" },
    { "type": "Building", "key": "Amphitheatre" },
    { "type": "Trait", "key": "Gout" }
  ]
}

A rule with a group disables a whole named group in one go - groups are how content is bucketed for exactly this purpose, so a single line switches off a themed set. A rule with a type and key disables one specific thing, where the key matches the content's own key, the n"Amphitheatre" from default Key = n"..." set in AngelScript. Every rule has to be one or the other; the game rejects a rule that's neither a group nor a type-and-key pair.

You can also declare which groups your own content belongs to, so other packs (or your own campaigns) can target them:

JSON
"content": {
  "groups": ["SicilianCommerce"],
  "disable": [ { "group": "SiegeEngines" } ]
}

Campaign-level: Info.json

A campaign can disable content just for itself. You author this in the World Editor's Info panel (see The World Editor), which writes the fields into the exported Data/Maps/<MapId>/Info.json:

JSON
{
  "id": "SicilySouthernItaly827",
  "contentProfileId": "sicily-827",
  "requiredContentPacks": ["com.yourname.lords-of-sicily"],
  "disabledContentGroups": ["SiegeEngines"],
  "disabledContentKeys": [
    { "type": "Building", "key": "Amphitheatre" }
  ]
}

The fields mirror the pack-level rules. disabledContentGroups is an array of group names, working the same way as a pack-level group rule, and disabledContentKeys is an array of { type, key } objects, working the same way as a pack-level type-and-key rule. Alongside them, requiredContentPacks lists the packs that must be enabled for this campaign; the World Editor warns at export if a required pack isn't in your linked-build preview set, and the game checks the same thing when it loads the campaign.

The mechanics are identical to the pack-level rules; the only difference is that they apply while this campaign is loaded and nowhere else. That's usually the cleaner choice, because it keeps a scenario's content footprint tied to the scenario itself.

Overriding: load order wins

Where disabling removes content, overriding replaces it, and the mechanism is load order. The base game loads first, then each pack in ascending loadOrder, with later packs layering on top of earlier ones. To override something that the runtime merges by key, ship your own version with the same key and give your pack a higher loadOrder than the one you're overriding.

JSON
{ "id": "com.yourname.sicily-icon-fixes", "loadOrder": 500 }

The key is important. If two enabled packs provide the same key for a merged system, the later pack.

Putting it together

A total-conversion campaign usually uses all three at once:

  1. Ship new content in Script/, Content/, and WebUI/.
  2. Override merged content by load order where you want different values.
  3. Disable the base content that doesn't belong - pack-wide if the mod is a global overhaul, or per-campaign in the map's Info.json if you want the change scoped to your scenario.

The Sicily example is the reference for how this looks in a finished mod.

Next

  • Test that your disables and overrides actually took effect, and package the result - Testing & Publishing
NextTesting & Publishing →