DayZ server mods and keys, and why players get kicked on join

A player picks a modded DayZ server, clicks join, and is back at the menu within seconds with a warning box: a hexadecimal code in its title, a line saying they were kicked, and a reason from the server's file check. On a modded server that check fails when the player's mods and the server's do not match, or when the server has no key to verify them.

Since update 1.22 the check runs at the very start of login, so a player with missing or outdated mod files is turned away before reaching the queue. Almost every fix is on the server side, in the launch line and in the keys folder.

How the server loads mods

A DayZ server loads mods from folders in its own directory, by convention named with an @ in front, each holding an addons folder of PBO files and usually a keys folder. The launch line says which ones to load:

DayZServer_x64.exe -config=serverDZ.cfg -port=2302 "-mod=@CF;@SomeMap;@SomeWeapons" -serverMod=@SomeServerTool -profiles=profiles

-mod= takes a semicolon-separated list of mods that players must have as well. -serverMod=, added in update 1.04, loads mods on the server alone; Bohemia's configuration reference describes them as not broadcast to clients, so players never download them and there is nothing of theirs for the join check to compare. Admin tools and server-side logic belong there when the author says the mod works that way, and server-side versus client-side mods explains why some can and some cannot. Both parameters accept absolute paths.

On Linux, Bohemia's modding guide asks authors to keep the addons and keys folders, and the files inside addons, in lower case for the Linux server. A mod that ships Addons or Keys is the first thing to check on a Linux box.

Keys, and the verifySignatures line

serverDZ.cfg holds the line that makes keys matter:

verifySignatures = 2;

Bohemia's server configuration reference describes it as verifying .pbo files against .bisign files, and notes that only 2 is supported. Every PBO in a signed mod has a .bisign beside it, made with the author's private key, and the matching public key is the .bikey in the mod's keys folder. When a player joins, the server checks the signatures on their mod files against the keys in its own keys folder, so every client mod's .bikey has to be copied there. Miss one and every player running that mod is kicked at the file check, while the server itself starts and runs normally. Update 1.04 made the same setting verify mod addons and deprecated the older equalModRequired option.

Bohemia's modding guide shows verifySignatures = 0 together with allowFilePatching = 1 for testing unsigned mods on a local setup. Those are development settings for a machine only you connect to.

Load order and dependencies

A mod's Workshop page lists the items it requires, and Community Framework (CF) is a common one; Bohemia's own Linux example installs it alongside Community Online Tools. The usual practice is to put dependencies before the mods that use them in the -mod list, and to keep that order stable as the list grows, so a new mod goes on the end.

Getting Workshop mods onto the server

Bohemia's Linux hosting guide installs the server and its mods with SteamCMD, logged in with a Steam account:

./steamcmd.sh +force_install_dir ~/servers/dayz-server/ +login your_login +app_update 223350 +workshop_download_item 221100 1559212036 +quit

223350 is the stable DayZ server (the experimental one is 1042420), and workshop_download_item 221100 followed by an item ID fetches a Workshop mod under the game's own app ID; 1559212036 is Community Framework. The files land in steamapps/workshop/content/221100/, in a folder named after the item's ID, and the guide links each mod into the server directory and its keys into keys. Updating is the same command run again, so it belongs in whatever script restarts the server. The SteamCMD guide covers the tool itself, and Workshop content on a server covers the dependency it creates.

How players end up with the same set

DayZ loads mods when the game starts, so joining a modded server means starting the game with that server's mod set. The in-game server browser marks modded servers and can list their mods, but on PC the practical route is a launcher that sets up the mods and starts the game: the DayZ Launcher that installs with the game, whose server browser and direct-connect window handle modded servers, or the unofficial DZSA Launcher. The mods themselves come from the Steam Workshop. A long list makes the first join slow, and what makes a modded join slow has the arithmetic; the basic steps are in installing DayZ and joining a server.

The mission folder, and why types.xml comes up

A mod that adds items has a second job to do on the server. Loot is handled by the Central Economy, from the mission folder named in serverDZ.cfg:

class Missions
{
    class DayZ
    {
        template = "dayzOffline.chernarusplus";
    };
};

That folder, mpmissions/dayzOffline.chernarusplus/, holds db/types.xml, where each spawnable item has an entry with its nominal count, minimum, lifetime, restock time and where it can appear. An item with no entry never spawns as loot, however well the mod itself works, which is why types.xml comes up as soon as a mod adds items.

Since update 1.08 there is no need to paste a mod's entries into the vanilla file. Inside its economycore element, cfgeconomycore.xml can name extra files:

<ce folder="custom">
    <file name="weaponspack_types.xml" type="types" />
</ce>

Bohemia's page on the feature lists types, spawnabletypes, globals, economy, events and messages as the file types, and notes that mod authors can ship their own XML for owners to include. One file per mod turns the next update into a file swap instead of a merge.

When a mod updates under you

Workshop updates reach players whenever Steam downloads them, and the server only changes when you run SteamCMD. The kick reasons in the game's own scripts cover both directions, a client holding a newer version of a mod than the server and a server newer than the client, so the gap between an author's update and your next restart is when players start bouncing. Update the server's copy as soon as you know and restart it. Then check whether the author changed the key. Bohemia's example update script deletes the old .bikey and links the new one on every run, and a stale key causes the same kicks as a missing one.

Game updates are the larger risk. Bohemia's notes for the 1.29 experimental build said its changes would affect mods and framework mods, many of which might not work properly at first, and asked server owners to review their dependencies. The notes for 1.30 experimental warned of problems with animation-related mods. On past cycles stable has followed experimental by four to six weeks, which is the window to run a copy of your server on the experimental branch with your full mod list and see what breaks. Updating a modded world safely covers the backup side of that.