draftnote 0005build 66792026-08-15prior-artecosystem

Prior art and ecosystem

Question

Who else has solved Deadlock data extraction, what did they build, and what should we borrow rather than rebuild?

Summary

Several mature projects already do end-to-end extraction. Read them before writing a parser.
deadlock-api/deadlock-api-assets is the most established: parses vdata to JSON and serves it publicly. If the goal is having the data rather than owning the pipeline, start here.
deadlock-wiki/deadbot is the best reference for the hard part — inheritance flattening and scale-function evaluation.
Status is draft: the summaries below come from project descriptions and search results, not from reading the source or running the code. Treat every claim in the Findings table as unverified until someone checks it.

Findings

⚠️ Unverified. Nothing in this table has been confirmed by reading source or running code. It is a map of where to look, not a set of facts.

project	what it claims to do	why it matters to us
deadlock-api/deadlock-api-assets	Static assets API; parses hero/item data to JSON, serves images, icons, sounds. Docs at `assets.deadlock-api.com/docs`. FastAPI.	Most established. Reference implementation for the JSON schema; also a shortcut if we just want data.
deadlock-wiki/deadbot	Decompiles, parses, and uploads Deadlock data to the wiki.	Closest to our pipeline shape. Likely the best reference for inheritance flattening and stat scaling.
0xThiagoAmaral/deadlock-open-assets	Pre-extracted vdata, 1,700+ icons, codename maps, JSON manifests.	Codename maps are the interesting artefact — validates our note 0004 join.
STmihan/deadlock-data-extractor	Automated image + data extractor; ships `data/heroes.json`.	Simplest reference; good for a first read.
simon-lund/deadlock-data	Scraped and copied data, structured.	Cross-check source for validating our numbers.
Artemon121/deadlock-ability-swapper	Decompiles and re-exports `heroes.vdata` / `abilities.vdata`.	Demonstrates the write direction, not just read.
dougwithseismic/dezlock-dump	Runtime schema + RTTI extraction from the running process.	Fundamentally different approach — see below.

Two distinct approaches

Static extraction (what notes 0001–0004 describe): read the VPKs, decompile, parse KV3. No game process involved. Reproducible, safe, offline. This is our path.

Runtime schema dumping (dezlock-dump, source2gen): attach to the running game and walk RTTI/schema metadata to recover struct layouts. Recovers information static extraction cannot — notably the meaning of fields and engine-internal structures.

Inferred: runtime dumping is only worth it if we hit a wall where field semantics are genuinely opaque. It carries anti-cheat and ToS considerations that static extraction does not, and should not be reached for casually.

Reproduce

Nothing here is reproducible yet — that is what makes this note draft. To promote it to verified, for each project:

git clone <url> /tmp/prior-art/<name>
# read the parser entry point; specifically look for:
#   - how _multibase / _class inheritance is flattened
#   - how m_subclassScaleFunction is evaluated
#   - the output JSON schema

Then rewrite the Findings table with confirmed behaviour and drop the warning banner.

Gotchas

Third-party datasets inherit third-party bugs. If a project does not flatten inheritance (note 0002, gotcha 1), its numbers are wrong in exactly the places that matter. Verify against the game before trusting any of them — including ours.
Check licences before copying code. Not surveyed.
Check freshness. A data repo that has not tracked recent patches is worse than no data, because it looks authoritative.

Open questions

Everything in the Findings table. See the warning above.
Licences of all listed projects — not surveyed.
Which projects are actively maintained as of August 2026 — not checked.
Whether deadlock-api-assets' JSON schema is a good fit for our goals, or shaped around their own site's needs.