Pretty-prints every record in <zoneDir>/items.json as a table with
idx / id / itemLevel / stackable / quality (named) / displayId /
name columns. Also supports --json for machine-readable output
(emits the items array verbatim).
Verified on a 3-item zone: table output aligns columns, quality
labels resolve correctly (common/uncommon/legendary), --json mode
emits a clean array consumable by jq or downstream tools. Brings
command count to 197.
Introduces a new per-zone content file alongside creatures.json /
objects.json / quests.json. Schema: {"items": [{id, name, quality,
displayId, itemLevel, stackable}, ...]}. Inline JSON manipulation
via nlohmann::json — items are simple records and don't yet need
NpcSpawner-style infrastructure.
ID assignment: pass 0 (or omit) to auto-pick the smallest unused
positive integer so numbering stays contiguous. Explicit IDs are
honored. Duplicate IDs rejected with exit 1 so collisions are
visible.
Quality is 0..6 (poor/common/uncommon/rare/epic/legendary/artifact)
— summary line maps the number to the human name so users see what
they wrote.
Verified: auto-id sequential (1, 2) → explicit id (99) honored →
duplicate id rejected with exit 1; JSON schema stable, quality
labels correct, file auto-created on first call. Brings command
count to 196.
Synthesizes a procedural WOM model with proper per-face normals,
planar UVs, a bounding box, and a single batch covering all indices
so the model renders immediately in the editor without further
processing.
Three shapes:
- cube — 24 verts / 12 tris, axis-aligned, ±size/2 (per-face flat
normals, requires duplicated verts at edges)
- plane — 4 verts / 2 tris on the XY plane (Z=0), ±size/2
- sphere — UV sphere, 16 segments × 12 stacks, radius=size/2
(221 verts / 384 tris)
Default size=1.0 (unit cube/plane/unit-diameter sphere). Pair with
--gen-texture to make a ready-to-place model from scratch.
Verified all three shapes write valid v3 WOM files with correct
vertex/triangle counts, correct bounds, and a single opaque batch;
cube.wom round-trips cleanly through --export-obj (24 verts in →
24 verts out). Brings command count to 195.
Lets users add a working texture to a project without firing up an
external image editor. Useful for prototyping new meshes, filling
out a zone before art is final, or generating CI test fixtures.
Three spec modes:
- "RRGGBB" or "RGB" hex (case-insensitive, optional leading '#') →
solid fill
- "checker" → 32x32 black/white checkerboard
- "grid" → black background with white 1-px grid every 16
Default 256x256, configurable via optional W H positional args
(clamped to 1..8192). Writes via stbi_write_png so the output is a
standard PNG every WoW open-format pipeline already accepts.
First commit in the new "add content" direction (items / textures /
meshes) the user requested. Verified: solid hex (ff0000), 3-char
hex (8a3), checker, grid all produce valid PNGs of correct sizes;
'notacolor' input fails with exit 1 and a clear error. Brings
command count to 194.
Generates MIGRATION.md with: status badge ("100% migrated", "Mostly
migrated", "Partially migrated", "Migration pending"), summary
counts, per-pair table with shares, and recommended next steps as
copy-pasteable wowee_editor invocations. Drops cleanly into PR
descriptions, CI artifacts, or GitHub Pages status pages.
Verified: 50%-migrated test tree → "Partially migrated" badge,
correct per-pair shares (.m2→.wom 100%, .blp→.png 0%), recommended
steps point at the actual srcDir. Brings command count to 193.
Top-N largest proprietary files (.m2/.wmo/.blp/.dbc) in <srcDir>.
Helps users decide what to migrate first when sequencing the work
across a large extracted Data tree — convert the heaviest files
first to free the most disk space soonest.
Each row annotates whether an open sidecar already exists ("migrate")
or is still pending ("pending"), so the heavy hitters that are
already migrated are visible at a glance.
Default N = 20 (one terminal page); pass an explicit N for a
different cutoff. Header reports total proprietary bytes plus the
share captured by the top-N rows so users know how much of the work
the displayed list represents.
Verified: 3-file mixed tree (100/50/10 KB) → ranked descending by
size, .m2 (with sidecar) shows "migrate", others show "pending",
total/shown bytes match. Brings command count to 192.
Times each step of --migrate-data-tree (m2/wmo/blp/dbc) end-to-end
and reports wall-clock per step plus the total. Useful for capacity
planning ("how long will the full extracted Data tree take?") and
regression detection (a recent change shouldn't make M2 conversion
2x slower).
Sub-batches dispatched the same way --migrate-data-tree dispatches
them, so the timings are exactly what the user will experience
running the migration. Both human (table with share %) and --json
output modes.
Verified: 4-format synthetic tree → all 4 steps timed individually,
share percentages sum to 100, total reported in both ms and seconds.
M2 + WMO dominate the share even on empty inputs (AssetManager init
overhead surfaces here, useful insight). Brings command count to 191.
Non-destructive CI gate that exits 1 if any proprietary file
(.m2/.wmo/.blp/.dbc) lacks a matching open sidecar at the same
(parent, stem). The pre-strip safety check: don't run --strip-data-
tree until this returns exit 0.
Lists the missing sidecars (capped at 50) so the user can re-run
--migrate-data-tree to fill the gaps. Per-extension breakdown
identifies which converter to investigate if specific formats are
underrepresented.
Completes the data-tree workflow:
--info-data-tree visibility
--migrate-data-tree fill sidecars
--audit-data-tree confirm 100% before stripping
--strip-data-tree delete migrated proprietary originals
Verified: empty tree → PASS exit 0; fully migrated → PASS exit 0;
gaps (1 .m2 + 1 .blp lacking sidecars) → FAIL exit 1 with both
files listed sorted, per-ext counts correct. Brings command count to
190.
Destructive cleanup that completes the data-tree migration workflow.
Walks <srcDir>, finds every proprietary file (.m2/.wmo/.blp/.dbc)
that already has a matching open sidecar at the same (parent, stem),
and deletes the proprietary file. Files without sidecars are
preserved (still need migration).
Honors --dry-run for safe previews. Defaults to actually delete
(matches --strip-zone convention).
Recommended workflow:
--info-data-tree see migration share
--migrate-data-tree fill in missing sidecars
--strip-data-tree --dry-run confirm kill list
--strip-data-tree apply
Verified: 11-file mixed tree → dry-run preserves all 11; apply
removes exactly the 4 that have sidecars (foo.m2, castle.wmo,
sky.blp, Spell.dbc); the 3 unmatched proprietary files
(bar.m2, grass.blp, Item.dbc) are correctly kept. Brings command
count to 189.
Companion to --migrate-data-tree. Walks <srcDir> recursively, counts
files per format pair (.m2 vs .wom, .wmo vs .wob, .blp vs .png, .dbc
vs .json), and reports per-pair counts plus an overall migration
share — the fraction of source files that already have an open
sidecar present.
A "sidecar" is matched by parent dir + stem (case-insensitive ext),
so the comparison is sound across nested trees. Orphan open files
(present without a matching proprietary) are also reported — those
are the candidates for keeping after stripping the originals.
Designed to drop into CI dashboards: a 100% migration share means
every proprietary asset has a deterministic open counterpart on disk
and the originals are safe to delete.
Verified on a mixed tree: 8 proprietary / 4 sidecars (50% share)
correctly reported per pair, plus 1 orphan .json detected. Brings
command count to 188.
Composes the four bulk converters into a single one-shot migration
of an extracted Data tree. Runs --convert-m2-batch → --convert-wmo-
batch → --convert-blp-batch → --convert-dbc-batch in order, streams
each step's full output through, then emits an aggregate summary
with per-step PASS/FAIL.
The headline open-format command: point it at a freshly extracted
Data dir and every .m2/.wmo/.blp/.dbc gets converted to its open
counterpart in one call. Idempotent — re-running on a partially-
migrated tree just re-attempts the originals (sidecars are
deterministic).
Verified: 4-format synthetic tree → all four sub-batches dispatched,
aggregate summary correctly reports per-step rc, exit 1 when any
sub-converter reports failures (verified with true exit code, not
shell pipeline gotcha). Brings command count to 187.
Final commit in the four-format batch-converter set. Walks <srcDir>
recursively for every .dbc file (case-insensitive) and re-invokes
--convert-dbc-json per file, writing a .json sidecar next to each
source.
The batch converters now cover the full proprietary→open transition:
--convert-m2-batch .m2 → .wom
--convert-wmo-batch .wmo → .wob (skipping _NNN group files)
--convert-blp-batch .blp → .png
--convert-dbc-batch .dbc → .json
Run all four against an extracted Data tree to migrate it end-to-end
to the open format ecosystem.
Verified: 3 .dbc files (case-insensitive, sub-dir) discovered;
.json file in same tree skipped; exit 1 on failures. Brings command
count to 186.
Walks <srcDir> recursively for every .blp file (case-insensitive) and
re-invokes --convert-blp-png per file. The single-file converter
writes the .png as a sidecar next to the source by default, so a
batched run mirrors the standard "PNG sidecar everywhere" layout
that the editor's open-format runtime expects.
Verified discovery: 3 placeholder .blp files (lowercase, uppercase,
sub-dir) found correctly; .png file in same tree skipped; all fail
conversion as expected for empty bytes; exit 1 on failures. Brings
command count to 185.
Sibling to --convert-m2-batch. Walks <srcDir> recursively for every
.wmo file (case-insensitive) and re-invokes --convert-wmo per file
via a child process so the existing root-WMO + group-loading logic
is reused verbatim.
Skips group files (e.g. Stormwind_001.wmo) since the root WMO
converter already pulls those in transitively. Detection: stem ends
in _NNN with NNN being three digits.
Verified: 5 .wmo files → 2 root candidates, 3 group files correctly
skipped, summary line accurate. Brings command count to 184.
Walks <srcDir> recursively for every .m2 file (case-insensitive,
including subdirs) and re-invokes --convert-m2 per file via a child
process so the existing single-file logic — AssetManager init, skin
file resolution, fromM2() pipeline — is reused verbatim. Per-file
[ok]/[FAIL] line streamed live; aggregate summary at the end.
Designed to migrate an entire creature/world model dump in one go.
This is the headline open-format conversion: every .m2 in a
proprietary data tree gets turned into a .wom open-format model. Pair
with the upcoming --convert-wmo-batch / --convert-blp-batch /
--convert-dbc-batch to migrate a complete extracted Data tree.
Verified discovery: 3 placeholder .m2 files (one in subdir, one
.M2 uppercase) found correctly; .txt skipped; all fail conversion as
expected for empty bytes; exit 1 on any failure. Brings command
count to 183.
Destructive companion to --list-project-orphans. Reuses the same
reference-collection + orphan-detection logic, then deletes the
resulting .wom/.wob files. Honors --dry-run for safe previews.
Completes the list/remove cycle for unreferenced model files: run
--list-project-orphans to audit, then --remove-project-orphans
--dry-run to confirm, then drop --dry-run to actually clean. Useful
right before --pack-wcp so the archive doesn't carry dead weight.
Verified: dry-run preserves files (3 reported, all still present);
real run on a copy removes all 3 with no failures, freeing 1.2 KB.
Brings command count to 182.
Inverse of --list-zone-deps. Walks every zone in <projectDir>,
collects the set of .wom/.wob files on disk plus the set of paths
actually referenced by objects.json placements + WOB doodad lists,
and reports any model files in the first set but not the second.
Useful pre-pack cleanup — orphans bloat .wcp archives without
contributing to gameplay. The output table shows zone + path + bytes
so users can decide which to delete.
Comparison normalizes paths by stripping extensions and matching both
the full relative path and the leaf basename, so unqualified refs in
objects.json (e.g. just "cube_a" without ".wom") still resolve.
Verified: empty objects.json → 3 orphans across 2 zones; after
--add-object cube_a → only 2 orphans remain (cube_a correctly removed
from the list). Brings command count to 181.
Project-wide companion to --info-zone-density. Walks every zone in
<projectDir>, sums creatures/objects/quests, and emits a per-zone
breakdown table with per-tile averages plus project-wide totals.
Helps spot zones that are abnormally sparse (5 mobs across 16 tiles,
"why is this zone so empty?") or stuffed (200 mobs in 1 tile, frame-
rate bomb), and surfaces the project's overall content footprint.
Brings command count to 180 — 180 distinct CLI flags now.
Project-wide companion to --info-zone-water. Walks every zone in
<projectDir>, sums water chunks/layers and liquid type counts per
zone, and emits a per-zone breakdown table plus project-wide totals
broken down by liquid type (water/ocean/magma/slime).
Useful for "do my coastal zones actually carry ocean data" sanity
checks and for budget planning when many zones share liquid types
(e.g. an archipelago where every zone has 256 water chunks per tile).
Brings command count to 179.
Project-wide companion to --info-zone-extents. Walks every zone in
<projectDir>, computes each zone's tile XY range and Z height range,
then unions them into a project-wide world bounding box. Per-zone
breakdown table shows each zone's disjoint world ranges so overlap
issues are visible at a glance.
Useful for sizing the world map overview, sanity-checking that zones
don't overlap (project-union should equal sum of per-zone areas for
disjoint layouts), and understanding total project area in both
yards and meters.
Verified on 2-zone test project: each zone correctly resolves to one
533x533yd tile, project union is 1066x533yd (the two tiles arranged
horizontally), Z range matches manifest baseHeight + heightmap delta.
Brings command count to 178.
Wraps --repair-zone across every zone in <projectDir>. Spawns the
binary per-zone so each zone's full repair report streams through,
with section markers between, then aggregates a final tally. Honors
--dry-run.
Calls fflush(stdout) before each child spawn so the parent's section
header lands ahead of the child's stdout (separate buffers per
process).
Verified: clean project → 0 fixes / exit 0; project with an orphan
tile file → "would add tile (5, 5) to manifest" / exit 0 (dry-run).
Brings command count to 177.
Re-invokes the binary itself to run the four key per-project checks
back-to-back and rolls their exit codes into a single PASS/FAIL
verdict. Designed to be the only command CI needs to run before
--pack-wcp or release tagging.
Sub-checks: validate-project (format integrity), validate-project-
open-only (no proprietary leaks), check-project-refs (every model/NPC
ref resolves), check-project-content (sane field values). Sub-output
is suppressed; the audit's own report shows one line per check plus
the final overall result. Users rerun a failing sub-check directly
for detail.
Verified: clean project → all PASS, exit 0; project with a .blp leak
→ open-only gate fails as expected, OVERALL: FAIL exit 1. Brings
command count to 176.
Project-wide companion to --list-zone-textures. Walks every WOM across
every zone in <projectDir>, dedupes texture paths globally, and emits
both a per-zone WOM/unique-texture summary table and a project-global
texture set with usage counts.
Useful for "how many textures do I need to ship across the whole
project" — texture sharing across zones often makes the global set
much smaller than the per-zone sum, and the usage counts identify
shared workhorses vs zone-specific assets.
Brings command count to 175.
Wraps --strip-zone across every zone in <projectDir>. Removes derived
outputs (.glb/.obj/.stl/.html/.dot/.csv/.png/ZONE.md/DEPS.md) at each
zone's top level, leaving source files (zone.json + content JSONs +
open binary formats) untouched. Per-zone breakdown table plus aggregate
freed-bytes total. Honors --dry-run for safe previews.
Useful before --pack-wcp to keep release archives lean, or before a
git commit so derived blobs don't bloat history across many zones at
once.
Verified: dry-run shows "would-remove" totals matching the actual
delete pass on the 2-zone test project (870.8 KB per zone, 1741.6 KB
freed). Brings command count to 174.
CI-friendly check that exits 1 if any proprietary Blizzard asset
(.m2/.skin/.wmo/.blp/.dbc) remains in <projectDir>. Designed as the
final gate before shipping a wholly open-format project release —
once it returns exit 0 the project ships only WOM/WOB/PNG/JSON
content with no Blizzard binary payloads at rest.
Reports per-extension counts and lists the offending files (capped at
50 to avoid flooding the terminal on a wholly unmigrated project).
Verified: pass case on open-only test project (exit 0); fail case
after dropping fake .blp + .m2 (exit 1, both files listed under their
extensions). Brings command count to 173.
Project-wide byte audit. Walks every zone in <projectDir>, re-uses the
--info-zone-bytes categorization, and emits a per-zone breakdown table
plus aggregated category totals. The headline is the open-vs-proprietary
size split — surfaces how much disk a project still spends on .m2/.wmo/
.blp/.dbc payloads vs the open WOM/WOB/PNG/JSON replacements.
Useful as a migration progress metric: an "open share" of 100% means
the project no longer ships any proprietary Blizzard assets at rest.
Verified: 2-zone test project shows 1246B open, 0B proprietary, 100%
open share (the expected state after WOM-only authoring). JSON form
emits the same numbers structured. Brings command count to 172.
Closes the emit/verify loop for --export-project-checksum natively, so
Windows runners and CI containers without coreutils' sha256sum can
still validate PROJECT_SHA256SUMS. Re-hashes every file listed in the
manifest, reports ok/missing/mismatched counts, and exits 1 on any
failure with a per-file failure list.
Verified all three paths: success (9 ok / exit 0), missing file
(1 missing / exit 1), mismatched hash (2 mismatched / exit 1).
Brings command count to 171.
Project-wide companion to --info-zone-models-total. Walks every zone in
<projectDir>, sums verts/tris/bones/anims/batches per WOM and groups/
verts/tris/doodads/portals per WOB, then prints a per-zone breakdown
table plus a TOTAL row. Both human (table) and --json output modes.
Useful for capacity planning across an entire content project — e.g.
"how many bones across all my creatures" or "total triangles per frame
if every model loaded simultaneously."
Verified on the 2-zone migration test project: per-zone counts match
--info-zone-models-total output, totals row aggregates correctly,
JSON form parses cleanly. Brings command count to 170.
Project-wide companion to --export-zone-checksum. Walks every zone in
<projectDir>, hashes every source file, and emits PROJECT_SHA256SUMS in
the standard sha256sum format with paths kept relative to projectDir
(so entries look like "<hex> <zone>/<file>"). Also computes a single
SHA-256 fingerprint over the manifest body — a one-line identity for
the whole project, useful for CI release gates and reproducibility.
Verified: external 'sha256sum -c PROJECT_SHA256SUMS' passes all 9
entries on a 2-zone test project, and standalone 'sha256sum
PROJECT_SHA256SUMS' matches the emitted fingerprint byte-for-byte.
Adds wowee_sha256::hex(buf, len) helper. Brings command count to 169.
Wraps --migrate-zone across every zone under <projectDir>, so a single
invocation upgrades legacy WOM1/WOM2 files to WOM3 with batches[]
populated across an entire content project. Per-zone breakdown table
shows scanned/upgraded/already-v3/failed counts for visibility.
Verified end-to-end: scaffold 2 zones, drop 3 v1 cubes, run --migrate-
project once → 3/3 upgraded; second run → 0 upgraded, 3 already-v3
(idempotent). Brings total command count to 168.
Camera::setPosition now refuses NaN, so flyToSelected() would silently
do nothing if the selected entity had a corrupted position. Surface it
as a toast so the user knows the selection is unusable rather than
wondering why the camera didn't move.
Aggregates WOM/WOB stats across every model in a zone. Useful for
capacity planning and perf budgeting:
wowee_editor --info-zone-models-total custom_zones/MyZone
Zone models total: custom_zones/MyZone
WOM (open M2):
files : 47
vertices : 184320
triangles : 122880
bones : 612
anims : 94
batches : 188
WOB (open WMO):
files : 8
groups : 32
vertices : 28480
triangles : 18960
doodads : 156
portals : 24
Combined :
vertices : 212800
triangles : 141840
Per-format aggregation (WOM = open M2, WOB = open WMO) plus a
combined totals row. Catches:
- 'how many bones across all my creatures?' (rigging budget)
- 'total triangles per frame if all loaded?' (perf ceiling)
- 'do my models actually have multi-batch material support?'
(counts batch entries; 0 means everything is WOM1/WOM2)
Walks the zone dir recursively so models in subdirs (creatures/,
buildings/, props/) all roll up. JSON mode emits per-format records
for capacity dashboards.
Project-level cross-reference checker. Walks every zone and runs the
same model-path / NPC-id checks --check-zone-refs does, with per-zone
breakdown:
wowee_editor --check-project-refs custom_zones
check-project-refs: custom_zones
zones : 12 (2 failed)
total missing: 5
zone obj_chk obj_miss q_chk q_miss status
AshenForest 12 0 4 0 PASS
BoneOasis 17 2 6 0 FAIL
Stranglethorn 34 1 8 2 FAIL
...
2 zone(s) have dangling refs
Per-zone columns split objects vs quests so designers see at a
glance whether the issue is missing models (asset bundle drift) or
NPC IDs (creature definitions out of sync with quest references).
Pairs with --check-project-content (data quality) and
--validate-project (binary integrity). Together the three give a
complete pre-ship validation gate:
--validate-project binary structure
--check-project-content field plausibility
--check-project-refs cross-references resolve
Verified on a 2-zone project: Forest mvp-zone has 1 unresolved
object placement (no Tree.m2 on disk in test cwd), Bad zone has
1 missing object → 2 zones FAIL, exit 1.
Renders WOM bone hierarchy as Graphviz DOT. Mirrors --export-quest-graph
for skeleton trees: a 50-bone tree from --info-bones is hard to read in
text; pipe this through 'dot -Tpng' for the picture:
wowee_editor --export-bones-dot HumanMale
dot -Tpng HumanMale.bones.dot -o bones.png
Visual encoding:
- lightgreen fill: keybones (named anchor points referenced by gameplay
systems — head, hands, feet, etc.)
- lightgrey fill: internal/blend bones (non-key, used for shape only)
- goldenrod border: root bones (parent=-1, top of skeleton hierarchy)
Edges flow parent -> child (rankdir=TB so root is at top, leaves at
bottom).
Useful for skeleton-debugging:
- 'why is this finger not following its hand?' -> see the parent chain
- 'is this bone really a root or did its parent get deleted?' ->
goldenrod border makes intentional roots vs accidental ones obvious
- understanding which bones gameplay code can reference by key id
Verified on a 5-bone synthesized skeleton (3-deep chain + 1 detached
root + mix of key/internal): DOT correctly emits 5 nodes with the
right colors (3 lightgreen for key bones, 2 lightgrey for internal,
2 with goldenrod root borders), 3 edges traversing the chain.
Counterpart to --scaffold-zone / --copy-zone / --rename-zone — completes
the zone-lifecycle CRUD. Defense-in-depth against accidental
destruction:
wowee_editor --remove-zone custom_zones/Doomed
remove-zone: custom_zones/Doomed ('Doomed')
would delete: 6 file(s), 174.9 KB
re-run with --confirm to actually delete
wowee_editor --remove-zone custom_zones/Doomed --confirm
Removed custom_zones/Doomed ('Doomed')
deleted: 7 filesystem entries, 174.9 KB freed
Two-step safety:
1. Without --confirm: dry-run that lists what would be deleted
(file count + total bytes + zone display name from manifest).
2. With --confirm: actually wipes the directory.
Belt-and-suspenders refusal: even with --confirm, refuses to delete
anything that doesn't have a zone.json at the top level. Catches
typos like '--remove-zone .' that would otherwise nuke an entire
project.
Why not just 'rm -rf'? --remove-zone gives:
- Per-zone display name in the confirmation
- Byte-count audit before deletion
- The non-zone-dir guard (rm doesn't know what a zone is)
- Symmetric with the rest of the zone-lifecycle CLI
Verified: dry-run lists 6 files / 175 KB; '. --confirm' correctly
refused (no zone.json at top level); zone-dir --confirm wiped 7
fs entries with byte tally.
Tree view of a WCP archive's contents with per-file byte sizes.
--list-wcp shows the flat sorted file list; this gives the
hierarchical view that's easier to read for archives with
subdirectories:
wowee_editor --info-pack-tree custom_zones/MyZone.wcp
custom_zones/MyZone.wcp (47 files, 2348.21 KB)
├─ Forest_28_30.whm (150540 bytes)
├─ Forest_28_30.wot (26685 bytes)
├─ buildings/
│ ├─ inn.wob (45120 bytes)
│ └─ tavern.wob (38104 bytes)
├─ creatures.json (694 bytes)
├─ data/
│ ├─ Spell.json (15032 bytes)
│ └─ Item.json (8194 bytes)
├─ objects.json (234 bytes)
└─ zone.json (500 bytes)
Recursive renderer with UTF-8 box-drawing connectors. Files show
their byte size; directories show the subtree subtotal aggregated
from children. Children sorted alphabetically (std::map).
Pairs with --info-pack-budget (per-extension byte breakdown) and
--list-wcp (flat sorted list) — three lenses on the same archive:
hierarchy / extension cost / flat search.
Verified on a 6-file mvp-zone WCP: tree correctly shows top-level
files (no subdirs in mvp-zone output) with byte sizes and total
175 KB summary.
Project-level content sanity check. Walks every zone and runs the
same per-zone checks --check-zone-content does, aggregating warnings
per zone. Designed for CI gates before --pack-wcp:
wowee_editor --check-project-content custom_zones
check-project-content: custom_zones
zones : 12 (2 failed)
total warns : 7
zone creat object quest status
AshenForest 0 0 0 PASS
BoneOasis 3 0 1 FAIL
CrystalCaverns 0 0 0 PASS
Stranglethorn 2 1 0 FAIL
...
2 zone(s) have content warnings
Per-zone warning columns (creature/object/quest) make it instantly
clear which content category needs attention. Exit 1 if any zone
has any warning so CI can gate.
Pairs with --validate-project (binary integrity) — both needed for
release gates: a zone can have valid file structure (validate
passes) AND content data-quality issues (check-content fails).
Verified on a 2-zone project: mvp-zone Forest (all defaults sane)
PASS, Empty zone with displayId=0 creature FAIL with 1 warning,
exit 1.
Renders a top-down PNG showing creature + object spawn positions
colored by type. Bound by the zone's tile range so the image is
properly framed at zone scale:
wowee_editor --export-zone-spawn-png custom_zones/MyZone
# -> custom_zones/MyZone/MyZone_spawns.png
Layout:
- Tile-grid lines at tile boundaries (subtle grey on dark grey)
- Red 3×3 dots: creature spawns
- Green 3×3 dots: M2 object placements
- Blue 3×3 dots: WMO object placements
- 256 px per tile (so a 4-tile zone is 512×512); cap at 4096
largest dim for huge multi-tile projects
WoW coord -> image transform: +X world is north (up in image),
+Y world is west (left in image). Same convention --info-tilemap
uses, so the spawn map and the tilemap line up visually.
Useful for design review ('does the spawn distribution match the
encounter design?'), screenshot bait for blog posts, and instant
visual validation of new content before opening the GUI.
Verified on a 1-tile mvp-zone with 3 creatures + 1 object plotted:
256×256 RGB PNG, dots placed at expected positions, --info-png
confirms the output is well-formed (8-bit RGB, 2184 bytes).
Companion to --bench-validate-project. Times the WHM/WOT load step
(the dominant cost in --bake-zone-glb/obj/stl) per zone. The actual
write side adds ~constant cost proportional to vertex count, so
load time is a strong proxy for bake cost:
wowee_editor --bench-bake-project custom_zones
Bench bake (load-only): custom_zones
zones : 12
total : 4731.20 ms (terrain load)
per zone : avg=394.27 min=87.42 max=2103.55 ms
slowest : Stranglethorn (2103.55 ms)
Per-zone:
zone ms tiles chunks ms/tile
AshenForest 87.42 1 256 87.42
BoneOasis 245.10 4 1024 61.27
Stranglethorn 2103.55 9 2304 233.73
Useful for tracking 'has my latest geometry change made baking 3×
slower?' across releases. Per-tile timing surfaces zones with
high-variance chunk loads (e.g. dense doodad placements that
inflate ADT load time).
Pairs with --bench-validate-project (validation timing). Both use
std::chrono::steady_clock for monotonic measurement; JSON modes
emit per-zone records for CI dashboard consumption.
Verified on a 2-zone project (Forest 2 tiles + Desert 1 tile):
correctly reports per-zone timings + ms/tile ratio.
Drills into a .glb's byte composition. Pairs with --info-glb (counts)
and --info-glb-tree (structure) — three lenses on the same file:
wowee_editor --info-glb-bytes custom_zones/Z/Z.glb
GLB bytes: custom_zones/Z/Z.glb
total: 891736 bytes (0.85 MB)
Sections:
header : 12 bytes 0.00%
JSON hdr : 8 bytes 0.00%
JSON : 828 bytes 0.09%
BIN hdr : 8 bytes 0.00%
BIN : 890880 bytes 99.90%
BufferViews:
idx target bytes MB share-of-bin
0 vertex 248832 0.24 27.93%
1 vertex 248832 0.24 27.93%
2 index 393216 0.38 44.14%
By attribute:
INDICES 393216 bytes (44.14% of BIN)
NORMAL 248832 bytes (27.93% of BIN)
POSITION 248832 bytes (27.93% of BIN)
Three breakdowns:
- Section costs (header + JSON chunk + BIN chunk + their headers)
- Per-bufferView with target hints (vertex / index / other)
- Per-attribute (POSITION/NORMAL/TEXCOORD_0/INDICES/etc.) bucketed
by walking accessors referenced from primitives
Catches asymmetric BIN allocation ('why is INDICES 44% of my .glb?')
and helps tune vertex layout decisions (drop normals if synthesized,
quantize positions if precision allows). Verified on a single-tile
zone bake: header+JSON is 0.1% of total, BIN is 99.9%, attribute
breakdown shows POSITION/NORMAL each 28% and INDICES 44%.
Companion to --info-pack-budget (which operates on .wcp archives).
Per-extension byte breakdown of an extract dir, sorted largest-first.
Answers 'where did my 31 GB extract go?' with a flat sortable table:
wowee_editor --info-extract-budget /home/k/Desktop/wowee/Data
Extract budget: /home/k/Desktop/wowee/Data
total: 284613 file(s), 31482.11 MB
ext count bytes MB share
.adt 11213 11985924414 11430.7 36.3%
.wav 39396 8107038542 7731.5 24.6%
.blp 133742 4990640480 4759.4 15.1%
.m2 48466 2568180656 2449.2 7.8%
.wmo 16526 2286454107 2180.5 6.9%
.mp3 1222 1976864519 1885.3 6.0%
...
Caps to top 30 extensions with the rest rolled into '(other)' so
big extracts (this one has 30+ format types) don't drown the
output.
Pairs with --info-extract-tree (hierarchical view) and
--info-extract (sidecar coverage) — three lenses on an extract
directory: structure, formats, byte costs.
Verified on a real 31GB Data/ extract: ADT files dominate at 36%
(11GB), with WAV audio second at 25% (8GB).
Quest-side analytics paralleling --info-creatures-by-faction/-level.
Two distribution views for difficulty-curve and reward-pacing analysis:
wowee_editor --info-quests-by-level $Z/quests.json
Quests by required level: ... (47 total)
range : 1 to 60 (avg 22.4)
level count bar
1 8 ████████████████████████████████████████
5 6 ██████████████████████████████
...
60 1 █████
wowee_editor --info-quests-by-xp $Z/quests.json
Quests by XP reward: ... (47 total)
range : 100 to 5000 (avg 1462, 0 with 0 XP)
bucket (≥XP) count bar
0 8 ████████████████████████████████████████
250 6 ██████████████████████████████
500 4 ████████████████████
5000 1 █████
(bucket size: 250 XP)
--by-level: catches difficulty-curve gaps (every quest level 1 → no
mid-game; cluster at 60 → no early game) and outliers (level-30
quest dropped into a starter zone).
--by-xp: bucket size auto-grows with the max XP value so the
histogram stays readable for both starter zones (10-100 XP per bin)
and endgame (5000+ XP per bin). Surfaces no-reward quests
explicitly so designers spot ones they forgot to fill in.
JSON modes emit per-bucket records for dashboards. Verified on a
4-quest seed (xp 100/250/500/5000): bucket-size correctly auto-
selected as 250 XP, range and avg match.
Per-tile batch runner. Pairs with --for-each-zone (project-level
tile iteration is too coarse for tile-level commands like
--build-woc, --validate-whm, --info-whm).
wowee_editor --for-each-tile custom_zones/MyZone -- \
wowee_editor --build-woc {}
[custom_zones/MyZone/MyZone_30_30 (30, 30)]
WOC built: custom_zones/MyZone/MyZone_30_30.woc (32768 triangles, ...)
[custom_zones/MyZone/MyZone_31_30 (31, 30)]
WOC built: custom_zones/MyZone/MyZone_31_30.woc (32768 triangles, ...)
for-each-tile: 2 tiles, 0 failed
The {} substitution receives the tile-base path (zoneDir/mapName_TX_TY)
which is the form most tile-level commands accept. Sorts tiles by
(tx, ty) so output ordering is deterministic.
Use cases:
- Build WOC for every tile in one shot after editing terrain
- Validate WHM headers across all tiles
- Export per-tile previews via --export-whm-obj
- Per-tile data dump via --info-whm
Same shell-escaping + cmd-substitution machinery as --for-each-zone
(safe against names with spaces and quotes). Returns failed-run
count as exit code (capped at 255).
Verified on a 2-tile zone running --build-woc per tile: both
tiles built correctly, exit 0.
Times --validate-project per zone. Useful for catching unusually
slow zones (huge WHM/WOC pairs, lots of WOM batches) and tracking
validation overhead growth across releases:
wowee_editor --bench-validate-project custom_zones
Bench validate: custom_zones
zones : 12
total : 4731.20 ms
per zone : avg=394.27 min=87.42 max=2103.55 ms
slowest : Stranglethorn (2103.55 ms)
Per-zone timings:
zone ms files ms/file
AshenForest 87.42 8 10.928
BoneOasis 245.10 17 14.418
Stranglethorn 2103.55 94 22.378
...
Reports total + avg/min/max per zone + slowest zone callout. Per-
zone table with ms/file ratio surfaces formats that scale poorly
('this zone has only 5 files but takes 2 seconds — one is a 100MB
WHM that's slow to load').
Useful for:
- Pre-commit profiling: 'did my validator change make Stranglethorn
3× slower?'
- CI cycle time budgeting
- Catching pathological inputs (a 10000-creature creatures.json that
blows up validation cost)
JSON mode emits per-zone records + aggregate stats for dashboards.
Verified on a 2-zone project: per-zone timings make sense (Forest
with .woc takes 5× longer than Desert without).
Per-tile content density. Catches sparse zones (5 mobs across 16
tiles → boring) and over-stuffed ones (200 mobs in 1 tile → frame-
rate bomb). Reports overall averages plus per-tile bucket counts:
wowee_editor --info-zone-density custom_zones/MyZone
Zone density: custom_zones/MyZone
tiles : 4
totals : 47 creatures, 23 objects, 8 quests
per-tile : 11.75 creatures, 5.75 objects, 2.00 quests
Per-tile breakdown:
tile creatures objects
(28, 30) 12 7
(29, 30) 18 4
(29, 31) 9 8
(30, 30) 8 4
Spawn-to-tile bucketing reverses the WoW grid transform from world
position back to tile (tx, ty) coords. Out-of-zone spawns silently
drop (they show up in --check-zone-refs / --check-zone-content as
their own warning class).
Useful for difficulty-curve work ('how packed is this hub vs this
zone-edge?'), perf budgeting ('which tile do I need to lod-out
first?'), and content-pacing reviews ('is the early game too empty?').
JSON mode emits per-tile records for dashboards. Verified on a
1-tile mvp-zone: 1 creature + 1 object + 1 quest, all bucketed
into the correct tile (28, 30).
Object-side counterparts to --info-creatures-by-faction/-level. Two
analytics commands for placement audits:
wowee_editor --info-objects-by-path $Z/objects.json
Objects by path: ... (47 total, 12 unique)
count share path
18 38.3% World/Generic/Tree.m2
9 19.1% World/Generic/Lamp.m2
4 8.5% World/Building/Inn.wmo
...
wowee_editor --info-objects-by-type $Z/objects.json
Objects by type: ...
M2 : 38 (scale 0.80-2.50, avg 1.12)
WMO : 9 (scale 1.00-1.00, avg 1.00)
--info-objects-by-path: most-used model paths first. Catches
'this looks repetitive, diversify the doodads' design feedback
and surfaces texture-budget hot spots (one model used 50× pulls
its textures into the working set 50×).
--info-objects-by-type: M2 vs WMO split + per-type scale stats.
Catches scale outliers ('this WMO is at 0.001 scale, did you mean
1.0?') and gives composition sense (mostly props vs mostly
buildings).
JSON modes emit per-path / per-type records for dashboards.
Verified on a 4-object seed (3 M2 + 1 WMO with mixed scales):
correctly reports Tree.m2 used 2× (50%), M2 scale range 0.80-1.50
avg 1.10.
Aggregates water-layer stats across every tile in a zone. Useful for
confirming a 'lake zone' actually has water, budgeting water-heavy
zones, or auditing what liquid types appear (water vs ocean vs magma
vs slime affects gameplay rules):
wowee_editor --info-zone-water custom_zones/Z
Zone water: custom_zones/Z
loaded tiles : 1
water chunks : 0 (out of 256 possible)
total layers : 0
(no water in this zone)
wowee_editor --info-zone-water custom_zones/Stranglethorn
Zone water: custom_zones/Stranglethorn
loaded tiles : 4
water chunks : 387 (out of 1024 possible)
total layers : 412
height range : 12.40 to 18.50
By liquid type:
water (0): 380 layer(s)
ocean (1): 28 layer(s)
magma (2): 4 layer(s)
Per-chunk water can have multiple layers (different liquid types or
height regions overlapping). Liquid types: 0=water, 1=ocean, 2=magma,
3=slime — different gameplay rules apply (oceans are swimable, magma
is damage-over-time, etc.).
JSON mode emits per-type layer counts + height range for programmatic
audit. Verified on a freshly-scaffolded zone: correctly reports 0
water chunks.
Multi-zone wrapper around --validate-all. Walks every zone in a
project and runs the per-format validators (WOM/WOB/WOC/WHM).
Aggregates pass/fail per zone with file-level breakdown:
wowee_editor --validate-project custom_zones
validate-project: custom_zones
zones : 12 (1 failed)
zone files failed errors status
AshenForest 47 0 0 PASS
BoneOasis 31 0 0 PASS
CrystalCaverns 28 2 14 FAIL
...
1 zone(s) failed validation
Designed for CI gates before --pack-wcp (or before tagging a release):
one command checks the whole project's binary integrity, exits 1 if
anything's broken with a clear breakdown of which zone went wrong.
Pairs with --validate-all (single-zone, all formats) and the
per-format validators (--validate-wom etc.). Three levels of
granularity now:
--validate-{wom,wob,woc,whm} single file
--validate-all single zone (or any dir)
--validate-project entire project
JSON mode emits per-zone records (totalFiles + failedFiles +
totalErrors) for dashboard consumption. Verified on a 2-zone
project with one tile having .woc built and one without — both
zones PASS, exit 0.
Two analytics commands for combat-balance work. Where --info-creatures
gives totals + behavior counts, these give the distributions:
wowee_editor --info-creatures-by-faction $Z/creatures.json
Creatures by faction: ... (47 total)
faction count share
7 12 25.5%
14 29 61.7%
35 6 12.8%
(factions: 7=human, 14=monster, 35=neutral, etc.)
wowee_editor --info-creatures-by-level $Z/creatures.json
Creatures by level: ... (47 total)
range : 5 to 32 (avg 14.2)
level count bar
5 4 ████████████████████████████████████████
6 3 ██████████████████████████████
...
30 1 ██████████
Faction histogram catches single-faction zones (one giant melee) and
mixed-faction tuning issues. Level histogram catches difficulty-curve
problems (cluster at 5, gap, cluster at 30) and outlier spawns
(level-60 boss accidentally placed in starter area).
ASCII bar chart for level distribution since gameplay tuning is
visual — '60% of mobs are levels 8-12 with a long tail' is more
intuitive as a bar than as numbers. Bars scale to longest bin so
small zones still get usable visualization.
JSON mode emits per-faction / per-level records for dashboards.
Verified on a 4-creature seed (3×faction-14 + 1×faction-35; levels
7/8/12/30): faction percentages and level range/avg both correct.
