Definitive Build API & Wiki
This section is the long-form technical and historical reference for the Starwind Definitive build. The project landing page intentionally stays short; this reference preserves the details required to reproduce, audit, or modify the pipeline without rediscovering years of TES3 archaeology.
The word API is used broadly here: this documents the build contract, data boundaries, invariants, generated artifacts, record-placement policy, and the interfaces between the project's tools.
Recommended reading order
- Build pipeline — start here for the complete stage graph.
- Source corpus & preprocessing — understand what enters the build and which historical edits are allowed.
- Master decoupling — how Bethesda-master dependencies are imported and then removed.
- Dialogue canonicalization — the most complicated subsystem and the largest body of source archaeology.
- Star_Data / Starwind split — the stable-data/content ABI and dependency rules.
- Validation & reports — the acceptance contract for every build.
- Historical cleanup ledger — specific removals, source fixes, and rejected historical behavior.
- Design decisions — policies that are intentional rather than accidental artifacts of the implementation.
- Tools & commands — executable/tool reference and common forensic workflows.
Current contract
A successful strict build must produce a masterless monolith and a split pair with these properties:
Starwind-Definitive.omwaddon
masters = 0
hard unresolved dependencies = 0
OpenMW dialogue = exact expected effective database
Star_Data.omwaddon
masters = 0
no dependency on Starwind.omwaddon
Starwind.omwaddon
sole master = Star_Data.omwaddon
Star_Data + Starwind
reconstruct Starwind-Definitive exactly
The current corpus validates at 591 DIALs, with no missing/extra live INFOs, no engine-order mismatch, no physical-order mismatch, no serialized-link mismatch, and no dialogue payload mismatch.
Scope of this reference
This documentation intentionally records both the current implementation and the reasoning history that led to it. Old strategies are included when they explain why a current rule exists, but historical behavior is clearly marked so that it is not mistaken for current build policy.
Back to the Starwind Merged Plugin Project