git:20261001.7ab7879 to git:20261001.e42d2f4

---

name: dayz-test-ingame

description: "Use when: lanzar el juego con el mod, probar el mod in-game, filepatching, DayZDiag, arrancar server local, connect 127.0.0.1, the mod doesn't load. Not packaging-only: dayz-pbo-build; not env check: dayz-preflight."

---

# DayZ test in-game (filepatching launch)

## WHAT THIS DOES

Closes the dev loop for a DayZ mod on a single Windows box: re-pack the PBO, deploy it

where the engine reads mods, and launch `DayZDiag_x64.exe` with `-filePatching` so script

and config edits are picked up without re-binarizing. Three launch modes (offline / server /

client / all) driven by one orchestrator script and double-click `.bat` wrappers, generated

per mod into `<Mod>_dev\tools\`.

(until 1.29: the loop was pack PBO → deploy packed `@Mod` → DayZDiag `-filePatching`.) (since 1.30 Exp [CHANGELOG]: `-mod` may point at an **unpacked** source folder; RV configs load unpacked; new flags `-cacheP3D=0/1` and `-resolveFilePatchingUsingEnfusion=0/1`. Details: [dayz-1-30-test-ingame.md](references/dayz-1-30-test-ingame.md) and ## DayZ 1.30 Exp.)

## SOURCE OF TRUTH

`<dayz-projects>\DAYZ_INFRA.md` is the canonical record of

this user's DayZ paths, flags and gotchas, verified in-situ. This skill **operationalizes**

that doc — it does not re-derive the flags. If the two ever disagree, DAYZ_INFRA.md wins;

update the skill to match, never the reverse.

Cite-then-verify discipline:

- `[EXACT]` — flag/path verified against DAYZ_INFRA.md (section refs below; section names are

stable, line numbers drift as the doc grows) and the user's RPTs.

- `[DESIGN]` — plausible but NOT in the user's infra. The single-exe **offline mode is

`[DESIGN]`** — validate it in-game on first run before trusting it.

## WHEN TO USE / WHEN NOT

Use when the user wants to see a mod running in-game, iterate scripts/configs live, or stand

up a local server+client. Do NOT use to author the mod (that is `dayz-model-pipeline` /

`enforce-script-reference`), to validate/pack only (`dayz-pbo-build`), or to configure a

production server. The retail `DayZ_x64.exe` is for final pre-release validation only —

`<runbooks>\dayz-mcp-agent-session-protocol.md`.

|---|---|---|

7. [EXACT] After adopting, keep the run owned yourself: the lease lasts 120 s and is not renewed internally, fresh client or not, so send `session_heartbeat` at least every ~90 s during the whole run, including while a human plays. Without heartbeats the run goes ownerless and the daemon stops it after the grace period (measured 2026-09-27, three runs; detail in `dayz-mcp-verify` §COMPOSICIÓN).

- [EXACT] When the command that `cmd /c start` launches is a `.bat`, the new window runs `cmd /K`: an `exit /b` at the end of the bat exits the script, not the interpreter, and the window stays at an idle prompt after the server closes — one leftover console window per launch (measured 2026-09-25, LFDucati T99, Windows 11 23H2: 9 idle `cmd.exe /K` wrappers after two days of server starts; 0 after the switch). Wrap the bat in a second `cmd /c`: `cmd /c start "<title>" cmd /c "<abs bat>"`. A preflight failure with `pause` inside the bat is still visible.

- [DESIGN] Server argv: `-server "-config=<serverDZ.cfg>" "-profiles=<server-profiles>" "-mission=<mission-abs>" "-mod=<mod-abs-semicolon-list>" -filePatching -port=2302`

- [DESIGN] Client argv: `"-mod=<mod-abs-semicolon-list>" -connect=127.0.0.1 -port=2302 "-profiles=<client-profiles>" -name=Dev -window -filePatching`

(since 1.30 Exp [CHANGELOG]) Optional on both: `-cacheP3D=1` (unbinarized `.p3d` sibling cache) and `-resolveFilePatchingUsingEnfusion=1` (requires `-filePatching`; always on in Workbench). `-mod=` may name an unpacked source folder, not only a packed `@Mod`. See `references/dayz-1-30-test-ingame.md`.

## PREREQUISITES (preflight — runs automatically)

```

python <KNOWLEDGE_PACK>/tools/dayz-script-validator/scripts/script_validator.py <addon_root>

```

The orchestrator checks these every run and fixes what it safely can. Verified on this box

2026-05-30: missions present in DayZServer, AddonBuilder present, `P:\` mounted, but

`P:\Mods` junction NOT yet created and `DAYZ_*` env vars unset (fallbacks used).

- **Diag exe** — `DayZDiag_x64.exe`. Client AND server MUST be the diag binary; retail blocks

- **`P:\Mods` junction** -> `<DayZ>\!Workshop` so deployed PBOs land where the engine looks.

- **`allowFilePatching = 1`** in the server's `serverDZ.cfg`, else BattlEye kicks the client

with `0x00020005`. The script generates a dev `serverDZ.cfg` with it set. [EXACT — DAYZ_INFRA.md §serverDZ.cfg — allowFilePatching = 1; obligatorio]

- **Mission template** — absolute path; the server loads an empty mission otherwise.

- **`class Missions` in `serverDZ.cfg`** — a dedicated server with a `dayzOffline.*` mission self-terminates before the mission loads (RPT countdown `[Server] :: termination in: N`) unless the config declares `class Missions { class DayZ { template="<mission>"; }; };`. With it, the server stays up with no client, which is what a server-side probe in the mission `init.c` needs. [EXACT] (measured in game, DayZ 1.30.164014 Exp, SP-434]

- **Steam client session** — for CLIENT-launching modes only (`offline`, `client`, `all`),

`HKCU\Software\Valve\Steam\ActiveProcess` must have both `pid != 0` and

`ActiveUser != 0`. The script warns without aborting; run `steam.exe -shutdown`, then relaunch

Steam (the login is preserved). [DESIGN] Restart is NOT the reliable remedy: measured 2026-09-08/09, a restart can leave the key pointing at the old pid with the client still dead — the deterministic fix is to copy the live `steam.exe` pid into `ActiveProcess` from a shell OUTSIDE any sandboxed (MSIX) app — a write from inside one only reaches that app's private registry copy, see `references/dayz-1-30-test-ingame.md` — (guards and verification in the "El `pid` de Steam en el registro puede estar MUERTO" section below), and restart only as a fallback when there is no live Steam or `ActiveUser == 0`.

Path resolution is env-var-first, Steam-default fallback (`DAYZ_GAME_PATH`, `DAYZ_DIAG_PATH`,

## THE CYCLE

1. **Build + deploy** (`-Build`) — `AddonBuilder P:\<Mod> -> P:\Mods\@<Mod>\Addons\<Mod>.pbo`.

Required whenever **assets** (`.p3d`, `.paa`, `.rvmat`) change — filepatching does not

reliably hot-load binarized models/textures.

**Scripts-only mods**: AddonBuilder's default binarize mode drops `.c` files (not in its

include-list) → a config-only PBO where the mod mounts but no script runs. `Invoke-Build`

now auto-adds `-packonly` when the source has no `.p3d`/`.paa` (force with `-PackOnly`), and

warns if a mod with a `scripts\` folder packs suspiciously small. [verified 2026-06-03]

**`.asi`/`.anm` (added 2026-06-24, A6_SR2M)**: binarize mode ALSO drops these unless the

`-include` list has `*.asi;*.anm`. A weapon with a custom player anim graph

(`AddItemInHandsProfileIK` 2nd arg = its own `.asi`) then builds WITHOUT the graph → the

reference points at a missing file and the change (e.g. a fire-anim no-jump fix) is silently

absent (the build still reports success). The generated include list must contain

`*.asi;*.anm`. Verify the `.asi`/`.anm` shows up as a FILE ENTRY in the PBO header, not just

as a string inside the compiled script.

**Mixed mods (assets + scripts, SP-083, added 2026-07-22, LFPowerGrid)**: auto-`-packonly` does

NOT apply when `.p3d`/`.paa` are present — `Invoke-Build` and `dayz-test.ps1 -Build` never pass

`-include` (only -prefix/-temp/[-clear]/[-packonly]), so binarize still silently drops

`.c`/`.paa`/`.ogg`/`.rvmat`/`.layout`/`.csv` — the PBO mounts with zero scripts running.

The "packs suspiciously small" warning (<4096 B) misses it: binarized `.p3d` keep the PBO

large (measured 95.1 MB / 170 files; with include-list 451 files / 106.8 MB). Production:

AddonBuilder <src> <out> -prefix=<Mod> "-temp=<tmp>" "-include=<lst>" -clear with

lst = `*.c;*.asi;*.anm;*.paa;*.rvmat;*.layout;*.ogg;*.ptc;*.csv`. Mandatory post-build gate:

count PBO entries (PboViewer unpackFolder) or grep a known `.c` (170 vs 451 = drop).

Complements SP-065. Cross-ref `dayz-pbo-build`.

**Mixed mods, migration (SP-168, added 2026-08-04, GunRacks)**: the real failure mode

is MIGRATION. Measured on GunRacks: **22 entries / 401.857 B without the include-list,

25 entries / 411.786 B with it** — the gap is exactly the three `.c`. The project's

documented hand command already passed `-include=...\tools\include.lst`

(`PLAN.md:216`, `GunRacks_dev\HANDOFF.md:543`); that `include.lst` was created by

hand. GENERATING THE SCRIPTS FOR A MOD copies only `dayz-test.ps1` plus the three

`.bat` wrappers — it does not write `include.lst`. `Invoke-Build` still does not pass

`-include`, so switching from the hand command to `server.bat` / `dayz-test.ps1 -Build`

drops every script with no visible change (PBO still large; the <4096 B warning never

fires). In-game the mod mounts but no action appears — indistinguishable from an

unregistered ActionConstructor or a bad ActionCondition, so the wrong file gets

debugged. Caught by listing the freshly built PBO before spending a test cycle.

In `Invoke-Build`, pass the include-list when it exists and the build is not packonly:

$incLst = Join-Path $PSScriptRoot 'include.lst'

if (-not $usePackOnly -and (Test-Path $incLst)) { $abArgs += "-include=$incLst" }

Replace the size check (`scripts\` present and PBO < 4096 B) with a CONTENT check:

if the source has `scripts\`, list the PBO and require packed `.c` count == source

`.c` count. `GunRacks_dev\tools\pbo_list.py` is the lister. Cross-ref

`GunRacks_dev\tools\dayz-test.ps1` Invoke-Build (patched locally; the measurement

is in the comment). Complements SP-083.

2. **Launch** — diag exe in the chosen mode. **Script/config** edits (`.c`, `.cpp`) are then

picked up live by `-filePatching` without re-packing.

So: edit a model -> re-run with `-Build`. Edit a script -> just relaunch (or even keep the

client running, depending on what changed).

## RELEASE-GRADE BUILD BOUNDARY

[EXACT][CLAIM-R21-TEST-BUILD-POSTCONDITION] `exit_0_is_not_build_success`.

AddonBuilder can leave an old destination PBO in place after a later copy step

fails, so process exit and `Test-Path` alone do not prove that the requested

bytes were built or deployed. A release verdict requires evidence for a

`fresh_pbo`, the expected `header_prefix` and file entries, and a clean

`fatal_log` scan; require a valid `.bisign` too when signing is expected.

[DESIGN] The Phase 04 release workflow must stage the candidate outside the

published path, validate it, and publish only after every gate passes. On any

failure, require `previous_artifact_unchanged` and do not advance the build

manifest or cache. Its cache key must cover input bytes, build options, prefix,

DayZ build, tool versions/hashes and signing-key identity. Its preflight must

reject case/path conflicts, excluded-but-referenced files, absolute packaged

paths, stale or missing `.paa` dependencies, and unsupported ODOL inputs before

binarization.

The current generated dev launcher does not yet implement that complete

release contract. Use its PBO for iteration, but do not label the result

release-ready until the future `dayz-pbo-build` / `dayz-workshop-release`

pipeline supplies these postconditions.

## MODES

| Mode | What | Status |

|---|---|---|

| `offline` | single diag with `-mission`, no network | **[DESIGN]** validate in-game |

The diag exe compiled Enforce in STRICT mode; the retail chain compiled permissively.

Third-party packs were observed with syntax that retail tolerated as `FIX-ME` warnings but

diag rejected as fatal errors — verified live with the A6 weapons pack (braceless

one-liners: `override typename GetInputType() return X;` in OpticScripts/WeaponScripts,

"Missing function scope") and LBmaster_Core ("Unsafe down-casting"). This remained a

diagnostic fact, not an alternate launcher path. The agent's role is limited to reporting

the incompatibility; the user owns any decision to open retail manually outside this

orchestrator. While an external retail route is open, the agent remains in cuarentena

retail and read-only under the protocol.

Historical manual-route facts retained for diagnosis:

- **Retail server was `DayZServer_x64.exe` from the dedicated install.** In the observed

session, the retail game exe with `-server` booted the CE and then terminated while

loading GFX resources (`Water/*.edds`, "Termination successfully completed").

- **The dedicated binary already operated as a server.** Adding `-server` also triggered

LBmaster's startup check (`Error: Remove Startup Parameter: -server`).

- **The historical LBmaster setup loaded server-only addons through `-serverMod=`.** Its

`*_Server.pbo` files had been placed under `@SomeFolder\addons\*.pbo`, and their paths

had resolved absolutely in the same way as `-mod` paths.

- The launcher's bind-wait produced a false negative ("exited before binding") while the

server was still booting the CE. In that session, the first CE boot of the large pack

took minutes and the later UDP 2302 observation showed that startup had continued.

**BattlEye on the retail pair — kick 240 "Game restart required"** (session 2026-06-11):

- The retail server loaded its BE module (`profiles\BattlEye\BEServer_x64.dll`,

auto-downloaded on its first BE boot) and kicked clients that had not initialized BE,

including the bare `DayZ_x64.exe` client from that session. `BattlEye = 0;` in

serverDZ.cfg masked the behavior for several sessions, then stopped doing so after a

system-wide BE service hot-update under `%ProgramFiles(x86)%\Common Files\BattlEye`.

The recorded file times identified that update, after which kick 240 returned 20-60 s

after each connection regardless of the cfg flag.

- When `BEServer_x64.dll` was removed or renamed in the 1.29 dedicated installation, the

server bound UDP, printed `BattlEye initialization failed`, and shut down cleanly about

a minute later ("Termination successfully completed" in the RPT). The sequence looked

like a healthy boot followed by a silent death.

- In the historical external-manual setup, with server BE intact, `DayZ_BE.exe`

initialized the client handshake and avoided the kick. The in-game session on

2026-06-11 reached spawn, equip and inventory with zero kicks. This launcher did not

invoke that route; the user owned its UI lifecycle and the agent remained in

quarantine/read-only.

Historical load-order failures that cost a session:

- Removing `@CF` from BaseMods while `@VPPAdminTools` remained caused VPP's embedded CF

sources to fail with `Unknown type 'RPCManager'`.

- LBmaster operated only when the observed setup included client PBOs (`LBmaster_Core`

plus the matching client of every `*_Server.pbo`, such as `LBmaster_Groups` for

`AdvancedGroups_Server`), the server-side PBOs and a per-IP license whitelist. Its

error log contained the corresponding whitelist URL. In the historical local weapon

sessions, VPP served as the admin/spawner and LBmaster appeared only in parity runs.

- The historical `@A6_TestPack` subset had been staged with filesystem hardlinks from

`@LFTEST`; it represented 13 weapon PBOs without duplicate file copies.

## USAGE

Orchestrator (from `<Mod>_dev\tools\`):

```powershell

# build, deploy, run server+client on Chernarus

.\dayz-test.ps1 -Mod HiddenBase -Mode all -Build

# script-only change: relaunch client, no re-pack

.\dayz-test.ps1 -Mod HiddenBase -Mode client

# offline eyeball of a model [DESIGN]

.\dayz-test.ps1 -Mod HiddenBase -Mode offline -Build

# another map + an extra dependency on top of the defaults (CF/Dabs/VPP)

.\dayz-test.ps1 -Mod LFPowerGrid -Mode all -Build -Mission livonia -ExtraMods "@RaG_Liquid_Framework"

# preflight only / stop one exact managed run

.\dayz-test.ps1 -Mod HiddenBase -Preflight

.\dayz-test.ps1 -Mod HiddenBase -Kill -RunId <run_id>

```

Key params: `-Mod` (required), `-Mode`, `-Mission`, `-Build`/`-Clean`, `-ExtraMods`,

`-BaseMods`/`-NoBaseMods` (see below), `-Source` (default `P:\<Mod>`), `-RunId`,

`-NoFilePatching`, `-Port`, `-PlayerName`, `-ServerWait`. Double-click wrappers:

`server.bat` (all+build), `client.bat`, `offline.bat`.

## DEFAULT MODS & ADMIN TOOLS

Every launch prepends three base mods (load order, CF leftmost — folder names verified in this

user's `!Workshop`): `@CF;@Dabs Framework;@VPPAdminTools`. The mod under test and `-ExtraMods`

load after them. Override with `-BaseMods "..."`, or drop them entirely with `-NoBaseMods`.

`@VPPAdminTools` gives in-game admin tools (teleport, spawn, godmode, object editing) for

testing. Admin access is by **SteamID64**, not a server password — but the on-disk layout

differs across VPP versions, and the installed one uses the `Permissions\` folder, NOT the root

`SuperAdmins.json`. Because this script isolates `-profiles`, the preflight seeds **both** so

admin works regardless of version (idempotent; an already-hashed password is never clobbered):

- `<server profiles>\VPPAdminTools\Permissions\SuperAdmins\SuperAdmins.txt` — one SteamID64 per

line; the file the installed VPP actually reads. (verified in-situ 2026-06-09)

- `<server profiles>\VPPAdminTools\Permissions\credentials.txt` — the **in-game login

password** on line 1. VPP hashes it on first boot and the raw is then lost.

[EXACT][CLAIM-R21-TEST-VPP-SECRET] There is no packaged default. It is seeded

only when the operator explicitly supplies non-empty `-AdminPass`, and its

value is never printed.

- `<server profiles>\VPPAdminTools\SuperAdmins.json` — `{ "SUPER_ADMINS": ["<SteamID64>"] }`,

the legacy layout; still seeded for older VPP builds that read it.

SteamID source: `-AdminSteamId`, else reused from the retail config at

`%LOCALAPPDATA%\DayZ\VPPAdminTools\SuperAdmins.json`. In-game: open the VPP menu (key set under

Options → Controls; VPP's common default is Insert), then log in with the password. To change

admin or password later, edit the files above and restart the server.

**No-password dev default (verified vs VPP source 2026-06-09):** the generated `serverDZ.cfg`

sets `vppDisablePassword = 1;`, so VPP skips the login password entirely — a superadmin (SteamID

in `SuperAdmins.txt`) gets access with NO password (`missionServer.c:14` →

`DisablePasswordProtection(true)`; granted because `HasUserGroup`→`IsSuperAdmin`,

`PermissionManager.c:693`). This is the robust local-dev default: the `credentials.txt` password

path repeatedly failed across sessions (SHA256/version quirks), and disabling it removes that

whole failure class. An explicitly seeded `credentials.txt` password only matters if you remove

`vppDisablePassword` for password-gated testing. In-game keys: End = toggle admin, Home = open

menu (rebind under Options → Controls if a fresh client profile lost them).

Earlier this doc claimed VPP reads the root `SuperAdmins.json` — that was wrong for the installed

build (it reads `Permissions\`), which is why admin silently failed until 2026-06-09.

The dev `serverDZ.cfg` sets `verifySignatures = 0`, so VPP's signed PBO loads without registering

its `.bikey`.

## GENERATING THE SCRIPTS FOR A MOD

1. Create `<Mod>_dev\tools\` if absent (per the dev-split layout in workflow.md).

2. Copy `templates\dayz-test.ps1` there verbatim — it is fully generic (driven by `-Mod`).

3. Copy the three `.bat` wrappers and replace the `__MODNAME__` placeholder with the real mod

4. Confirm the mod **source** is reachable at `P:\<Mod>` (a junction to the editable folder)

or pass `-Source`. Confirm `requiredAddons` in `config.cpp` map to the `-ExtraMods` you

pass (CF, Expansion, etc.) — the client and server mod lists MUST match.

The `.ps1` is self-contained (no dependency on this skill at runtime) so it stays valid in the

mod repo even if the skill changes. `_server\` and `_client\` workspaces (serverDZ.cfg, RPT,

script.log) are created next to `tools\` under `<Mod>_dev\`.

## FILEPATCHING SCOPE — read before promising hot-reload

`-filePatching` hot-loads **scripts and configs** from raw source in the general case, not

binarized assets. Model/texture/material changes need a `-Build`. Do not tell the user "just

edit and it reloads" for a `.p3d` or `.paa` change — that is the most common false expectation

here. **On this install even scripts do NOT hot-load — the PBO wins** (measured 2026-07-20);

see the SP-078 section at the end of this file and use the `srcprobe` discriminator before

attributing anything to filepatching.

## MOD PATHS MUST BE ABSOLUTE — silent no-mount otherwise (verified 2026-06-01)

A bare `-mod=@Name` is resolved by the engine **relative to its working directory** (the game

dir), i.e. `<DayZ>\@Name`. Deployed mods live under `<DayZ>\!Workshop\@Name`, so that relative

path does not exist and the engine **silently fails to mount the addon** — its `CfgPatches` /

`CfgVehicles` classes never register, and `CreateObjectEx` later returns **null with no RPT

error**. This is a brutal failure mode: the server boots, the mission runs, nothing logs wrong,

but your mod's classes simply aren't there.

Verified via an in-mission `ConfigIsExisting("CfgPatches LFQuad")` probe on a headless `-server`:

- `-mod=@LFQuad` (relative, cwd=game) → `CfgPatches.LFQuad = 0` (absent).

- `-mod=C:\...\DayZ\!Workshop\@LFQuad` (absolute) → `CfgPatches.LFQuad = 1`, `LFQuad_base = 1`.

`Get-ModString` now rewrites every bare `@Name` to its absolute `!Workshop` path via

`Resolve-ModToken` (handles names with spaces like `@Dabs Framework`; passes through tokens that

are already rooted or not found under `!Workshop`). This applies to server, client and offline.

Caveats (honest scope — not yet verified):

- The probe only confirmed the **mod-under-test** mount. Whether base mods mount under relative

names in the `all` mode (client present) was NOT isolated — the fix makes it moot by resolving

all of them to absolute.

- Checking a dependency's mount needs its **real CfgPatches name**, not the folder name:

`@CF` → `JM_CF_Scripts` (verified by extracting `@CF\addons\scripts.pbo`). A probe using `"CF"`

yields a false negative.

### Headless autotest pattern (no client, scripted spawn)

For automated physics/spawn testing without a human client, a dedicated harness lives at

`LFQuad_dev\tools\dayz-autotest.ps1` (reuses this launcher's build+deploy). Five gotchas that

cost many iterations, recorded so the next headless harness works first try:

1. **Historical detached pattern — superseded 2026-07-15.** A direct `Start-Process` avoided

waiting on the DayZDiag grandchild but left it outside the registered lifecycle. Launch now

exclusively through the managed Diag launcher after acquiring the lease; retain its `run_id`

and poll the RPT read-only. Do not recreate the old direct invocation.

2. **A test mission `init.c` should skip `CreateHive()`** (CE economy) for a physics test — it

loads ~20k loot items and delays the mission loop by minutes.

3. **A `CarScript` vehicle only ticks `OnUpdate` / simulates with a player present.** A headless

server with zero clients won't drive the vehicle's own script; spawn after a client connects

(the harness has a `-WithClient` mode that connects a second diag instance to 127.0.0.1).

4. **Cell infrastructure (spawn-on-connect, engine watcher, auto-test hooks) belongs INSIDE the

mod under `#ifdef DIAG` + a CLI param — never only in the mission `init.c`** (added 2026-08-17,

LFHeli). The mission lives under Steam (`DayZServer\mpmissions\<mission>\init.c`), which no

portable pack, backup or repo carries: the LFHeli cell infra written into `init.c` on

2026-08-12 (`CreateObjectEx` on `InvokeOnConnect` + `EngineStart()` pre-crew watcher) was

gone on the other machine five days later and had to be recovered from a transcript. In-tree

it travels with the PBO, is versioned, and stays inert in retail by absence of the flag

(pattern: `LFHeliCore\scripts\5_Mission\LFHeliFLIRMission.c` `modded class MissionServer`,

`-lfheliAutoGetIn=1` in `LFHeliPlayerBase.c`). Corollary measured the same day: start the

engine BEFORE the crew sits — a sleeping PARKED body rejects the injected get-in action.

5. **PowerShell orchestrator traps that hang a cell silently** (measured 2026-08-17, LFHeli

`run_celda_scripted.ps1`): (a) never name a function parameter `$Args` — it is the automatic

variable, `@Args` splats EMPTY and `& python` with no argv opens the interactive REPL that

never returns (the cell sat at "flip DebugLog" for minutes with a `python.exe` child and no

arguments); (b) `& native 2>&1` under `$ErrorActionPreference='Stop'` turns any stderr line into

a terminating error (PS 5.1) — wrap native calls in a helper that switches to `Continue` and

returns text + `$LASTEXITCODE`; (c) the DayZ CLIENT needs a usable Steam

(`HKCU\Software\Valve\Steam\ActiveProcess` pid AND ActiveUser ≠ 0): a Steam restarted minutes

earlier sits at pid populated / ActiveUser=0 and the client dies at bootstrap with a ~1 KB RPT

and an `ErrorMessage_*.mdmp` while the SERVER (no Steam) boots fine — `steam.exe -shutdown` +

relaunch repopulated the key in ~20 s. Check the key in the pre-flight of every cell.

## WHEEL SIMULATION DIAGNOSIS (vehicle won't drive / bounces / sinks)

When a modded `CarScript` vehicle spawns but won't drive - wheels mount yet don't

spin, chassis bounces or sinks, engine revs with no speed - the failure is almost

always one of two MEASURABLE things, not mass/inertia. Instrument and read them

side-by-side against a known-good reference vehicle (e.g. the vanilla sedan or the

Croco quadbike) IN THE SAME RUN before touching geometry.

### 1. Is the wheel seated in PhysX, and does it touch ground?

- `WheelCountPresent()` - how many wheels the simulation actually seated (the gate).

`0` while `WheelCount()` returns N means the slot/FireGeometry wiring is wrong; see

the `enforce-script-reference` wheel-attachment rule and audit check SP-017.

- `WheelHasContact(i)` per wheel - `1` = touching ground, `0` = airborne. Print the

four as a bitstring (`wc=1111` good; `wc=0000` = the whole vehicle is suspended off

the ground, a placement/clearance problem, not a sim problem). Vanilla refs:

`car.c:297,349,352`.

So: `WheelCountPresent()=0` is the silent wheel-binding blocker (FireGeometry slot

selection); `WheelCountPresent()=4` with `wc=0000` is geometry sitting too high or

buried, which step 2 isolates.

### 2. Did placement bury or launch the vehicle? (controlled-height probe)

Spawn with an explicit height flag instead of letting CE drop it:

- `ECE_KEEPHEIGHT` (`=524288`, "no surface trace") - places at the exact Y you pass,

no terrain snap. Spawn a known clear height and watch whether it settles.

- `ECE_PLACE_ON_SURFACE` (`=1060`) - normal surface-trace placement.

Vanilla refs: `centraleconomy.c:37,27`. If the vehicle is stable under KEEPHEIGHT but

bounces/sinks under PLACE_ON_SURFACE, the bug is placement burying the hull (wheel-well

clearance vs tire radius - audit check SP-023), not the model.

### 3. Gotcha: parser/instrumentation drift before declaring the test failed

When the harness reports "ERROR / no data", first confirm the parser regex still

matches the CURRENT log-line format of the instrumentation. A log-format change

(renamed tag, reordered fields) reads as a test failure when the test actually ran

fine. Check the regex against a raw sample line before concluding the build is broken.

(origin: SP-023; LFQuad wheel-well/placement 2026-06-01; handoff 30_Sessions/2026-06-01-LFQuad-wheelwell-bake-placement.md)

## TROUBLESHOOTING

| Symptom | Cause | Fix |

|---|---|---|

| VPP asks for a password despite a `SuperAdmins.txt` superadmin | `serverDZ.cfg` predates the `vppDisablePassword = 1;` default (generated before 2026-06-09); the existing-cfg path only re-checked `allowFilePatching` | launch now self-heals (appends `vppDisablePassword = 1;` if absent) + restart; or add it manually [session 2026-06-15] |

| Server boots then dies before UDP bind; RPT/log shows `!!! Serious stream damage detected during load` | half-written CE storage after an unclean server kill — masquerades as a mod bug | wipe (or rename) `<mission>\storage_1` before the next test; the server regenerates a fresh one. SOP: after ANY unclean server kill, wipe it preemptively |

| Mod class missing / `CreateObjectEx` returns null, no RPT error | relative `-mod=@Name` didn't mount | use absolute `!Workshop` paths — `Get-ModString` now does this (see "MOD PATHS MUST BE ABSOLUTE") |

| Mod mounts (CfgPatches in `defines:`) but no script/hook runs | AddonBuilder binarize dropped the `.c` → config-only PBO | build scripts mods with `-packonly` (Invoke-Build auto-detects when no `.p3d`/`.paa`); grep the deployed PBO for a known classname to confirm. [verified 2026-06-03] |

| Script edit doesn't take effect — the same compile error persists across rebuilds even though the source is fixed on disk | AddonBuilder's incremental sync to `P:\temp\<Mod>` served stale source (a changed `.c` not re-copied); filePatching also did not override the PBO's scripts with the loose work-drive copies | Invoke-Build now wipes `P:\temp\<Mod>` before every build; building AddonBuilder by hand, pass `-clear` or delete the temp first. Canonical tell: a compile error citing a line you already fixed and verified. [verified 2026-06-18] |

| Retail server binds, then dies ~1 min later; `BattlEye initialization failed`, RPT ends "Termination successfully completed" | `BEServer_x64.dll` missing/renamed | Historical observation: the 1.29 dedicated server shut down when BE initialization lacked that DLL. The external owner/user decides and performs any restoration outside the agent workflow; the agent remains in quarantine/read-only [session 2026-06-11] |

Logs (where to look): `script.log` = script compile/runtime errors; `*.RPT` = engine errors

(missing assets, malformed configs); `crash_*.log` = handled exceptions, not hard segfaults.

folders. For a structured script-failure diagnosis, hand off to `dayz-mod-workflow`.

## OUT OF SCOPE

Authoring the mod, production server config, Central Economy / persistence tuning beyond the

minimal dev `serverDZ.cfg`, signing for Workshop release. PBO validation/packaging internals

are planned for `dayz-pbo-build` / `dayz-workshop-release` in r21 Phase 04 — this skill calls

AddonBuilder and records their required handoff contract; it does not re-implement the checks.

## REFERENCES

- `DayZ Projects\DAYZ_INFRA.md` — canonical paths/flags/gotchas (the source this skill serves).

- `dayz-pbo-build` — pre-build validation + packaging.

- `dayz-mod-workflow` — debug protocol when a launch surfaces script/engine errors.

- `templates\dayz-test.ps1`, `server.bat`, `client.bat`, `offline.bat` — the generated tooling.

## Session findings (dated appendices -> references/session-findings.md)

Per-session in-game gotchas moved to `references/session-findings.md`; load it when a launch hits one of these. One line each:

- **LFSlidingFloor (2026-06-11)** — `Print()`->script.log not RPT; `-filePatching` can compile WITHOUT the mod's scripts silently; VPP needs `@CF` first; 1 Steam acct = 1 client (kick 179); deployed PBO locked while server runs.

- **A6_SR2M grip (2026-06-17)** — visual capture on retail (brightness band, specular glint, exposure drift, multi-config desync, RPT error filter) + `Start-Process EPERM uv_spawn` in a backtick `foreach`.

- **MercedesAMGLF Fase 0 (2026-06-22)** — cheap mount-probe gate (CfgPatches existence) before physics autotest; retargeting the LFQuad physics harness (server-only no-spawn, phantom debug token, control-vehicle verdict, case-insensitive `-replace`).

- **Retargeting the harness to a new mod (2026-06-23)** — `dayz-test.ps1` is car-parametric (copy verbatim); only per-mod helpers need a case-sensitive token swap; retarget host-direct.

- **The box is a coordinated resource (2026-06-24, superseded 2026-07-15)** — one DayZ instance per box (UDP 2302); FIFO lease serializes mutations and `run_id` exacto identifica lifecycle; nombres de mod/perfil no conceden ownership.

- **`@<Mod>_deps` separate dep addon (2026-06-26)** — put deps in `-BaseMods` (loads first) or the client fails `Unknown type` at compile; replicate the last successful `-mod=` from the RPT.

- **Third-party "sloppy" scripts (2026-06-28)** — deps that only warn on retail but fatal-compile on diag require a user-owned external manual parity run; agent stays in quarantine.

- **Launching DayZDiag from the agent (2026-06-28, superseded 2026-07-15)** — background tool-jobs can lose their child; use the Diag-only managed launcher and its exact run instead of an unmanaged process.

## Backups (.bak_*) in scripts/ inflate the PBO and break grep-verify (SP-065, added 2026-07-14)

`Invoke-Build -packonly` copies the mod tree AS-IS, so any `<file>.c.bak_*` left next to the `.c` (the OneDrive rule: back up before editing) gets packed into the PBO. It does not break the game (Enforce compiles only `*.c`, ignores `.bak_*`), but it (a) inflates the PBO and (b) breaks PBO verification by grep-of-the-blob - an old anchor reads as PRESENT because it lives in a `.bak`, not the active `.c`. Measured (LFHeli 2026-07-14): 827,593 bytes with 29 `.bak` inside vs 115,609 bytes after moving them out (7x bloat + stale code shipped).

Rule: in `Invoke-Build`, before packing, move/exclude `*.bak*` from `$src` (or warn if `Get-ChildItem $src -Recurse -Include *.bak*` is non-empty). When verifying a PBO by text, COUNT occurrences (`Cnt`) instead of `Contains` - a `.bak` copy makes `Contains` lie. Cross-project convention: never leave `.bak_` in the mod's `scripts/`; put them in `<Mod>_dev\_backups\`. Cross-ref `dayz-pbo-build` (packaging). Origin: LFHeli feel-pass 2026-07-14 (cycle-16).

## Clean storage before any measurement boot - persisted entities re-fire EEInit (SP-062, added 2026-07-14)

Vehicles (and other persistent entities) saved in the mission's `storage_1` RE-RUN their `EEInit` on the next boot. Any logic ARMED there - a test `CallLater`, a JSON-driven spike/tuning mode, a countdown - re-fires on every persisted instance at once. Real case (LFHeli 2026-07-11): two helis from the day before re-armed their W0 spike at boot and flew off on their own after 60 s (two phantom CSV pairs contaminating the corpus, violating one-run-active-at-a-time; the user even saw them fly with no explanation).

Rule: before a boot meant for MEASUREMENT (cells, spikes, telemetry), the mission storage must be clean ALWAYS - rename `storage_1` -> `storage_1.bak_<date>_<reason>` (reversible), not only after a dirty kill. The current SOP only covers the dirty kill / stream-damage case (see `## TROUBLESHOOTING`). The rename also purges test entities accumulated from earlier sessions. Cross-ref `dayz-mcp-verify` (one-run-active protocol). Origin: LFHeli feel cells 2026-07-11 (storage renamed storage_1.bak_20260711_feelcells).

## DEVELOPER vs DIAG_DEVELOPER - the standard diag only defines DIAG_DEVELOPER (SP-033, added 2026-07-14)

The standard `DayZDiag_x64` defines `DIAG_DEVELOPER` but NOT `DEVELOPER` (bare). Verified in `script_*.log` of both peers: server/client defines include `DIAG,DIAG_DEVELOPER,...,FEATURE_NETWORK_RECONCILIATION` - no `DEVELOPER`. So every vanilla `#ifdef DEVELOPER` block (e.g. the debug get-in: `DayZPlayerSyncJunctures.SendGetInVehicle`, `SJ_DEBUG_GET_IN_VEHICLE`, `PlayerBase.TryGetInVehicleDebug`, much of `plugindeveloper.c`) does NOT exist in this build. `OnDebugSpawn` working (it is `#ifdef DIAG_DEVELOPER`) does NOT prove `DEVELOPER` is active - different macros.

Expensive trap: if a mod PBO EMITS a `#ifdef DEVELOPER` symbol (a call to `SendGetInVehicle`, etc.), the symbol does not exist -> HARD compile failure of the WHOLE PBO -> every tool/script of the mod drops. Not a silent no-op (unlike `ExecuteEnforceScript`, Developer-only, which returns false at runtime).

Rule before basing a design on a vanilla `#ifdef DEVELOPER` API: (1) grep the `#ifdef` guarding it (`DEVELOPER` or `DIAG_DEVELOPER`?); (2) if `DEVELOPER`, read the `defines:` line of a recent `script_*.log` for that build to confirm it is active; (3) if not, do NOT emit the symbol - wrapping it in `#ifdef DEVELOPER` is not "robustness" if the design DEPENDS on it; find a non-DEVELOPER path. Cross-ref `dayz-mod-workflow` (anti-confabulation). Origin: DayZ_MCP Fase 5 Tramo A (2026-06-28), compile logs of both profiles.

## Secure-launcher allow-list: the base_mods format is decided by junctions, not style (SP-089, added 2026-07-25)

On this box DayZDiag only launches through the registered native launcher (SP-085), so a mod that is not in the sealed allow-list of `dayz-test-v1` cannot be launched under a project entry of its own. It can still be TESTED without touching the launcher, by riding an approved project - see "Testing a mod that is not in the allow-list" below; reach for the rebuild only when the mod needs its own sealed entry. Adding the Nth mod is mechanical - copy a live project block in `DayZ_MCP_dev\tools\build_native_launcher.py` (`_build_request_policy()` AND `_build_worker_runtime()`, same order) - but the `default_base_mods` FORMAT is a correctness trap, not a style choice.

`request_path_authority._open_descendant` rejects any path component that is a reparse point (`item.reparse_tag != 0 -> _invalid()`). Therefore:

- A dep whose folder under `P:\Mods` is a JUNCTION (`@CF`, `@Dabs Framework`, `@VPPAdminTools` -> Steam workshop) MUST be listed as its ABSOLUTE workshop path, and that path must also be sealed in `mod_roots`.

- A dep that is a REAL directory under `P:\Mods` (a locally built mod, e.g. `@LFHeliCore`) can be a bare relative name: `dayz_test_worker._mod_path` joins it to `mods_root` and it accredits under the sealed `P:\Mods` root (exactly 1 match required).

Why it costs a session: the wrong format passes EVERY unit test (they only pin strings) and fails at accreditation time, when the server is launched. Check `Get-Item <path> | Select-Object LinkType` for each dep BEFORE choosing the format.

Two more gates in the same flow, both of which have already burned a session:

- `tests\test_secure_launcher.py` HARDCODES the launcher PE sha256. Every rebuild changes it (adding a mod changes the PE), so update it after `build_native_launcher.py --offline --verify-reproducible` or the suite stays red for a reason unrelated to the change.

- `launcher_registry_update install-dayz-test-v1 --expected-sha256 <X>` is a compare-and-swap on the BYTES of `approved-launchers.json` (NOT the PE hash), and it REFUSES to install while a `dayz-test-v1` entry exists -> run `rollback-last` first; it prints the restored registry sha, which is the CAS token the install needs.

Origin: LFHeli OH-1 (2026-07-25), authorizing the 6th mod, after the 2026-07-22 session was lost to this same flow.

### Testing a mod that is not in the allow-list, without rebuilding the launcher

Authorizing a project is the expensive path: edit `build_native_launcher.py`, rebuild

the PE, update the hardcoded sha256 in the test, roll back and re-install the registry

entry. Sessions have gone into it. It is only needed when the mod must have its OWN

sealed project entry.

To just run the mod in-game, mount it as an `extra_mods` entry on a project that is

already approved. `_mods` appends every `extra_mods` value to the launch list

(`dayz_test_worker.py:204-210`), and `_mod_path` joins a NON-absolute value to the

sealed `mods_root` (`:199-201`), so a bare `@Name` accredits under `P:\Mods`.

The name must be a plain relative one. `_valid_mod_entry`

(`dayz_test_request.py:137-148`) rejects anything containing `:`, `\` or `/`, rejects

`.` and `..`, and requires `ntpath.normpath(value) == value`. An absolute path is

accepted instead, but then it must fall inside a sealed root.

Two constraints that decide whether the run works:

- **The deployed directory must be REAL, not a reparse point.** Same rule as the

`default_base_mods` format above: `_open_descendant` rejects any component whose

`reparse_tag != 0`. A junction has to be listed by its absolute workshop path and

sealed in `mod_roots`.

- **Pick a carrier project that compiles.** Script compilation aborts on the first mod

that fails, so a broken carrier's error only surfaces once yours already compiles -

which reads as "my mod broke it". `LFPowerGrid` is verified as a carrier

(`Module: Mission; loaded 231x files`). `@DayZ_MCP` is not usable as one: its

`5_Mission` fails with `CParser: quoted string not closed` attributed to

`mcpclientbridge.c`.

Origin: SP-128 (2026-07-28), measured against the launcher source; supersedes the

"cannot be tested at all" reading of SP-089.

Cross-ref SP-085 (diag hangs, 0 CPU / 0 RPT, when launched outside the registered launcher).

launches.

## Script changes NEVER hot-load from the work drive on this install - the PBO wins; rebuild the PBO for every script iteration (SP-078, added 2026-07-20)

Measured 2026-07-20 (LFHeli toggle diagnosis): with `-filePatching` on server AND client, `allowFilePatching=1`, work drive mounted and `P:\<prefix>\scripts\...` present, the engine still compiled the scripts FROM THE PBO. Probe prints existing only in the source tree never appeared over two boots; after `dayz-test.ps1 -Build` (packonly repack) the same prints appeared immediately. Consequences:

1. "Iterate scripts without repacking" does NOT work here. Every Enforce change needs a PBO rebuild (packonly, seconds) + relaunch. Treat the PBO as the only script source of truth.

2. Loose-file MODEL/texture shadowing is equally unproven on this install - do not attribute stale visuals to (or expect fresh visuals from) work-drive loose files; verify what the engine runs, do not assume filepatching semantics.

3. **The srcprobe discriminator** (cheap, definitive, one boot): change a LOG STRING in an already-printing line in the SOURCE only (e.g. `[TAG]` -> `[TAG srcprobe]`), relaunch WITHOUT rebuilding, grep the script log: token present = source served; absent (old string still printing) = PBO served. Use it before wasting cycles on "why doesn't my script change do anything".

Origin: 3 boots lost to probes that were "deployed" but never in the runtime; the PBO-wins fact then explained an earlier red herring the same day (a stale `P:\LFHeli\models` tree suspected of shadowing the deployed model - it never did).

## Secure-launcher runtime traps: daemon argv, staging dir, opaque errors (SP-092, added 2026-07-26)

Three infra traps cost most of a session on 2026-07-26. All three are cheap preflights.

**1. The daemon argv is derived from the client registrations - and the handoff documented it wrong.**

`host_config.resolve_daemon_provenance()` reads BOTH `~/.claude.json` (`mcpServers.dayz-mcp`) and

`~/.codex/config.toml` (`[mcp_servers.dayz-mcp]`), requires them to agree, and builds ONE canonical

daemon argv. Hand-starting the daemon with anything else is rejected with `daemon_identity_unverified`

- by design, so nothing can squat the port and impersonate the daemon. The session handoff said

`--idle-timeout 1800.0`; the registrations say `600`, so the canonical argv ends in `--idle-timeout 600.0`.

That single wrong number made every retry impossible.

Never guess the argv - ask the system:

`python -c "import sys; sys.path.insert(0,r'<tools>'); from dayz_mcp import host_config; print(host_config.resolve_daemon_provenance().argv)"`

**2. The CLI hides its own error code.** `secure_launcher` prints only

`secure launcher failed: ControlClientError` and swallows the code. Getting `daemon_identity_unverified`

required a wrapper script that caught the exception and read `.code`. If a launch fails, capture the

code first - do not retry blind.

**3. `oh1-build-deploy.ps1` fills the staging dir but never creates it.** `$Stage` under

`%LOCALAPPDATA%\Temp\LFHeli_OH1_stage` holds `$PBOPREFIX$`, so when Windows cleans `%TEMP%` the build

dies with `staging dir missing`. Rebuild it by copying the pack source (models/, proxies/,

`$PBOPREFIX$`, config.cpp) into it; the script overwrites the p3ds with the fresh ODOLs afterwards.

Also: the daemon self-terminates on its idle timeout (600 s), so a launch flow that worked hours

earlier will fail later with no change to the mod. Check port 8765 before blaming the build.

## Secure-launcher request grammar, the Steam prerequisite, and orphaned runs (SP-095, added 2026-07-27)

Four traps in one launch session on LFHeli OH-1. Each is cheap once known and expensive when not.

**1. The CLIENT needs Steam running. The SERVER does not.** A client launched with Steam down exits

immediately, writes a 793-byte RPT with only the header and an `ErrorMessage_*.mdmp` next to it, and

logs NOTHING useful. The real message is only inside the minidump: extract strings and look for

`Unable to locate a running instance of Steam`. There is no Windows "Application Error" event

because the engine handles it itself. Check `Get-Process steam` BEFORE launching a client, and start

it with `steam.exe -silent` if missing.

**1-bis. If that message appears while Steam IS running, stop reading the message and run the

discriminator.** Measured 2026-09-08 on SUB_BRZ: the client died on 5 consecutive launches with

exactly the string above, plus `[API loaded no]` in the same dump, while `Get-Process steam`

returned a live process, `HKCU\Software\Valve\Steam\ActiveProcess` held a non-zero `ActiveUser`

whose `pid` matched it, and steam.exe, DayZDiag_x64 and the daemon all ran as the same unelevated

user. Restarting Steam (`steam.exe -shutdown`, then relaunch) changed nothing, twice. Point 1's

advice ends at "check Steam is running"; when it IS, the reader has nowhere to go.

**The asymmetry is the clue: the server lives and the client dies.** Point 1 already says why - only

the client needs the Steam API - so the split names the suspect on its own, and the experiment that

separates the two causes is to launch the dead half YOURSELF, from your own user shell, with the

same command line (lift it from the RPT header or the dump). Two minutes, and it answers completely:

- **the hand-launched client dies too** -> the host or Steam really is broken, and that fix belongs

to the user.

- **the hand-launched client lives** -> the DAEMON'S SPAWN CONTEXT is what breaks it, not the host.

Different owner, different fix, and no amount of restarting Steam will touch it.

On that date it lived: it booted, connected, and reached the in-game HUD. `capture_screenshot` works

on it, because capture is host-side rather than a bridge verb. Filed as `fb-20260908-190943-5073`.

**Caveat that bounds the workaround**: a client you launched yourself is FOREIGN to the run record,

so the instance fence rejects its polls (`unaccredited_polls_by_class.instance_unknown` climbs) and

no client verb reaches it. Without `camera_set` there is no framing. It is good for putting a HUMAN

in front of the screen, not for automating a reading.

**The general rule, worth more than this case**: when one half of a client/server pair dies and the

other lives, their differing requirements already shortlist the cause. Run the by-hand launch of the

dead half BEFORE believing whatever subsystem the error message happens to name. Here the message

named Steam, and Steam was the one thing that could not help.

**And when it IS the daemon, re-measure before treating the wall as permanent.** Confirmed on

SUB_BRZ 2026-09-10, the day after: the same launch succeeded on the first try -- `client_alive=true`

at 17 s, player in game at 51 s, no Steam intervention, and `auto_remediate_steam` not even

requested. The only thing that had changed was `session_status.daemon_generation`. The wall was

daemon STATE, not the host, and a daemon restart cleared it. So record `daemon_generation` when you

file the finding, compare it when you retry, and give a freshly restarted daemon one clean launch

before spending a session on the workaround.

**2. The request JSON must not carry a UTF-8 BOM.** `Out-File -Encoding utf8` in Windows PowerShell

5.1 writes a BOM and the parser rejects the whole request with `invalid_dayz_test_request`. Write it

with `[IO.File]::WriteAllText($path, $json, (New-Object Text.UTF8Encoding($false)))`, or copy a

known-good request file and string-replace the fields.

**3. The request grammar has two coupled rules** (`dayz_test_request.py:336-344`), and violating

either returns the same opaque `invalid_dayz_test_request`:

- `kill: true` REQUIRES a `run_id`.

- With a `run_id`, `mode` may NOT be `server` or `all`; and `mode: "client"` REQUIRES a `run_id`.

So the valid shapes are: `server`/`all` without run_id (starts a run), `client` with run_id (joins

one), and kill as `mode: "client"` + `kill: true` + run_id (stops the run, not just the client).

`mode: "all"` in one request launches server AND client and avoids the run_id dance entirely - prefer

it when starting fresh.

**4. `run_not_adoptable` means the run is gone but its processes may not be.** The kill path tries

`adopt` then `stop` (`dayz_test_worker.py:496-507`); when both fail the lifecycle has lost the run

while a DayZ process may still hold port 2302, so every new run fails with `worker_failed` and the

audit trail shows `session_rejected reason=process_identity_mismatch`. Read

`%LOCALAPPDATA%\DayZ_MCP\audit\events.jsonl` (tail) - it names the real reason, which the CLI hides.

Recovery is a documented DEGRADED CLOSURE: close that specific process after verifying by

`CommandLine` that it is yours, then start a fresh run. This is the sanctioned exception to "never

kill DayZ processes directly": it applies only to a process you launched, under a run the guard has

already disowned, that is blocking the port.

**Also**: `lifecycle_cli.py` cannot be invoked standalone - it answers `missing_lifecycle_environment`

because the launcher chain sets its environment. Drive lifecycle operations through

`secure_launcher.run_secure_launcher` with a request on stdin.

**Method note that cost real time here**: `host_config.resolve_daemon_provenance()` raises

`daemon_provenance_conflict` if you call it with the SYSTEM python instead of the `.venv-mcp`

interpreter that both registrations declare - it compares `command` against the local launch

executable (`host_config.py:218-222`). That is a false alarm produced by the caller, not a

divergence between the Claude and Codex registrations. Always invoke with

`DayZ_MCP_dev\tools\.venv-mcp\Scripts\python.exe`.

Cross-ref SP-089 (allow-list format), SP-092 (daemon argv, staging dir, opaque errors), SP-085

(diag hangs outside the registered launcher).

|---|---|---|

```powershell

AddonBuilder.exe P:\<Mod> <staging> -prefix=<Mod> -temp=P:\temp\<Mod> -clear -packonly

Copy-Item <staging>\<Mod>.pbo P:\Mods\@<Mod>\Addons\<Mod>.pbo -Force

(Get-FileHash 'P:\Mods\@<Mod>\Addons\<Mod>.pbo' -Algorithm SHA256).Hash

```

```

SCRIPT (E): Virtual Machine Exception

Reason: Failed to read modstorage for entity Type=Rangefinder, Position=<...>

Class: 'CF_ModStorageObject<ItemBase>'

JM/CF/.../modstorage\cf_modstorageobject.c:142 Function OnStoreLoad_CF

.../mpmissions/dayzOffline.chernarusplus/init.c:6 Function main

```

`ActionManagerClient.PerformActionStart(GetAction(ActionGetInTransport), target, null)`

---

## Preflight: prove your celda's gates can go RED before you trust a single green run (added 2026-08-13, LFHeli council; LL-249)

A test-cell wrapper is only worth what its gates are worth, and two failure modes make a gate

**structurally incapable of failing** while it keeps printing green. Neither is visible by reading

the script in good faith. Both were live in a wrapper that had already gated ~12 in-game cells.

**1. A flag that turns your regex into a literal.** This line looks like a compile gate:

```powershell

Select-String -Path $slog.FullName -Pattern "Compile error|Can't compile" -SimpleMatch

```

`-SimpleMatch` makes PowerShell search for the whole string **verbatim, pipe included** — a

sequence that never occurs in a log. Measured against a synthetic log containing both real errors:

**0 hits with `-SimpleMatch`, 2 without it.** Every cell that "passed the compile gate" passed it

by construction. Same trap: `-Raw`, `-Literal*`, `[Regex]::Escape` on a pattern you meant as regex,

and `-match` vs `-like` mixups.

`File "$mission:storage_1/communityframework/modstorageplayers.bin" was not closed. Always shut

**2. An analyzer whose input does not depend on the experiment.** Hardcoded log paths

(`$clientPath = ...client_script_2026-08-12_11-25-05.log`) mean every future A/B re-analyses the

same old flight and reports "no change" tautologically. Its sibling: a script that only prints

statistics and never sets an exit code — without one, nothing can fail, so it is a report, not a gate.

**Preflight before trusting any inherited gate** (cheap, and it is the only thing that separates a

gate from decoration):

1. Feed it a fixture that MUST fail, and confirm it fails. If you have never seen the gate red, you

do not know it is a gate.

2. Grep the wrapper for `-SimpleMatch`/`-Raw`/`-Literal*` next to any pattern containing `|`, `.`,

`*`, `\` or `(`.

3. Require parametrised inputs, and assert the analysed artifact is **newer than** the run that

produced it (a stale-input check is one line and catches the whole class).

4. Require a non-zero exit code on failure, and check the caller actually propagates it.

Corollary for measurement campaigns: fix the gates BEFORE the campaign, not after. A campaign run

through a decorative gate produces greens that mean nothing, and you cannot tell afterwards which

of them were real.

## Teardown copies the logs BEFORE killing the client, and verifies the copy (SP-237, added 2026-08-13)

Killing the DayZ client immediately loses its last unflushed log buffer. A pilot

run's flight output was lost this way: the **client** log cut at `t=2118` while

the **server** recorded the dismount roughly 56 s later, so the interesting

window existed only in the buffer that the kill discarded.

The order is not "stop, then collect". It is:

1. **Copy** the script logs while the process is still alive;

2. **Verify the copy contains the stretch that matters** -- count the lines of the

probe you expected to see, do not just check the file is non-empty;

3. **Only then** `Stop-Process`.

A teardown that kills first cannot be repaired afterwards: there is no second

copy of an unflushed buffer. This costs one line-count assertion and buys the

whole run.

$m = "<mision>"

Rename-Item -LiteralPath "$m\storage_1" -NewName "storage_1_corrupt-modstorage-$(Get-Date -f yyyyMMdd)_<proyecto>"

(`P:\Mods`, `P:\<Mod>`, `P:\<Mod>_dev\_server\profiles`, `P:\scripts`, `P:\DZ`).

FileBank.exe -property prefix=<Mod> -exclude <lst> -dst <staging> P:\<Mod>

exit=0

<staging>\<Mod>.pbo -> 79 bytes

Test-Path -LiteralPath "P:\" # si False:

subst P: "<dayz-projects>"

$k = Get-ItemProperty 'HKCU:\Software\Valve\Steam\ActiveProcess'

$st = Get-Process -Name steam -ErrorAction SilentlyContinue

$ok = $st -and ($st.Id -contains [int]$k.pid) -and $k.ActiveUser -ne 0

|---|---|

**Two Steam facts the registry cannot answer (measured 2026-09-08, LFPowerGrid; SP-382).** (1) WHICH account is logged in: read `logs/connection_log.txt` under the Steam install for `[Logged On, ...] [U:1:<accountID>] RecvMsgClientLogOnResponse() : 'OK'` (`SteamID64 = accountID + 76561197960265728`). (2) Whether that account OWNS DayZ: `steamapps/appmanifest_221100.acf`, field `"LastOwner"`. If the logged-in account is not the LastOwner, the client dies about one second after launch with the same header-only RPT + `0x80000003` signature while every registry check passes green; the dump's `Caching Steam ID: <id>` vs `LastOwner` closes the case in a minute. [EXACT] (measured, SP-382]

```powershell

$fs = [IO.File]::Open($path, [IO.FileMode]::Open, [IO.FileAccess]::Read,

[IO.FileShare]::ReadWrite)

try { $text = [IO.StreamReader]::new($fs).ReadToEnd() } finally { $fs.Dispose() }

```

mods.

```text

```

```text

SCRIPT : string <var> = '<payload>'

```

```

scripts\4_World\LFG10_Probe.c 3579 <- y en disco: 3579

scripts\5_Mission\LFG10_Driver.c 4756 <- y en disco: 4756

```

```

dayz_test_run(project="DayZ_MCP", mode="all", extra_mods=["@MiProbe"])

```

`build_native_launcher.py`.

```

A6_MK47_dev\tools\dayz-test.ps1:422-429

ExpandedBuilding_dev\tools\dayz-test.ps1:403-408

LFGungame_dev\tools\dayz-test.ps1:353-354

```

```powershell

if ($p.ExitCode -ne 0) { Die "AddonBuilder failed (exit $($p.ExitCode)). ..." }

$pbo = Join-Path $target "$Mod.pbo"

if (-not (Test-Path $pbo)) { Die "Build reported success but $pbo is missing." }

# Sanity: ... -lt 4096 ...

Ok "deployed: $pbo ($((Get-Item $pbo).Length) b)"

```

|---|---|---|

```powershell

$before = if (Test-Path $pbo) { (Get-Item $pbo).LastWriteTimeUtc } else { [datetime]::MinValue }

# ... Start-Process AddonBuilder ...

if (-not (Test-Path $pbo)) { Die "Build reported success but $pbo is missing." }

if ((Get-Item $pbo).LastWriteTimeUtc -le $before) {

Die "PBO no cambio: AddonBuilder no lo reescribio (destino bloqueado por una corrida viva?). El desplegado sigue siendo el anterior."

}

```

**Two more masks of the same trunk (af59 round 2, measured 2026-09-08).** (1) The generated launcher FABRICATES its own destination: `Invoke-Build` creates `<WorkDrive>\Mods\@<Mod>\Addons` with `New-Item -Force` if missing, and `-BuildOnly` / `-Mode none` reach `Invoke-Build` without passing through the preflight, so a missing `Mods` folder becomes a PLAIN folder that silently receives the PBO — the script prints `[ok] deployed` and the engine never reads it (reproduced literally: `exit=0; Mods created=True; junction=False`; the two lines are in 6 of 6 mod trees and in the template). The destination check — exists AND is a reparse point — must run from the build path itself before copying, not only in the interactive preflight. (2) Add the stdout text gate beside the byte gate: capture AddonBuilder stdout (`Start-Process -RedirectStandardOutput`) and require `Build Successful` while rejecting `[ERROR]: Build failed`. The pair discriminates: a false "Successful" with an untouched PBO dies on the mtime/hash gate; a touched-but-failed build dies on the text gate. A FIRST legit build has no previous PBO, so the byte comparison must be guarded (compare only when a previous PBO existed). [EXACT] (measured, SP-380]

```powershell

Get-CimInstance Win32_Process -Filter "Name LIKE 'DayZ%'" |

Select-Object ProcessId, CommandLine

```

`@SurvivorAnims`.

```bash

for f in _server/profiles/*.RPT _client/profiles/*.RPT; do

m=$(grep -m1 -oE '\-mod=[^ ]*' "$f")

printf "%-52s %s\n" "$(basename $f)" "$m"

done

```

cd <DayZ_MCP_dev>\tools

26 <-> 53 ms.

Reglas:

Evidencia y recetas: `<vault>\30_Sessions\2026-09-13-LFHeli-el-bote-sigue-al-foco-del-cliente.md`.