DayZ Modding Knowledge Pack

A distilled, battle-tested knowledge base for DayZ (Enfusion) modding, assembled by a
working DayZ modder and their AI assistant across dozens of shipped mods — vehicles, aircraft,
weapons, characters, base-building, persistence systems, and full Blender→.p3d asset pipelines.

It is meant to be handed to an AI coding assistant (Claude Code, or any capable LLM agent)
so it can help you mod DayZ with the same playbooks, tools, and hard-won gotchas that produced
those mods.

It contains three things:

0. TL;DR for the assistant reading this

If you are an AI assistant tasked with helping the user mod DayZ, internalize this first:

1. A "skill" is a playbook you load on demand. Each skills/<name>/SKILL.md starts with a
   description: that lists its trigger conditions. When the user's task matches, open that
   SKILL.md, follow it, and pull files from its references/ folder only when the procedure
   points you there (progressive disclosure — don't read everything up front).

2. The one rule that makes DayZ modding work: never invent an API. DayZ punishes
   confabulation with silent failures — a class that never binds, an action that never shows,
   a model that loads white. Before you write any Enforce Script function, config class, .p3d
   selection name, or memory point, grep the vanilla source (P:\scripts\ — see
   knowledge/DAYZ_INFRA.md) or a reference in this pack, and cite path:line. Then use it.
   This discipline is baked into every skill here; keep it.

3. The client/server split is not optional knowledge. Most "it doesn't work" bugs are a
   value read on the wrong side. Map which side owns each piece of state before writing a
   feature. enforce-script-reference and knowledge/ cover this.

4. In-game testing is expensive (3–10 min per cycle). Do all offline analysis first, batch
   every pending change into one test, and have a plan B/C ready before you ask for a rebuild.

5. Before starting real, multi-session work with this pack, ask the human which durable
   memory they will use. Recommend Obsidian (free, plain Markdown; the
   vault layout is in §7) or an equivalent plain-Markdown folder; offer to create the skeleton
   (project brief, verified APIs, assumptions, decision log, bug ledger, session handoffs). Do
   not silently proceed without one. What a session learns is gone in the next if it only lives
   in the agent — this pack itself came out of writing those facts down outside it.

1. What's inside

DayZ-Modding-Knowledge-Pack/
├── README.md                     ← you are here
├── AGENTS.md                     ← how an agent should work with this repo
├── TOOLS.md                      ← what each tool does and how to run it
├── compatibility-matrix.md       ← per-skill build/evidence status
├── CONTRIBUTING.md               ← evidence, privacy and contribution rules
├── THIRD_PARTY_NOTICES.md        ← included and research-only attributions
├── sources/                      ← provenance and executable-claim contracts
├── skills/
│   ├── _shared/                  ← conventions referenced by several skills
│   │   ├── dayz-conventions.md
│   │   └── enscript-style.md
│   ├── enforce-script-reference/ ← Enforce Script + config.cpp reference
│   ├── dayz-ai-patterns/         ← Expansion eAI FSM / targeting / groups
│   ├── dayz-mod-workflow/        ← implement/debug protocol (client/server, anti-confabulation)
│   ├── dayz-vehicles/            ← cars, trucks, quads, bikes, boats (CarScript)
│   ├── dayz-aviation/            ← planes, seaplanes, helicopters
│   ├── dayz-weapons/             ← custom firearms (entity side)
│   ├── dayz-characters/          ← infected, survivors, NPCs (rig to OFP2_ManSkeleton)
│   ├── dayz-clothing/            ← wearable items, custom skeletons, proxies
│   ├── dayz-model-pipeline/      ← author .p3d + LODs + config from Blender/py3d
│   ├── dayz-p3d-audit/           ← collision / winding / silent-killer audit
│   ├── dayz-p3d-inspector/       ← Recipe JSON + Three.js editor
│   ├── dayz-proxy-align/         ← visual proxy gizmo + lossless write-back
│   ├── dayz-basebuilding/        ← buildable structures (BaseBuildingBase)
│   ├── dayz-persistence/         ← OnStoreSave/Load, schema migration, data safety
│   ├── dayz-texture-pipeline/    ← .paa / .rvmat / native PBR maps
│   ├── dayz-particles/           ← .ptc / .emat particle pipeline
│   ├── dayz-sound-system/        ← CfgSoundShaders/Sets + client audio API
│   ├── dayz-ui-development/      ← .layout / widgets / Dabs MVC
│   ├── dayz-doors/               ← class Doors on buildings and static props
│   ├── dayz-physics-engine/      ← dBody*/raycast/layers/EOnContact
│   ├── dayz-preflight/           ← P:\ / Tools / workshop env check
│   ├── dayz-pbo-build/           ← pre-build validation + AddonBuilder packaging
│   ├── dayz-test-ingame/         ← build + deploy + launch with DayZDiag + filepatching
│   ├── dayz-mcp-verify/          ← auto-test a mod by driving it (see §8 and the bridge note)
│   ├── dayz-pbo-reverse-engineering/  ← learn from another author's PBO
│   ├── dayz-feature-spec/        ← spec + consistency gate before coding
│   ├── rip-vehicle-import/            ← convert a ripped racing-game car into a drivable DayZ vehicle
│   ├── rigorous-data-audit/      ← audit persistence/state-machine code before release
│   ├── blender-animation/        ← author animations in Blender (via MCP) → DayZ
│   ├── dayz-animation-pipeline/  ← model.cfg / RTM / SEAnim / weapon anim
│   ├── dayz-realistic-animation-director/ ← realistic motion gates + offline audit
│   ├── mixamo-retarget/          ← Mixamo/FBX retarget (no Mixamo assets shipped)
│   ├── blender-assembly/         ← build geometry in Blender via MCP
│   ├── blender-visual-review/    ← render-and-look review loop
│   ├── 3d-generation-harness/    ← research → plan → build → roast → ship
│   ├── uv-clean-atlas/           ← legible UV atlases (SAT-zero overlap)
│   ├── ai-3d-to-dayz/            ← AI-generated 3D (Hunyuan/Tripo/TRELLIS) → DayZ
│   ├── ardy-motion-generation/   ← motion generation → DayZ integration
│   └── dayz-3d-viewer/           ← MLOD .p3d / PAA / RVMAT → glTF + HTML viewer
├── tools/                        ← see TOOLS.md
│   ├── py3d/                     ← DayZ fork of py3d (MLOD .p3d codec), MIT
│   ├── dayz-animation-formats/   ← strict RTM/SEAnim v1 reader/writer/inspect
│   ├── dayz-model-preflight/     ← contract-driven MLOD export gate
│   ├── dayz-odol-strict/         ← read-only ODOL v53-v55 anatomy/diff adapter
│   ├── dayz-ui-lab/              ← offline .layout parse / compose / render / diff
│   ├── dayz-layout-viewer/       ← one .layout at four viewports, in one HTML
│   ├── dayz-script-validator/    ← pre-PBO linter: Enforce, config.cpp, .layout, .rvmat
│   ├── dayz-vehicle-proxy-contract/ ← offline vehicle-proxy reachability + fit gate
│   └── dayz-3d-viewer/           ← MLOD .p3d / PAA / RVMAT → glTF + HTML
├── examples/                     ← worked examples that chain the tools
│   └── end-to-end/               ← synthetic MLOD through preflight + viewer
└── knowledge/
    ├── DAYZ_TECHNICAL_NOTES.md   ← py3d MLOD facts, LODs, winding, config, runtime
    ├── DAYZ_INFRA.md             ← drives, AddonBuilder, serverDZ.cfg, RPT triage, terrain
    ├── dayz-mcp-bridge-protocol.md  ← driving DayZDiag from an agent (see §8)
    └── vault-notes/              ← 16 topic notes (see §6)

2. How to use the skills

What a skill is

A skill is a folder with a SKILL.md (the procedure, with YAML front-matter: name,
description) and usually a references/ folder of deeper material the procedure links to.
The description is written as trigger conditions — read it as "invoke me when…".

If your assistant is Claude Code

Copy the skill folders into a skills directory Claude Code reads:

• Project-scoped: <your-project>/.claude/skills/
• User-scoped (all projects): ~/.claude/skills/ (Windows: %USERPROFILE%\.claude\skills\)

Copy the contents of skills/ into one of those (keep _shared/ alongside them — several
skills reference _shared/dayz-conventions.md and _shared/enscript-style.md). Claude Code
auto-discovers them by their front-matter and invokes them by trigger; you can also call one
explicitly, e.g. /dayz-vehicles.

If your assistant is a different LLM / agent

There is nothing Claude-specific about the content. Use them as retrieval-and-follow
playbooks:

1. Match the user's task against the description: blocks (a cheap way: concatenate all
   SKILL.md front-matters into your context as a routing table).
2. When one matches, load that whole SKILL.md into context and follow it step by step.
3. Load a file from references/ only when the procedure names it.

Do not dump the entire pack into context at once — it is large by design. Route, then load.

AGENTS.md says the same thing in the form most agent hosts expect to read;
GEMINI.md, .cursorrules and .github/copilot-instructions.md are entry points that lead
back to it.

3. Skill index

Vehicles & aircraft

Weapons, characters & animation

Base building

3D / AI asset pipeline

Script, audio, VFX, UI, doors & physics

Process, QA & tooling (domain-agnostic — use them across all of the above)

4. What is in the pack, and what you still install separately

These playbooks are the author's. The local plugin folder they were installed under happened
to be named anthropic-skills; that is a namespace on one machine, not a licence or an
upstream. They ship under the same MIT licence as the rest of the pack.

Shipped in this pack

Every playbook listed in §3 lives under skills/ and loads like any other skill here.
That is the complete set the author chose to distribute.

Six of the p3d/pipeline playbooks used to vendor a py3d 1.4.0 wheel; the wheel is not
in the pack. Install the pack fork with pip install -e tools/py3d (1.5.0, distribution
py3d-dayz, import py3d).

True external dependencies

These are not in the pack and have to be installed (or already present) on the machine that
builds and tests mods:

There is nothing to install from an "Anthropic skills" marketplace for this pack.

The in-game half: DayZ-MCP

Everything in this pack is offline. Every gate here ends at the same sentence — now go
look in game — and that step is the expensive one: a rebuild, a server, a client, a scenario
set up by hand, several minutes per iteration. DayZ-MCP
(MIT, its own repository) is what lets an agent take that step itself.

It is an MCP server that drives a running DayZDiag server and client. 75 tools (+
exec_enforce when an allowlist is configured) — exec_enforce is an escape hatch, off by
default behind an exact-match allowlist. They group into: a session lease so two agents
cannot fight over one game, queries on player state, world mutation (spawn, delete,
animate, time, weather, inventory, teleport), scene reads (raycast, surface query, object
inspect, telemetry), camera and capture, a vehicle group (enter, engine, control,
telemetry, trace), weapons, actions and input, UI, knowledge, playbooks,
the pipeline inbox, and lifecycle: dayz_test_run builds a mod, starts a diag server
and client with it loaded, and waits for readiness.

The detail that shows it was built against the engine and not against a wish: the split is not
by tool group, it is by peer. vehicle_enter seats a player server-side; only
vehicle_get_in_client, which makes the client take ownership, lets you actually drive.
Facts of that shape — SetThrottle setting future input that CarScript.OnInput then
overwrites, DEVELOPER not being defined in DayZDiag while DIAG_DEVELOPER is, freecam
freezing the simulation you are trying to measure — cost in-game cycles to learn and are
written down in knowledge/dayz-mcp-bridge-protocol.md,
each cited to vanilla path:line.

git clone https://github.com/willy92wins/dayz-mcp
cd dayz-mcp\tools
.\install-mcp.ps1 -Register

.mcp.example.json in this repository is the client wiring that installer writes. The skill
that consumes it is dayz-mcp-verify; the acceptance ladder it runs
for a drivable vehicle is spawn → render → get-in → drive → wheel direction.

What it is not. It is not a test framework: it drives the engine and reports, and deciding
what counts as a pass stays with the caller. Headless execution is bounded by the engine — some
operations need a real client attached, which is DayZ's limitation and not a design choice. A
live daemon serves the modules it loaded at start, so a newly added verb does not exist until it
restarts. And multi-client behaviour is under-tested, because one Steam account is one client.

5. 3D tooling

Full index, including tools/dayz-ui-lab and what each tool refuses to do:
TOOLS.md.

tools/py3d

tools/py3d/ is a DayZ-specific fork of KoffeinFlummi/py3d
(MIT) — a pure-Python reader/writer for the MLOD .p3d format (the editable, non-binarized
model format). Most asset scripts in these skills import it. Upstream is an unmaintained minimal
codec; this fork (__version__ = "1.5.0", IS_DAYZ_FORK = True) adds anti-corruption guards so
the paths that used to silently corrupt a .p3d now fail early with an actionable message.

Highlights (see tools/py3d/README.md for the full list):

• lod.new_selection(name) — get-or-create a named selection that binds and registers correctly.
• lod.set_memory_point(name, xyz) / lod.get_memory_points() — idempotent memory-point upsert.
• lod.faces_by_material() / faces_for_material(n) — case-insensitive material match.
• p3d.save(path, verify=True, backup_dir=...) — atomic write with reopen+parse+invariant verify;
  on failure the original stays byte-intact.
• p3d.validate() → list[Finding] with codes (stale selection, weight range, normals budget…).
• Complete fail-closed proxy lifecycle: raw/engine frame conversion,
  add_proxy, strict enumeration, in-place align and index-safe remove.

Install: it targets Python 3. From the pack root:

pip install -e tools/py3d        # editable install
# then, in scripts, assert you got the fork (PyPI 'py3d' is a DIFFERENT library):
python -c "import py3d; assert getattr(py3d,'IS_DAYZ_FORK',False); print(py3d.__version__)"

Or just add tools/py3d/ to PYTHONPATH. License: MIT — tools/py3d/LICENSE (© 2017 Felix
Wiegand, upstream author); keep that file with any redistribution.

tools/dayz-animation-formats

Strict stdlib reader/writer for SEAnim v1 and DayZ RTM (RTM_MDAT and
RTM_0101) plus deterministic JSON inspection:

python -m dayz_animation_formats inspect input.rtm --output anatomy.json

Frozen first-party fixtures are independently decoded by
Arma3ObjectBuilder during validation. BMTR and .anm conversion remain
explicitly out of scope; unsupported signatures fail closed.

tools/dayz-model-preflight

Read-only MLOD gate driven by a versioned JSON contract. It composes
py3d.validate() with intended scale, required non-empty bone selections and
determinant-aware face-lineage/winding checks:

python -m dayz_model_preflight check target.p3d \
  --contract preflight.json --json preflight-result.json

The DayZ py3d fork >=1.4.0 is required. Missing or ambiguous one-to-one
lineage is INVALID; the tool never guesses a mapping or repairs a model.

tools/dayz-odol-strict

Fail-closed, read-only ODOL v53-v55 anatomy inspection and deterministic diff:

python -m dayz_odol_strict inspect input.p3d \
  --backend-root <external-backend> --json anatomy.json
python -m dayz_odol_strict diff reference.json candidate.json

The adapter, schemas and three user-authorized first-party fixtures are
redistributable. The compatible BisDLL-derived backend has no redistribution
license and is therefore external, hash-pinned and loaded only in an isolated
subprocess. No ODOL writer or partial-success mode is included.

tools/dayz-3d-viewer

MLOD .p3d plus optional PAA/RVMAT to a .glb and a Three.js HTML viewer
(embedded or web):

python -m dayz_3d_viewer build-viewer model.p3d --textures ./tex --mode embedded

Requires the pack py3d fork >=1.5.0. Pillow and LZO are optional extras.
Generated HTML loads three.js 0.160.0 from jsDelivr and is not self-contained
offline. Documented converter gaps live in
tools/dayz-3d-viewer/KNOWN-ISSUES.md.

6. Knowledge notes

knowledge/ is verified reference material — facts to consult, but still cite-then-verify
against the vanilla source for your game version (the engine moves).

• DAYZ_TECHNICAL_NOTES.md — py3d MLOD reader facts, the canonical LOD resolutions
  (Geometry / Memory / LandContact / ViewGeometry / FireGeometry), winding handedness
  Blender→DayZ and the canonical fix, debris/selection centroids, single- vs double-sided faces,
  Container base requirements, magazine ammo, JSON schema migration, loot resolution cascade.
• DAYZ_INFRA.md — the environment: drive layout and the P:\ work-drive convention,
  AddonBuilder / DayZDiag commands, serverDZ.cfg allowFilePatching, mission templates, texture
  suffixes, .p3d named properties, Central Economy file layout, BattlEye codes, RPT triage,
  terrain pipeline.
• dayz-mcp-bridge-protocol.md — driving DayZDiag from an agent: the bridge's tool surface,
  the invariants that keep it safe (server-authoritative, one FIFO lease, fail-closed ingress,
  deadman-held controls), and the engine facts it cost in-game cycles to learn — client vs
  server vehicle ownership, why SetThrottle alone never moves a car, DIAG_DEVELOPER vs
  DEVELOPER, and why freecam freezes the thing you are trying to measure.
• vault-notes/ — 16 topic notes, including: dayz-animations-creatures-weapons,
  dayz-custom-infected, dayz-enforce-script-reference, dayz-mod-implementation-checklists,
  dayz-modded-class-server-stub-pattern, dayz-objectbuilder-lod-conventions,
  dayz-wiki-systems-reference, dayz-wrp-roadgraph-extraction, uv-mapping-dayz, and
  cross-project syntheses for vehicles and weapon configs.

vault-notes/ is a slice of the author's durable-memory vault — the practice described in §7,
which is where this whole pack came from. If you take one process idea away, take that one.

The vault notes use Obsidian [[wikilink]] syntax. Some links point to the author's own
process notes that are not included in this pack — treat those as contextual pointers; the
substantive knowledge is inline. Links between notes that are here still resolve.

7. Working conventions that make AI-assisted DayZ modding reliable

These are the process rules — distilled from many painful cycles — that the skills enforce. They
are the real value; keep them even if you adapt everything else.

1. Verify every API before you use it. Grep the vanilla scripts (P:\scripts\ → 1_core,
   3_game, 4_world) or a reference here, and cite path:line. Memory and semantic search are
   hints, not facts — open the file.

2. Trace an invariant to every call-site. When a change alters a system invariant (not just a
   local bug), grep all sites that assumed the old one and propagate the fix. The classic bug is
   "fixed it here, forgot the adjacent site."

3. Walk it end-to-end before declaring it done. Compiling ≠ correct. Mentally run the happy
   path, then kill the process between each I/O pair (crash recovery), then re-check admin/reset
   flows. For data-critical code, run rigorous-data-audit.

4. Respect the client/server split. Decide which side owns each value before coding; most
   "doesn't work" bugs are a read on the wrong side.

5. Batch in-game tests. A test cycle is minutes. Exhaust offline analysis (grep logs, simulate
   the fix in Python) and apply all pending fixes before asking for one rebuild; keep a plan B/C.

6. Be honest about verification. State what you verified, how (grep / checksum / repro /
   in-game), and what you did not. "It compiles" is not "it works." An error of exactly 0.000 in
   a test is suspicious (a tautology), not perfection.

7. Keep a durable memory outside the agent. This is the rule that produced everything else
   here, and the one most people skip.

   An assistant's context dies at the end of the session. Without somewhere to put what was
   learned, every session re-derives the same facts, re-proposes hypotheses that were already
   refuted, and re-pays for the same in-game cycles. The fix is boring and it works: a plain
   Markdown vault, in version control, that outlives the conversation.

   The author's is Obsidian — free, local-first, plain .md files on
   disk with no lock-in, which is exactly why it suits an agent: any assistant can grep it, and
   the notes stay readable if the app disappears. The [[wikilink]] syntax you will see
   throughout knowledge/vault-notes/ is Obsidian's, and it is the whole mechanism: linked notes
   let a fact be written once and reached from every context that needs it. Any tool over plain
   Markdown works the same way.

   What earns a note is narrow: a verified API with its path:line, an assumption that
   turned out false and why, a decision and the alternative it rejected, a bug and the
   measurement that found it. Not transcripts, not summaries of what you did — those are
   recoverable from git. Convert relative dates to absolute; "last week" ages badly.

   Three surfaces, three jobs, and keeping them distinct is what stops the drift: git is the
   distributable source, the vault is durable memory and full evidence including the private
   parts, and installed skills are the operational deployment. Knowledge flows outward from
   the vault into skills; releases are never built from an installed copy.

8. Caveats & disclaimers

• Example project names are illustrative. The skills cite the author's real mods (e.g.
  LFQuad, SUB_BRZ/BRZ, MercedesAMGLF, A6_SR2M, LF_VStorage, LFPowerGrid,
  KT-Roadkill) as where a given rule came from. The rules are general; the mod source is not
  included. Treat the names as case-study labels.
• One skill assumes the author's local tooling layout. dayz-test-ingame generates a
  Windows PowerShell orchestrator around a specific setup (the P:\ work-drive junction,
  AddonBuilder, a <Mod>_dev\tools\ convention). The ideas transfer; the generated scripts
  will need to be re-pointed to yours.
• One skill needs a service you install separately. dayz-mcp-verify drives the game
  through DayZ-MCP, which is published as its own
  repository under MIT and installs independently of this pack. It is no longer private
  infrastructure; see §4 — The in-game half — for what it does and how to wire it.
• Skills the author keeps private. A handful of the author's other playbooks stay
  unpublished (process/handoff helpers and some local-only tooling). They are not
  dependencies of this pack and are not listed in §3 or §4.
• Placeholders. Angle-bracket tokens like <notes>, <research-notes>, <skills>,
  <claude-home>, <tmp>, and C:\Users\<you>\… replace the author's private local paths. P:\
  is the standard DayZ work-drive convention, left as-is.
• Provenance & integrity. Releases are built from the versioned
  sources/source-map.json, scanned for secrets,
  identities and private paths, and checked for broken local links. Physical
  source and promotion roots stay in ignored local configuration.
• Licensing. Original pack material is MIT under LICENSE.
  tools/py3d retains its own upstream MIT license. Research-only GPL,
  DPL-ND, proprietary and unknown-license material is not release payload; see
  THIRD_PARTY_NOTICES.md.
• Moving target. DayZ/Enfusion changes across versions. Dates and version-specific facts are
  noted where known; re-verify against your game build and consult the
  compatibility-matrix.md.

9. Updates and releases

For every skill listed in promotions/promotion-map.json, this repository is
the editable source: a change lands here first (the skill, a resealed
sources/source-map.json, packctl validate green) and is then promoted into
the installed skill trees with packctl promote. Those installed trees are
promotion targets, not working copies; a hand edit there is what
PROMOTION-TARGET-UNEXPLAINED exists to catch (CONTRIBUTING.md §7).
Harvest from a working store is by UNION, never a wipe of the destination.
A release is created only after
python -m packctl gate --root . passes from a clean commit and two clean
builds produce the same SHA-256. The Cowork plugin tree is ephemeral.
The pack is the OFFLINE layer; DayZ-MCP is the ONLINE/in-game layer.

For a DayZ stable update, first pin the exact build and diff the relevant
vanilla contracts, then rerun offline validation and the smallest
representative in-game matrix. Record evidence and unknowns in
compatibility-matrix.md and notable changes in
CHANGELOG.md. Contribution and privacy requirements are in
CONTRIBUTING.md.

Build coverage (2026-10-01). The compatibility matrix is pinned to stable
1.29.0.163451. 28 skills also carry sections for DayZ 1.30 Experimental
(build 1.30.164014), each labelled as such, and dayz-motorbikes targets 1.30
only. 1.30 has not reached stable on this date; when it does, those sections are
re-checked against the stable build before their labels change. Where each 1.30
section lives: compatibility-matrix.md §DayZ 1.30 Experimental.

10. A worked first move (for the assistant)

User: "Help me make this ripped car drivable in DayZ."

1. rip-vehicle-import if it's a racing-game rip (import pipeline), else dayz-vehicles (authoring).
2. enforce-script-reference for any Enforce Script / config work.
3. dayz-feature-spec first if it's non-trivial — lock the Forward Contract (classnames,
   model.cfg selections, wheel names) before coding.
4. dayz-test-ingame to build/deploy/launch locally; verify in-game.
5. dayz-mcp-verify (or manual) to confirm spawn → get-in → drive → correct wheel sense.

Throughout: verify every class/field against vanilla (P:\scripts\), respect the client/server
split, and batch your in-game tests.

Happy modding.