dayz-split-types
Splits a monolithic DayZ types.xml into per-category files under db/types/ and registers them in cfgeconomycore.xml, backing up every changed file. Use when a mission's types.xml has grown too large t
SKILL.mdskills/dayz-split-types/SKILL.md
GitHub<!-- skill-dir-note -->
Path note:
<skill-dir>in commands below is the absolute path of this skill's folder. When the agent loads this skill the harness exposes the skill's base directory; substitute it before running. Sibling skills are reached via<skill-dir>\..\dayz-X\.
/dayz-split-types
Take a monolithic types.xml and split it into categorized XML files under a types/ subdirectory next to it, then point cfgeconomycore.xml (in the parent directory) at the non-empty ones and empty the original types.xml.
This skill wraps DayZ-n-Chill/DayZ-TypeSplitterPro. The upstream typeSplitter.py is vendored under vendor/; this skill adds the CLI front-end (path argument, preflight gate, backups, the <ce folder> fix, emptying the original, result verification, automatic restore on failure).
Follow skills/_shared/dayz-conventions.md.
How to run
python "<skill-dir>\split.py" <path-to-types.xml>
Typical:
python "<skill-dir>\split.py" .server\chernarus\mission\db\types.xml
What it does
- Preflight gate.
- Validate that
<types.xml>exists, has at least one<type>entry, thatcfgeconomycore.xmlis one directory up (DayZ standard layout:<mission>/cfgeconomycore.xml+<mission>/db/types.xml), and that both files are writable. - Back up
types.xml,cfgeconomycore.xmland any existingtypes/folder to<name>.<YYYYMMDD-HHMMSS>.bakbeside them. Every run makes new backups, so reruns never replace an earlier one. - Copy the vendored
typeSplitter.pynext totypes.xml(the upstream script findstypes.xmlthrough its own__file__), run it, then remove the temporary copy. - Fix
cfgeconomycore.xml. The Central Economy reads a<ce folder="...">path relative to the mission root (unverified against the vanilla files: vanillaP:\DZ\worlds\chernarusplus\ce\cfgeconomycore.xml:1-39has no<ce>block at all; this follows the community<ce>convention), but upstream writesfolder="types"while the files are indb/types/. The wrapper rewrites the attribute todb/typesand copies back any other<ce>blocks from the backup, which upstream deletes. - Verify the result:
types/exists, the category files hold exactly as many<type>entries as the originaltypes.xml, every non-empty category file is listed under<ce folder="db/types">, and every listed file exists at<mission>/<folder>/<name>. The upstream script only logs its errors and always exits 0, so this check decides success. Fails if a category file is not listed; a listed file that does not exist (for example from a restored custom<ce>block) is a warning. - Replace
types.xmlwith an empty<types>stub. The server always loadsdb/types.xml, so leaving the full file in place would load every type twice and edits to the split files would not be the only definition. The original is in this run's backup. - On any failure from step 4 on (the splitter exits non-zero,
types/is missing, the entry count does not match,cfgeconomycore.xmlis invalid or incomplete,types.xmlcannot be emptied, or an unexpected error), copycfgeconomycore.xmlandtypes.xmlback from this run's backups, delete the regeneratedtypes/folder and put back the earlier one if there was one, then exit 1. The.bakfiles are kept. If the restore itself fails (a file is locked), it prints[FAIL] Automatic restore failedwith the numbered copy and delete steps, naming each.bakpath, to finish by hand.
What gets created
<dir>/types/, holding one file for each of the 19 categories:ammo,armbands,ammo_boxes,animals,contamination,flags,staticObjs,vehicles,wrecks,zombies,seasonal,clothes,explosives,containers,food,tools,weapons,vehicleParts,uncategorized(each.xml). Categories with no entries are still written as an empty<types/>file. Any existingtypes/folder is deleted and regenerated (after being backed up).types.xml.<stamp>.bak,cfgeconomycore.xml.<stamp>.bakand, iftypes/existed,types.<stamp>.bak/: backups from this run. Delete old ones when you no longer need them.<mission>/cfgeconomycore.xml: rewritten with one<ce folder="db/types">block listing each non-empty category file, followed by the<ce>blocks it had before. Upstream's formatter keeps only<classes>(its<rootclass>entries) and<defaults>; comments and any other element are dropped, so compare against the backup if you had hand edits.<mission>/db/types.xml: replaced with an empty<types>stub (see step 7). To split again, restore it from atypes.xml.<stamp>.bakbackup first.
Refuses to run if
/dayz-preflightreturns non-zero (required by the Environment rule inskills/_shared/dayz-conventions.md).<types.xml>doesn't exist, isn't namedtypes.xml, isn't valid XML, or has no<type>entries (already split).cfgeconomycore.xmlisn't in the parent directory (the upstream tool requires that layout).types.xmlorcfgeconomycore.xmlis read-only (common for files copied from a server install). Clear it withattrib -r <file>and rerun. Nothing is backed up or changed.
Output
[OK] Backup: .server\chernarus\mission\db\types.xml.20261020-170428.bak
[OK] Backup: .server\chernarus\mission\cfgeconomycore.xml.20261020-170428.bak
... (typeSplitter logging) ...
[OK] Split into 14 non-empty category files in .server\chernarus\mission\db\types
ammo.xml
ammo_boxes.xml
... (more)
[OK] Updated .server\chernarus\mission\cfgeconomycore.xml (<ce folder="db/types">)
[OK] Emptied types.xml: its 2364 entries now load from db/types/ (original kept in types.xml.20261020-170428.bak)
On a failure after the splitter started, the last lines are the [FAIL] reason and:
[OK] Restored cfgeconomycore.xml, types.xml and types/ from this run's backups, so the mission is as it was before the run.
Attribution
The categorization logic and cfgeconomycore.xml formatting belong to DayZ-n-Chill/DayZ-TypeSplitterPro. To update the vendored copy, fetch the latest upstream typeSplitter.py and replace vendor/typeSplitter.py, keeping its attribution header.
Do not
- Don't modify the vendored
typeSplitter.pyto add features. Contribute upstream and re-vendor, so this skill stays a thin wrapper. - Don't rely on the
.bakfiles alone for a mission you care about. Commit the mission folder or copy it elsewhere first.