A mod in Xenonauts 2 is implemented as a Content Pack – a self-contained collection of game assets (and optionally code) that can extend or override the base game content. In technical terms, a mod is defined by a content pack manifest (a JSON file, usually manifest.json in the mod folder) which describes the mod's identity and dependencies, and a set of asset directories organized in the standard structure.

Every mod requires a manifest.json file in its root directory. Here's the complete structure:

{
    "version": "0.0.4",
    "asset": {
        "Name": "Xenonauts Basic Cover Mod",
        "UID": "56bbba8a-7fb5-44c3-a6d3-834a2fb2d977",
        "Description": "A basic mod for Xenonauts 2 that changes cover values on the full cover master to 80%.",
        "Author": "Goldhawk Interactive",
        "Website": "http://www.goldhawkinteractive.com/",
        "Tags": ["Official", "Mod"],
        "Version": "1.0.0",
        "Dependencies": [
            {
                "UID": "other-mod-uid-here",
                "MinimumVersion": "1.0.0"
            }
        ],
        "SupportedLanguages": ["en", "de", "fr"],
        "MinimumVersion": "1.0.0",
        "MaximumVersion": "2.0.0",
        "Credits": "Special thanks to the modding community",
        "$type": "Common.Content.DataStructures.ContentPackManifest"
    },
    "$type": "Common.Content.DataStructures.VersionedAsset"
}

• version – The manifest format version (currently "0.0.4")
• Name – The display name of your mod as it appears in the mod list
• UID – A unique identifier (GUID) that distinguishes your mod. Use uuidgenerator.net to generate one, or leave blank and the game will generate one
• Description – A brief description of what your mod does
• Author – Your name or handle as the mod creator
• Version – Your mod's version number (e.g., "1.0.0")
• $type fields – Must be exactly as shown for the game to recognize the manifest structure

• Website – URL to your mod's homepage, forum thread, or repository
• Tags – Array of strings categorizing your mod (e.g., ["Balance", "Gameplay", "Visual"])
• Dependencies – Array of other mods this mod requires to function properly
• SupportedLanguages – Array of language codes your mod supports (omit for all languages)
• MinimumVersion / MaximumVersion – Game version compatibility range
• Credits – Acknowledgments for contributors, assets used, etc.

If your mod depends on another mod, specify it like this:

"Dependencies": [
    {
        "UID": "12345678-1234-1234-1234-123456789abc",
        "MinimumVersion": "1.0.0",
        "MaximumVersion": "2.0.0"
    }
]

The game will ensure required mods are loaded before yours and warn users if dependencies are missing.

In addition to the manifest, a mod content pack consists of a directory structure that mirrors the base game's asset organization. The general pattern is:

<ContentPackName>/<TypePrefix>/<Screen>/<TypePostfix*>/<Name>.<Ext>

• ContentPack: Your mod's folder name (e.g., my_awesome_mod)
• TypePrefix: Asset type category (e.g., template, texture, prefab)
• Screen: Game context (e.g., groundcombat, strategy, common)
• TypePostfix: Optional subcategory for further organization
• Name.Ext: The specific asset file

my_awesome_mod/                    # Your mod's content pack directory
├── manifest.json                  # Required manifest file
├── assembly/common/               # Compiled .dll mod files (optional)
├── template/                      # Game data templates (JSON files)
│   ├── groundcombat/             # Ground combat templates
│   │   ├── masters/              # Master definitions
│   │   │   └── blueprints/       # Environment objects, cover, etc.
│   │   └── item/                 # Combat items (weapons, equipment)
│   │       └── weapon/           # Weapon definitions
│   └── strategy/                 # Strategy layer templates
│       └── actor/                # Unit/character definitions
│           └── combatant/        # Combat unit stats
├── texture/                      # Images and textures
├── prefab/                       # Unity prefabs (UI, objects)
└── data/                         # CSV files, localization data

Xenonauts 2 enforces strict naming rules:

• Use lowercase letters and underscores for names
• Use singular nouns for folder names (e.g., texture not textures)
• No spaces or special characters - use underscore _ instead
• Examples: plasma_rifle.json ✓, PlasmaRifle.JSON ✗

To modify existing game content, create a file with the exact same path as the base game asset. Your mod's version will override the original. For example:

• Base game: xenonauts/template/groundcombat/item/weapon/ballistic_rifle.json
• Your mod: my_mod/template/groundcombat/item/weapon/ballistic_rifle.json

When both are present, your mod's version takes precedence.

The manifest is represented by a ContentPackManifest object in the game code. The UID is particularly important as it's used to:

• Track and identify the mod uniquely
• Resolve dependencies between mods
• Determine load order
• Handle version compatibility

The game's ContentManager handles loading content packs in the correct order, with the base game (xenonauts pack) loaded first, followed by enabled mods. This system allows mods to override base content or add entirely new assets while maintaining compatibility and proper load order.

Notably, mods can include custom code via compiled assemblies placed in the assembly/common/ directory. These .dll files (and optional .pdb debug symbols) are loaded by the game's content system, allowing mods to execute custom logic using the provided modding API or frameworks like Harmony for runtime patching.