DayZ Container Loot Editor

How DayZ decides what is in a container

• A container gets its content from cargo blocks under its own entry in cfgspawnabletypes.xml. Each block rolls once against its chance. If the roll succeeds, exactly ONE item out of that block is placed inside; if it fails, the block yields nothing. Two items at once therefore need two blocks, which is why vanilla gives an Assault Bag three identical mixArmy blocks.
• Inside a block the chance on each item is NOT a percentage, it is a selection weight. The real chance for one item is block chance times its weight divided by the sum of all weights in the block. A block at 0.60 with ten items of weight 0.10 each gives every single item a 6 percent chance, not 10.
• A block can also point at a shared loot group in cfgrandompresets.xml instead of listing items itself. That is convenient and dangerous at the same time: on Chernarus the group foodVillage is used by 24 containers, 16 infected and 11 pairs of trousers, so widening it feeds the zombies too. The editor shows that count on every group and offers to detach a group into a private block.
• Two limits are easy to miss in a plain XML editor. Space: an AKM measures 8 by 3 slots and never fits into a 4 by 5 sling bag, so the engine simply drops it. Economy: an item that is not listed in the map's db/types.xml is skipped silently at server start, and the block is wasted. This editor checks both while you type.

The three files involved

All paths below start at your mission folder, for example mpmissions/dayzOffline.chernarusplus/. Which mission is running is written in serverDZ.cfg under template.

• cfgspawnabletypes.xml

  Sits directly in the mission folder, next to init.c, and NOT in db/. Holds one entry per class that spawns with something in or on it: containers, infected, wrecks, weapons with attachments. This editor only touches the container entries and leaves the other roughly 300 alone.

• cfgrandompresets.xml

  Also in the mission folder. Holds the shared loot groups that entries in the first file point at by name. Neither file is listed in cfgeconomycore.xml; the engine loads both by itself, so there is nothing to register.

• db/types.xml

  Not edited here, but it decides whether your entries do anything at all: a class missing from types.xml is skipped when the server starts. If you add a modded item to a container, add it to types.xml as well. The editor marks items that are missing from the current map.

From the editor to your running server

1. 1

   Pick the map first

   Chernarus, Livonia and Sakhal carry different loot groups and different types.xml. Editing on the wrong map and copying the result over silently changes what spawns, so switch to the map your server runs before you touch anything.

2. 2

   Load your own file if you have one

   If your server already runs a tuned economy or mods with their own containers, load its cfgspawnabletypes.xml through the button in the toolbar. The editor then builds every export on top of your file instead of the vanilla one.

3. 3

   Edit the containers

   Pick a container, add blocks, and watch the preview on the right: it shows how many out of 100 containers carry each item, whether the content fits into the grid and whether every class exists in the map's economy. Use the filter "Spawns empty" to find the containers that currently give nothing.

4. 4

   Choose add-only or whole files

   In the output tab, "Only add snippets" gives you just the changed blocks with a note per block saying whether it replaces an existing entry or is new. That way your files keep everything else. "Whole files" gives you two finished downloads instead, which is faster but replaces the files completely.

5. 5

   Stop the server, back up, edit

   Both files are read once at mission start, so the server has to be down. Copy cfgspawnabletypes.xml and cfgrandompresets.xml aside first, then paste the snippets in or upload the new files. New loot groups must be in cfgrandompresets.xml before any type points at them.

6. 6

   Start and check

   Start the server and let it come up fully. Containers already lying in the world keep their old content until they despawn, so give it a restock cycle before you judge the result. If the server does not start at all, the cause is almost always broken XML in one of the two files.

Traps that cost people an evening

• •Loot groups are map specific. Several groups carry different item lists on Chernarus, Livonia and Sakhal, so copying one map's file onto another server silently changes its loot. The editor keeps the three maps apart for exactly that reason.
• •Case matters for you, not for the engine. Vanilla writes Slingbag_Black while the game config says SlingBag_Black. The engine tolerates both, but if you paste one spelling next to an existing entry with the other, the class ends up in the file twice and only one of the two entries takes effect.
• •Commented-out entries stay dead. If a type sits inside an XML comment, editing it there does nothing on the server. When you paste a snippet, make sure the block you replace is not inside a comment.
• •cfgspawnabletypes.xml does not belong to the containers alone. Of roughly 584 entries on Chernarus, only about half are containers; the rest are infected, wrecks and weapons. Exporting a file that holds only the container part would take the loot away from all of them, which is why the full export always merges into a complete file.
• •More blocks do not mean more loot if the space runs out. The engine places the drawn items one after another and drops whatever no longer fits, so a small bag with six blocks yields less than the numbers suggest. The preview warns as soon as the worst case exceeds the grid.
• •Two tools write the same file. This editor and the zombie editor both change cfgspawnabletypes.xml. If you use both, take the add-only snippets from at least one of them, or load your current server file here before exporting whole files, otherwise the second export undoes the first.

Frequently asked questions