Exporting the game's tables

The server judges every hit itself - the attacker’s weapon against the armour on the part it struck - and resolves the keys a game mode and the chat commands use: an item by name, a horse breed by name, a buff by its class. Both need the game’s own tables, which the server does not have. data/combat/items.json is that export: the weapon and armour numbers and the lists of items, souls, buffs, consumables, weapon presets and prop meshes, read straight from the game’s files.

With it:

• a hit does what the game’s tables say it does ([combat] attack_scale, armour_pivot and the rest scale it - the combat model);
• items, souls, buffs and meshes answer to their names and ids as well as their GUIDs - /give shortswordBroad, /horse Horse2, GivePlayerBuff(pid, "potion_marigold_decoction"), /prop barrel_a - with the English names too (/give duelling longsword);
• the server owns potions, drink and the buffs it claims, and knows what each consumable does;
• chests hold what the game would put in them: the export carries the game’s loot tables and, for each level, the loot preset every chest is placed with and the loose item every slot on a table holds, so the server rolls a chest’s contents the way the single-player game does and restocks them on its own clock (the [containers] section; RollLoot in a mode);
• the server knows every door of the level - where it stands and which way it faces: GetNearestDoor in a mode, and the NPC characters open the doors they walk through ([actors] open_doors);
• the server knows where each of the level’s story layers stands - the walls, fences and heaps the story shows and hides: an admin finds the layer of whatever they stand at with /layer near, a mode with GetLevelLayersNear, and when a mode switches one off (Suchdol’s fence broken by a siege) the server’s own collision leaves it out too (the level’s layers);
• the audit can tell the items apart (the [audit] section): the item list says what each class is, which category it belongs to and how much it weighs, the weapon and clothing sets say exactly what a spawn’s outfit consists of - and how many of each item - the smithing recipes say what a player can forge at an anvil and from which materials, and the perks and consumables lists are what the progression check understands perks, potions, drinks and meals by.

Without it the server takes the damage the players’ games report (clamped by [combat] max_claim_damage), knows items, souls and buffs by their GUIDs only, and opens every chest empty. It says so at start: combat tables: ... not usable or nothing at all. The item check goes passive (item ledger: PASSIVE in the log): it follows what the players’ games report and removes nothing, until the file is there; the carry-weight check has no weights, and the progression check judges less of perks, potions and drinks.

After updating the server, export again. A file from an older version still loads, but it lacks the game’s clothing sets and the number of each item a weapon set gives (a bow set’s arrows): the spawn’s clothing is then credited by item category and a stack of arrows as one stack, up to a hundred, and the log says so (the clothing preset ... is not in the tables export). It also lists only one of the chests and table slots that share a name with others in the level (Kuttenberg and Trosky have hundreds): the others open empty and their items are not the level’s, and the log says to export again (lists one stash and one item slot of each name the level gives several). A file without the smithing recipes counts any melee weapon or horseshoe made at an anvil as forged without checking its materials, and the log says so at the start (smithing: no anvil recipes in this export). A file from before 2026-10-06 knows no story layer’s place: /layer near says to export again, and a layer a mode switches off stays solid for the server. The same goes after a game update.

Exporting it

On the machine that has the game, run tools/KcdMp.ExportTables.exe from the Windows server folder - double-click it, or from a terminal. It finds the game through Steam, the Xbox app or the Epic Games Launcher (or asks for the folder in a dialog), reads the game’s tables, the English names, the object files and the three levels’ own files, and writes data/combat/items.json into the server folder in a few seconds; the last lines say what it counted and where the file went. The game does not start.

KcdMp.ExportTables [--game <folder>] [--out <file>] [--no-names] [--no-meshes] [--voice-language <language>]

--game names the game’s folder when neither Steam, the Xbox app nor the Epic Games Launcher does; --out writes elsewhere; --no-names leaves the English names out (/give by English name stops working); --no-meshes skips the object files (a few seconds faster, no props by name; the levels’ chests, table slots and doors are still read); --voice-language picks the voice language the actors’ spoken lines are read from (english by default, else whichever voice language the game has installed - a warning says so; the lines are the same in every language, only their lengths differ). Without any voice language installed the export has no spoken lines and says so: actors then stay silent. --help prints the same.

Installing it

The tool puts the file where the server reads it. For a server on Linux, copy it into that server’s data folder as combat/items.json. The configuration names it:

[combat]
tables = "data/combat/items.json"

The server log confirms it at start: combat tables: data/combat/items.json (... weapons, ... armour pieces): damage from the tables.

The ids

The reference lists on this site - items, souls, buffs, meshes and the rest - are the same export of the same game build, so their numeric ids are the ones your server resolves. An id is a row number of a name-sorted export: the same for one game build, shifted by a game patch that adds things. Keep the name or the GUID in a game mode and in anything else durable; use the id at the chat line.

One export per game build: after a game update, export again, and the server picks the new file up at its next start.