7 Days to Die: XML Modding

XML modding in 7 Days to Die lets you change game content specifically through configuration files — without compiling any code. This page explains how to get started and how to work purposefully with the most important files: entitygroups.xml, items.xml, rwgmixer.xml and further config files.

---

Preparation

Tools you need

• A text editor with XML syntax highlighting — recommended: Notepad++ (free) or Visual Studio Code
• A basic understanding of XML structure (elements, attributes, nesting)

Back up the original files

:::warning Back up before every change Always create a copy of the original file before you make changes. Faulty XML files can cause crashes or a save game that no longer loads. Through Steam, all files can be restored to their original state with Verify integrity of game files. :::

Where the config files live

The original configuration files are located in the game's installation directory:

C:\Program Files (x86)\Steam\steamapps\common\7 Days To Die\Data\Config\

That folder holds all editable XML files plus an XML.txt with developer comments and notes on many attributes — a helpful reference right inside the game directory.

---

Understanding the modlet system

Since Alpha 17, changes have been integrated through so-called modlets. A modlet is a self-contained subfolder in the Mods directory that extends the game logic via XPath patches — without overwriting the original files.

Folder structure of a modlet

Mods/
  MeinModlet/
    ModInfo.xml
    Config/
      entitygroups.xml
      items.xml
      rwgmixer.xml

The Config folder inside the modlet must use the exact original file names. On game start the engine reads all modlets and applies the patches they contain to the vanilla data.

ModInfo.xml

Every modlet needs a ModInfo.xml — without this file the folder is ignored by the game.

<?xml version="1.0" encoding="UTF-8"?>
<xml>
  <ModInfo>
    <Name value="MeinModlet" />
    <DisplayName value="AKMG Testmod" />
    <Author value="DeinName" />
    <Version value="1.0" />
    <Description value="Kurzbeschreibung des Mods" />
  </ModInfo>
</xml>

Installation path (from V1.0)

Since version 1.0 the preferred installation location for mods is the user data folder:

%appdata%\7DaysToDie\Mods\

Alternatively, the classic directory in the Steam installation path still works:

C:\Program Files (x86)\Steam\steamapps\common\7 Days To Die\Mods\

---

XPath syntax — the basic principle

All XML patches in modlets use XPath to address and change individual nodes or attributes in the game data. The mod file always starts with <configs> as its root element.

Available operations

A simple example — changing an attribute

<configs>
  <set xpath="/items/item[@name='gunHandgunT1Pistol']/property[@name='DegradationMax']/@value">500</set>
</configs>

This snippet increases the maximum durability of the pistol without touching any other properties.

---

XML modding: the most important files

entitygroups.xml — adjusting spawn groups

This file defines which entities (zombies, animals, NPCs) are bundled into which groups. Spawn groups are referenced by the spawn system and by hordes.

Typical entries:

<entitygroup name="ZombiesAll">
  <entity name="zombieMoe"       prob="1" />
  <entity name="zombieBoe"       prob="0.5" />
  <entity name="zombieDarlene"   prob="0.5" />
</entitygroup>

• prob — the relative probability with which the entity is picked from the group
• Higher value = more frequent; a value of 0 or a commented-out entry = never

Adding your own group:

<configs>
  <append xpath="/entitygroups">
    <entitygroup name="ZombiesNurOnly">
      <entity name="zombieNurse" prob="1" />
    </entitygroup>
  </append>
</configs>

:::warning Mind consistency When you reference a group (for example in spawning.xml or gamestages.xml), the group name has to match exactly. A typo here means no spawn happens at all. :::

---

items.xml — modifying items and weapons

items.xml contains all definitions for weapons, tools, food, resources and other items. Every entry is an <item> element with a name attribute and a series of <property> child nodes.

Frequently changed attributes:

Example — making food more nourishing:

<configs>
  <set xpath="/items/item[@name='foodShamSandwich']/property[@name='Gain_food']/@value">40</set>
  <set xpath="/items/item[@name='foodShamSandwich']/property[@name='Gain_water']/@value">10</set>
</configs>

Example — a new item as an extension of an existing one:

<configs>
  <append xpath="/items">
    <item name="myCustomKnife">
      <property name="Extends" value="knifeHuntingT1" />
      <property class="Attributes">
        <property name="EntityDamage" value="50,80" />
        <property name="DegradationMax" value="300,800" />
      </property>
    </item>
  </append>
</configs>

With Extends the new item inherits every property of the original that is not explicitly overwritten. That is the cleanest method for your own variants.

---

rwgmixer.xml — configuring world generation

rwgmixer.xml controls how randomly generated worlds (random world generation) are built: biome distribution, city sizes, the road network and which POIs (points of interest) are allowed to spawn in which areas.

Important sections of the file:

Example — increasing the town size for a biome:

<configs>
  <set xpath="/rwgmixer/biome[@name='pine_forest']/property[@name='MaxTownSize']/@value">large</set>
</configs>

:::warning rwgmixer.xml only takes effect on new world generation Changes to this file have no effect on worlds that have already been generated. An existing world has to be deleted and regenerated with a new seed for the adjustments to apply. So always test rwgmixer patches on a separate test world. :::

POIs are assigned via tags. If your own POI is to be placed by RWG, the corresponding prefab has to carry a matching Tags attribute in its meta file that is referenced in the prefab rules of rwgmixer.xml.

---

Other relevant XML files

XML modding in 7 Days to Die covers far more than just the three main files. Here is an overview of further commonly used files:

---

Step by step: creating your first modlet

1. Create a new folder in the Mods directory, for example AKMG_TestMod
2. Create a ModInfo.xml file inside it (see the example above)
3. Create a Config subfolder
4. Create the XML file you want inside it (for example items.xml) — with <configs> as the root element
5. Enter your XPath patches and save
6. Start the game — on loading, all mods from the Mods folder are read in automatically

Error checking: With a syntax error in the XML, the game often aborts at the loading screen. In such cases the log file under %appdata%\7DaysToDie\Logs\ contains the exact location of the error.

---

Tips and common sources of error

• Capitalization: Attribute names and element names in XPath are case-sensitive. [@name='zombieMoe'] and [@name='zombiemoe'] are different.
• Use comments: XML comments (<!-- ... -->) help you temporarily disable experimental changes without deleting them.
• Never edit vanilla files directly: Every Steam verification overwrites direct edits. Only modlets in the Mods folder survive.
• One modlet = one function: Small, clearly scoped modlets are easier to debug and disable than monolithic bundles.
• Several mods, same file: If two modlets patch the same file, both patches are applied one after another. Conflicts arise when both remove the same node or set it contradictorily. Load order is alphabetical by modlet folder name.
• When XML modding, always open the original config file for reference — that is the only way to formulate valid XPath expressions correctly.