When that flag is used, sow-tools: - collects only the assets referenced by that manifest subset - skips full-project chunk planning for the per-archive run - reconstructs just the requested archive chunks from the manifest
sow-tools
Shared NWN build tooling for Shadows Over Westgate.
This repository owns the Go-based sow-toolkit binary used by the separate module and assets repositories.
Build
Build the development binary into tools/sow-toolkit:
./build-tool.sh
Or run directly with Go:
GOCACHE="$PWD/.cache/go-build" go run ./cmd/nwn-tool --help
Repository Layout
cmd/nwn-tool/ CLI entrypoint
internal/app/ command wiring and console UX
internal/erf/ ERF/MOD/HAK reading and writing
internal/gff/ canonical GFF JSON and binary conversion
internal/pipeline/ build, extract, compare, and manifest workflows
internal/project/ config loading and repo scanning
internal/validator/validation and diagnostics
tools/ built development binary output
Intended Consumers
sow-moduleusessow-toolkitforbuild-module,extract,validate,compare, andapply-hak-manifestsow-assetsusessow-toolkitforbuild-haksand validation- validation now fails early if duplicate asset resources would collide inside the same generated HAK
- duplicate resources split across different HAK groups remain warnings because later HAK order can still override earlier content at runtime
sow-modulenow also usessow-toolkitfor topdata:validate-topdatabuild-topdatacompare-topdataconvert-topdata
During development, sibling repositories can point at ../sow-tools/tools/sow-toolkit
or ../sow-tools/tools/sow-toolkit.exe. For pinned releases, each consumer repo can
instead carry its own copy in its local tools/ directory.
Cross-Repository Behavior
The current ownership split is:
sow-tools- owns the shared CLI and build logic
- owns module build, extract, compare, and HAK manifest application logic
- owns topdata validation, build, compare, conversion, and packaging logic
sow-module- owns canonical module source under
src/ - owns canonical topdata authored data under
topdata/ - owns the user-facing module and topdata wrapper commands
- owns canonical module source under
sow-assets- owns canonical binary asset source under
assets/ - owns generated HAK manifests and parts manifests under
staging/ - owns the user-facing asset wrapper commands
- owns canonical binary asset source under
Consumer wrapper resolution is intentionally aligned:
- Prefer a pinned local binary in
tools/ - Else prefer a sibling
../sow-toolscheckout for local source development - Else install the latest published
sow-toolsrelease artifact
NWScript compilation behavior is also aligned:
- Prefer
SOW_NWN_SCRIPT_COMPILERwhen explicitly set - Else prefer a local compiler in
tools/script-compiler/ortools/ - Else use a system-installed
nwn_script_compfromPATH
When the compiler runs, the toolkit prepares NWN_HOME / NWN_USER_DIRECTORY
automatically and tries to detect NWN_ROOT from common Steam locations, including
custom Steam library folders, before an explicit override is required.
Release Automation
This repo publishes:
sow-toolkit-linux-amd64.tar.gzsow-toolkit-windows-amd64.exe
Consumer repos can fetch those binaries into their local tools/ directory with:
install-tool.shon Linux/macOSinstall-tool.ps1on Windows
TopData
The native topdata system is implemented in this repo and authored in sow-module.
High-level ownership split:
sow-tools- owns the
sow-toolkitimplementation - owns topdata validation, build, compare, conversion, and dataset-resolution logic
- owns the
sow-module- owns canonical topdata authored data under
topdata/data/ - owns the user-facing topdata workflow scripts
- owns canonical topdata authored data under
For a human-readable front-to-back explanation of how the native topdata builder works and how to use it, see:
Important topdata contracts still live here under internal/topdata/ because they are
code-adjacent implementation contracts, not user workflow docs.