ExpandedLib.Verify 0.3.3

exlib-verify

Checks a Vintage Story mod's shipped assets the way the game would load them, with no game running and no test project. It depends on nothing in this repository beyond the game install it is pointed at.

dotnet tool install --global ExpandedLib.Verify
exlib-verify path/to/mod --game path/to/vintagestory

path/to/mod is a mod folder or a mod zip. --game is any Vintage Story install; the freely downloadable dedicated-server archive is enough, so no game licence is needed. Add --mods <dir> once per other mod that would be loaded alongside yours, so a patch aimed across mods resolves against its real target.

What it checks:

• Patches are replayed exactly as the game's own patch loader would: the same dependsOn and condition filtering, the same file resolution including the * wildcard, applied against the real parsed target. A patch whose target does not exist is an error - unless that target's mod ships an assembly, in which case it may inject the file at load and the finding is informational, because this tool reads only what is on disk.
• Recipe codes resolve to a block or item that exists once every patch has been applied.
• Handbook and lang coverage: a key the assets reference and no locale defines.
• Shape texture codes: every #code a blocktype's or itemtype's shape faces use resolves in the shape's own texture map or the definition's own textures/texturesByType for that variant (all/sides/horizontals/verticals shorthands included) - a block finding is an error, an item finding informational: the client logs this for an item exactly as for a block, but vanilla itself ships this defect (its own metalbit mapping only #ore against game:item/nugget's #granite), so an item finding stays a note rather than failing a mod's run for a defect the mod inherited from the game.

Exit codes: 0 clean, 1 findings, 2 a usage or load failure. --strict makes informational findings count; --json prints the findings as JSON for a CI step to read.

Part of ExpandedLib. MIT licensed.