| name | dayz-launch-workbench |
| description | Open Enfusion Workbench (DayZ Tools' script + UI editor) from the CLI, optionally pointed at a specific mod's project file. Spawns detached with cwd=P:\ so vanilla data resolves. Default behavior loads the vanilla dayz.gproj shipped with DayZ Tools; --mod <ModName> loads the per-mod gproj scaffolded by /dayz-new-mod. |
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-launch-workbench
Open Workbench without leaving the terminal. Default loads vanilla DayZ; --mod <ModName> loads the customized dayz.gproj that /dayz-new-mod writes into workspace/<ModName>/workbench/, so Workbench compiles and lints vanilla + your mod together.
Follow .claude/skills/_shared/dayz-conventions.md.
What it does
- Gates on
/dayz-preflight.
- Locates
workbenchApp.exe via DayZ Tools (Bin\Workbench\workbenchApp.exe).
- Resolves the project file:
--mod <ModName> → uses P:\<ModName>\workbench\dayz.gproj (the file scaffolded by /dayz-new-mod). Fails fast if the mod folder or gproj isn't there.--gproj <path> → uses an explicit .gproj path (escape hatch for non-scaffolded layouts).- Neither → no project arg; Workbench loads the default
dayz.gproj shipped next to workbenchApp.exe.
- Spawns
workbenchApp.exe with cwd=P:\ (so the gproj's Directory "./" resolves to the work drive root) and DETACHED_PROCESS so the shell returns immediately.
How to run
Just open Workbench on vanilla:
python "<skill-dir>\launch.py"
Open with a mod's project file (compiles vanilla + mod together):
python "<skill-dir>\launch.py" --mod MyMod
(Requires P:\MyMod\workbench\dayz.gproj to exist — created automatically by /dayz-new-mod MyMod.)
Open with an arbitrary gproj:
python "<skill-dir>\launch.py" --gproj P:\Custom\path\to\my.gproj
When to run
- After
/dayz-new-mod to start writing scripts/UI for a fresh mod with full code completion against vanilla.
- Anytime you want to edit
.layout files or browse vanilla scripts in their native IDE.
- When debugging script errors — Workbench's compiler surfaces the same errors the engine would hit at runtime.
Output
DayZ Workbench launcher
[OK] P:\ mounted
[OK] DayZ Tools: ...
[OK] Vanilla data: P:\dz
[OK] P:\Mods junction valid
[OK] workbenchApp.exe: ...\Bin\Workbench\workbenchApp.exe
[INFO] Project: P:\MyMod\workbench\dayz.gproj
[OK] Working directory: P:\
[OK] Workbench launched (PID 12345). The window may take a few seconds to appear.
Flag rules
--mod and --gproj are mutually exclusive.--mod is just the mod name; the skill expands to P:\<ModName>\workbench\dayz.gproj. Fails fast if either the mod folder or the gproj is missing.--gproj accepts an absolute path (relative paths resolve against repo root). Warns if the extension isn't .gproj.
Why cwd=<DayZ Tools>\Bin\Workbench
Workbench loads its support files (dta\, platforms\, ToolAddons\) and its bundled dayz.gproj relative to cwd, not relative to workbenchApp.exe. Launching from anywhere else (including P:\) triggers a "cannot find file dayz.gproj" error even when a valid project file is passed as an argument. We always launch with cwd = <DayZ Tools>\Bin\Workbench\. The project file we pass as an arg is then loaded as the active project, while the support files resolve from the install dir as Workbench expects.
Vanilla data paths inside the gproj (e.g. DZ/Anims/cfg/..., gui/imagesets/...) are resolved by Workbench relative to the gproj file's location, NOT cwd — so as long as your mod's dayz.gproj lives next to its sibling <ModName>/ source tree on the work drive (the layout /dayz-new-mod produces), vanilla imports keep resolving via the P:\ junction the engine and Workbench share.
Why detached
Running Workbench under the parent shell would block the terminal until you close the editor. We spawn with DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP so:
- Closing this terminal doesn't kill Workbench.
- The skill exits immediately after the spawn.
- The PID is printed so you can find/kill it later if needed.
Do not
- Don't pass
--mod for a mod that wasn't scaffolded by /dayz-new-mod — the workbench/dayz.gproj won't exist. Run /dayz-new-mod <ModName> first.
- Don't edit the workbench/dayz.gproj manually expecting
/dayz-new-mod re-runs to preserve your changes — the scaffolder writes a fresh copy each time. If you need custom modules beyond the auto-injected game/world/mission, keep your edits in a side file or accept that re-running scaffolding will overwrite.
- Don't spam-launch — Workbench isn't designed to run multiple instances against the same project.
