Adding 50+ DayZ Workshop mods without corrupting your loot table

Every Workshop mod that adds items has to get them into your loot economy somehow, and most do it by shipping a types.xml for you to merge. With five mods, pasting each one onto the end of the vanilla file works well enough. With fifty, you’re looking after tens of thousands of lines from dozens of authors, written for different maps and different game versions, with some classes defined two or three times. The server still starts, so nothing tells you that the entry you just edited isn’t the one it’s using.

This guide covers a layout that scales to any number of mods, how the server chooses between duplicate entries, how to find and clear them out, and how to fill in the items mods leave out without typing hundreds of entries yourself. If you’re new to the file itself, DayZ types.xml explained covers every field first.

Why pasting into types.xml stops working

Pasting a mod’s entries into the vanilla types.xml is how most servers start, and it’s how most loot tables end up in a mess. Past a few mods, it causes four problems:

• One bad paste breaks everything. An unclosed tag halfway down can stop the whole file loading, and vanilla loot goes with it.
• Mod updates mean digging. When a mod updates, you have to find its entries among tens of thousands of lines, and nothing marks which lines came from which mod.
• Game updates get harder too. When a DayZ update changes the vanilla file, you have to merge the new version into a file that’s half mod entries.
• Duplicates pile up unseen. The same class ends up in the file twice, or in the file and in a mod’s own file, and only one of them counts.

A layout that scales: one folder per mod

cfgeconomycore.xml lets a mission load extra economy files on top of the vanilla ones. Give each mod its own folder in the mission, keep its files under the names they shipped with, and register each folder:

dayzOffline.chernarusplus/
  cfgeconomycore.xml
  db/
    types.xml                  ← vanilla items only
    mods/
      WeaponsPack/
        types.xml
        cfgspawnabletypes.xml
      WinterClothing/
        types.xml
      …one folder for each mod

<economycore>
    <!-- …the existing classes and defaults… -->

    <!-- WeaponsPack: Workshop 1234567890, files from the 14 Oct 2026 update -->
    <ce folder="db/mods/WeaponsPack">
        <file name="types.xml" type="types"/>
        <file name="cfgspawnabletypes.xml" type="spawnabletypes"/>
    </ce>

    <!-- WinterClothing: Workshop 2345678901, files from the 2 Sep 2026 update -->
    <ce folder="db/mods/WinterClothing">
        <file name="types.xml" type="types"/>
    </ce>
</economycore>

folder is relative to the mission folder, and name is a file inside it. type says what the file holds: types for loot, spawnabletypes for what items spawn with, and events for dynamic events. The file name can be anything, so a folder per mod means fifty files called types.xml never collide, and removing a mod is deleting one folder and one <ce> block.

The comments are for you. With the Workshop ID and the date of the files next to each block, you can tell at a glance which mods you haven’t updated in a while.

Mods usually ship their types file in the mod’s own folder (look for a folder called something like types, extras or ServerFiles) or link to it from the Workshop page. The server still needs the mod itself in its -mod= list. A types entry only tells the Central Economy what to do with a class the server already knows about.

Load order decides which entry wins

When the server starts, it loads the vanilla db/types.xml, then every file listed in cfgeconomycore.xml, in the order they appear. When the same class is defined more than once, the entry loaded last replaces the earlier ones.

Two details catch people out:

• It replaces the whole entry. Nothing is merged. A mod entry for the AKM that only sets nominal and min leaves the AKM with no usage and no value, not the vanilla ones, so it has nowhere to spawn.
• Only the order in cfgeconomycore.xml matters. The order of mods in -mod= has nothing to do with it. Moving one <ce> block above another can change what spawns without a single number being edited.

The server starts normally either way, and nothing in game tells you an entry has been replaced. The loot is just different from what you set.

Where duplicate classes come from

With a handful of mods, duplicates are rare. With fifty, you almost certainly have some. They usually come from one of these:

1. Mods that ship vanilla entries. Some authors include their own balance for vanilla items, or a full copy of the vanilla types.xml as it was when they made the mod. Listed after vanilla, that file quietly replaces your values with theirs, possibly from an older game version. This is the worst kind, because one file can change thousands of items.
2. Shared items. Two mods built on the same base, or a pack that bundles another mod, both ship entries for the same classes.
3. Pasted and registered. A mod’s entries were pasted into the vanilla file a while ago, and later someone registered the mod’s own file as well.
4. Leftovers. A mod renamed its types file in an update, the new file was registered, and the old one is still listed.
5. The same entry twice in one file, usually from a paste that went in twice.

Each one is a trap that goes off later. You edit the entry you can see, restart, and nothing changes, because a file further down the list defines the same class. Or you tune the AKM in a mod’s file, because that’s the copy the server uses, and the next mod update replaces the file and your changes with it.

Finding duplicates

The quickest check is a script that lists every class defined more than once. Run it from the mission folder, and change the paths if your mod files live somewhere else. On a Windows server, in PowerShell:

Select-String -Path db\types.xml, db\mods\*\types.xml -Pattern '<type\s+name="([^"]+)"' |
    Group-Object { $_.Matches[0].Groups[1].Value } |
    Where-Object Count -gt 1 |
    ForEach-Object { $_.Name + ':  ' + (($_.Group | ForEach-Object { Resolve-Path -Relative $_.Path }) -join '  ') }

On Linux:

grep -oiE '<type[[:space:]]+name="[^"]+"' db/types.xml db/mods/*/types.xml |
  awk -F'"' '{ split($1, p, ":"); k = tolower($2); if (!(k in name)) name[k] = $2; n[k]++; f[k] = f[k] "  " p[1] }
    END { for (k in n) if (n[k] > 1) print name[k] ":" f[k] }'

Both print each duplicated class with the files it’s in:

AKM:  db/types.xml  db/mods/WeaponsPack/types.xml
WC_Parka:  db/mods/OldPack/types.xml  db/mods/WinterClothing/types.xml
WP_Rifle:  db/mods/WeaponsPack/types.xml  db/mods/WeaponsPack/types.xml

The files aren’t listed in load order, so check cfgeconomycore.xml to see which entry the server actually uses. Both scripts also match entries inside XML comments, so something an earlier admin commented out shows up too. Check each hit before you delete anything.

Cleaning up: one entry per class

The goal is simple: every class defined exactly once, in the file you’d expect to find it in. Three rules cover almost everything:

• Vanilla items belong in db/types.xml. Delete them from mod files. If you preferred the mod’s numbers for an item, copy them into the vanilla entry first.
• Mod items belong in the file of the mod that adds them. Delete the copies from every other mod’s file.
• Repeats within one file: keep one.

Before you delete a copy, work out which one is live, the one loaded last. If those are the values players are getting and you want to keep them, copy them into the entry you’re keeping, so the cleanup doesn’t change what spawns. Back up the mission folder first, then restart and check the server logs.

Keeping mod files up to date

Once you’ve cleaned up a mod’s file, it’s yours, and a mod update shouldn’t overwrite it blindly. Keep a copy of each mod’s files exactly as they shipped, outside the mission folder. When the mod updates, compare its new files against that copy: the differences are exactly what the author changed. Bring the new classes, and any changes you agree with, into your own file, then replace the stored copy with the new one and update the date in the comment.

Make mod entries fit your mission

A mod’s types file was written for the author’s server, which may run a different map with different rules. Check two things before you trust it.

Names your mission defines. Every category, usage, value and tag has to exist in your cfglimitsdefinition.xml or cfglimitsdefinitionuser.xml, and mods made for one map sometimes use names another map doesn’t have. Adding the missing name to your limits file stops the error, but if nothing on your map is marked with it, the item still has nowhere to spawn. Change it to a name your map uses.

Numbers that fit your loot. Every author thinks their items deserve to be found. Fifty mods each adding a generous handful of rifles adds up to far more guns than you planned. Compare each mod’s nominal and min values with the vanilla items they compete with, and scale them to match.

The items mods leave out

Then there’s the opposite problem: items with no entry at all. Some mods don’t ship a types file, some ship one that misses half their items, and updates add classes the types file never catches up with. An item without an entry never spawns as loot, and nothing tells you it’s missing.

Finding them by hand means checking every class in every mod’s config, which lives inside its PBOs, against your types files. Then each one needs an entry with eleven settings. A clothing pack with ten colours of everything can add a few hundred classes on its own, so across fifty mods, the data entry runs to days.

The best way to write those entries by hand is to copy each one from the closest item you already have: a new rifle from a similar rifle, a new colour of a jacket from a colour you already spawn. Change the name, and the new item starts with numbers that already fit your economy rather than the mod author’s. It works, but it’s the same few minutes of copy, paste and rename for every item.

Smart Add: let LootEngine copy from the closest relative

That copy-from-the-closest-relative step is exactly what LootEngine’s Smart Add automates.

Point LootEngine at your DayZ folder and tick the mods you run. It reads every item from the game and the mods’ PBOs, with their in-game names and rendered icons, along with every types file your cfgeconomycore.xml lists. The Not in loot files filter then shows every item that exists in the game but has no entry, which is the list that’s so hard to build by hand.

Click Add to loot on any of those items, and Smart Add looks for its closest relative already in your loot files:

1. Its own family first. It checks the item’s parent class, then the other items that share that parent, starting with the ones whose class names are closest to the new item’s. A new colour of a jacket copies from a colour you already have.
2. Then a generation up. If nothing in the immediate family has an entry, it moves up to the grandparent class and tries again, and so on up the tree.
3. Only close relatives. Items that share a parent only count when the family is small. A new tin of food won’t copy from something unrelated just because both sit under a base class shared by dozens of foods.

When it finds one, it copies everything: nominal, min, lifetime, restock, quantities, cost, the flags, category, usage, value and tag. Only the name changes. When we added a canvas backpack from a clothing mod, for example, its values came from the vanilla TaloonBag_Blue, so it spawns where backpacks spawn, as often as a backpack should. The panel tells you which item the values came from, so you can check the match and adjust from there.

A few more details:

• Where it goes. By default, the new entry goes in the same file as the relative it copied from, or db/types.xml if there wasn’t one. To keep mod items in their mod’s own file, as above, pick that file in the item’s panel before adding it.
• No relative, no surprises. If nothing related is in your loot, the entry starts with nominal and min at 0, so it won’t spawn until you’ve decided how common it should be. Where it can, LootEngine fills in the category from the kind of item, and you choose the usage and value.
• Checked as you go. Each new entry is checked like any other, so a usage or value name your limits files don’t define is flagged before you save, and the pickers only offer names they do.

Duplicates and updates

Smart Add isn’t the only part that helps with a big mod list:

• Duplicates are flagged. Any class defined in more than one file shows up under Has problems, with a warning naming every file it’s in and which one the server uses.
• You always edit the live entry. The panel shows the file and line of the entry the server uses, and your edits go there, never to a copy that’s ignored. LootEngine also won’t add a class that’s already in one of your files.
• Mod updates show what changed. After an update, new classes show up under Not in loot files, and entries for classes the mod removed show up under Not in game data.
• Saves are safe. Edits to vanilla and mod files share one undo history, every save keeps a timestamped backup, and LootEngine saves only the characters you changed, so a diff against the mod’s original file shows exactly your edits.

LootEngine edits types.xml and the mod types files your mission lists. Registering folders in cfgeconomycore.xml, and mods’ cfgspawnabletypes.xml and events files, are still done by hand. Weapon loadouts are on the roadmap.

A checklist for every new mod

Once the layout is in place, adding mod number 51 takes a few minutes:

1. Copy the mod’s files into their own folder in the mission, and keep an untouched copy somewhere else.
2. Register the folder in cfgeconomycore.xml, with a comment saying which mod it is and when the files are from.
3. Run the duplicate check, and delete vanilla entries and anything another mod already defines.
4. Check the names against your limits files, and scale the numbers to fit your loot.
5. Add entries for any items the mod’s file missed.
6. Restart, read the logs, and go and find some of the new loot yourself.

Fifty mods will never be as simple as vanilla, but with one folder per mod and one entry per class, you always know which number the server is using, and why.

Questions

How do I add a mod's types.xml to a DayZ server?

Copy the mod's types file into its own folder in the mission, such as db/mods/WeaponsPack, and register it in cfgeconomycore.xml with a <ce folder="db/mods/WeaponsPack"> block containing <file name="types.xml" type="types"/>. The server also has to load the mod itself with -mod=. Changes take effect after a restart.

What happens when the same item is in two DayZ types files?

The server loads db/types.xml first, then the files listed in cfgeconomycore.xml in the order they appear, and the entry loaded last replaces any earlier entry for the same class. It replaces the whole entry, so nothing from the earlier one is kept.

Why aren't my modded items spawning?

Usually the item has no types entry at all, its nominal is 0, its usage or value names aren't defined in cfglimitsdefinition.xml or used on your map, its file isn't registered in cfgeconomycore.xml, or a file loaded later replaces its entry. Check the server logs after a restart.

Can LootEngine add types entries for mod items?

Yes. LootEngine reads the items from the Workshop mods you tick and lists the ones with no types entry. Adding one copies the settings of its closest relative already in your loot, such as its parent class or another colour of the same item, and checks the result before you save.