Mod Structure

With the introduction of XPath and additional modding hooks in Alpha 17 experimental release, the mods folder structure has had some changes.

By default, the Mods folder does not exists. This can be created and called "Mods", at the root of your 7 Days to Die installation:

The default steam installation path:

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

The Mods Folder:

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

The same folder structure can be deployed to a dedicated build. XML-based changes are pushed from the server to the client; However, item icons and asset bundles do not get pushed, and must be installed on the client to work.

Mod Folder Structure

---

Mods following the new modding hooks should contain the following structure. Some folders will not be necessary if they are not used in the mod.

SphereII_PG13/
    /Config/
    /Config/XUi/
    /ItemIcons/                  (A17 and earlier)
    /Resources/
    /UIAtlases/ItemIconAtlas/    (A18+)
    /ModInfo.xml

SphereII_PG13/

This would be the Mod's main folder, and referenced under Mods/Sphere_PG13

/Config/

This is where all the xpath-based XML files should be stored. Its folder structure must replicate the Data/Config folder.

/Resources/

This is where your Unity3D asset bundles should be stored.

/ItemIcons/

A17 and earlier: this is where your custom item icons should be stored.

/UIAtlases/ItemIconAtlas/

A18 and later: this is where your custom item icons should be stored.

Note: despite what the A18 release notes say, use this path and not /UIAtlases/ItemIcons/ (incorrect).

/ModInfo.xml

This is the ModInfo.xml, that contains information about the mod. It's required, otherwise the game will not load the mod.

Config Folder

---

The Config folder is where the game will look for all the xpath-compatible XML files. These XML files must match their vanilla files in name and in folder. So if you are editing a XUI window, you will need to include the XUI folder as part of your Config folder.

Mods/SphereII_PG13/Config/entityclasses.xml

Mods/SphereII_PG13/Config/items.xml

Mods/SphereII_PG13/Config/XUi/windows.xml

Example XPath File

---

Here's an example xpath-compatible file, using the set command:

File: Mods/SphereII_PG13/Config/entityclasses.xml

---

<configs>
	<!-- change the stripper's meshes with the nurses' skin -->
	<set xpath="/entity_classes/entity_class[@name='zombieStripper']/property[@name='Mesh']/@value">Zombies/zombieStandardNurseRagdoll</set>
	<set xpath="/entity_classes/entity_class[@name='zombieStripperFeral']/property[@name='Mesh']/@value">Zombies/zombieStandardNurseRagdoll</set>
</configs>

Resource Folder

---

The Resource folder is an optional folder where you can place your generated unity3d asset bundles. These asset bundles allow us to package up our own block textures, entities mesh, and other unity-related packages. The folder name "Resources" is used here as an example. The folder can be named anything, as long as the xpath-compatible XML points to it.

Item Icons

This folder is an optional folder where you can place your custom item icons.

ModInfo.xml

---

The ModInfo.xml is required for the game to recognize the folder as a Mods folder.

Example of ModInfo.xml v2 (beginning with Alpha 21):

<?xml version="1.0" encoding="UTF-8" ?>
<xml>
    <Name value="SomeInternalName" /> <!-- (Required) Internal name, like an ID, of the mod. Should be globally unique, like an author prefix + name. Only allowed chars: Numbers, latin letters, underscores, dash -->
    <DisplayName value="Official Mod Name" /> <!-- (Required) Name used for display purposes, like shown in the mods UI at some point. Could be the same as you would later on use on workshop or wherever mods get distributed -->
    <Version value="1.0.3.243" /> <!-- (Required) SemVer version of the mod. Has to be in the format major.minor[.build[.revision]] (i.e. build and revision can be left out, recommend using them though as typically done with Semantic Versioning -->
    <Description value="Mod to show format of ModInfo v2" /> <!-- (Optional) More text to show on UIs -->
    <Author value="TFP" /> <!-- (Optional) Name(s) of the author(s) -->
    <Website value="" /> <!-- (Optional) URL of a website of the mod -->
</xml>

Example of ModInfo.xml v1

<?xml version="1.0" encoding="UTF-8" ?>
<xml>
	<ModInfo>
		<Name value="SphereII_PG13" />
		<Description value="This modlet tries to make the game a bit more PG, by switching out the stripper model with a nurse." />
		<Author value="sphereii" />
		<Version value="1.0.0" />
	</ModInfo>
</xml>

Config/Localization.txt

---

Beginning in A18, Localization from the Mods folder is now supported.

In the Config folder, create a Localization.txt. This file must match case and spelling of the vanilla entries.

The localization files have a heading, like the vanilla version, as a comma delimited line. For mod localization support, you only need to specify the heading that you are adding. For example, if your mod only contains localization for English, you do not need to specify the other language in the heading line.

If your new localization key matches a vanilla value, or a value from a previously loaded mod, then that value will be updated, with the last mod loaded having the final effect.

The format of the file is this:

HEADING
ENTRY

Example:

Key,English
myKey,This is my English Key

Note: If you are only including non-English translation, such as French, and leave the English blank or out, then a user loading the Spanish version will get the localization key. This is because English is the fall back translation. If you specify an English, then the Spanish player will see the English localization.