Five restype numbers in internal/erf disagree with upstream #64
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ShadowsOverWestgate/sow-tools#64
Reference in New Issue
Block a user
Five entries in
internal/erf/erf.go's restype table disagree with upstreamneverwinter.nim'srestype.nim. Found while researching restype handling for NWSync emit (#57); none are in the current asset corpus, so nothing is broken in shipped content today, but they are wrong for HAK writing in general —HAKResourceTypeForExtensionpacks arbitrary source files (internal/pipeline/build.go:870,internal/topdata/top_package.go:441).gfferf.go:100,167)restype.nim:75)bteltrerf.go:120,186)restype.nim:74)bakjpgerf.go:124,190)restype.nim:119)tmlmdberf.go:121,187)xbcdfaerf.go:104,170)dft(restype.nim:83)So a
.jpgpacked into a HAK by Crucible today is written with restype 2076, which the game reads astml.Root cause of why this was never caught: the
init()aterf.go:202-212is meant to keepextensionTypesandtypeExtensionsconsistent, but it only panics when a number is missing from the reverse map — itsif canonicalExt == ext { continue }branch does nothing when the two maps disagree. Fixing the guard is probably worth more than fixing the five values.Separately, Crucible registers six extensions upstream does not have at all —
lyt3000,vis3001,mdx3008,wlk3020,xml3021,gr24003 (erf.go:128-133). Those are deliberate local additions, not bugs, but they are why upstream conformance for NWSync emit mirrors upstream's table rather than this one.Correction to one premise in the description, found while fixing this in #69.
The issue says the six extensions upstream does not have —
lyt3000,vis3001,mdx3008,wlk3020,xml3021,gr24003 — "are deliberate local additions, not bugs". That holds for three of them. The other three are NWN2 formats, the same class of problem asmdb.Checked against xoreos
src/aurora/types.h, which covers every Aurora game and so keeps the games' tables apart:The 20000+ range sits above
kFileTypeMAXArchive, under the heading "Entries for files not found in archives with numerical type IDs". Sowlkandxmlhave no archive restype in any Aurora game: 0x0BCC and 0x0BCD were made up, and they sit in a band Aurora does use elsewhere (3022 FSM, 3023 ART).NWN:EE already covers those jobs with formats in the table:
wok/pwk/dwkfor walkmeshes, and EE's own UI XML loads fromui/ovrrather than from a HAK by restype — consistent with upstream neverwinter.nim (Niv being a Beamdog dev) registering noxmlnumber.lyt/vis/mdxare genuinely deliberate as the description says: real Aurora archive types NWN1 ships in its owndata/*.bif, same numbers in xoreos. Upstream's table just does not list them.Also a small amendment on
mdband the corpus. The description says none of these are in the current asset corpus, which is true of the shipped content, but there are nine.mdbfiles in_contentpool/!GunsPackage/Weapons/— a downloaded NWN2 package, the files starting with the literal magic bytesNWN2. They confirm the diagnosis rather than complicate it: NWN:EE cannot use them at any restype.mdbwas dropped rather than renumbered, since upstream gives 2070 toxbcand there is no correct NWN:EE number to move it to.Net effect in #69: four extensions removed (
mdb,gr2,wlk,xml) instead of one, plus the five number fixes..mdb/.gr2/.wlk/.xmlsources now fail the build with "unsupported extension" instead of packing into a HAK under a number the game misreads.