[Dev 9] Error saving some files with CMS collision

[GammaMetroid]

Attempting to save some files, e.g. meshes\clutter\weaponrack\wrplaqueshield01.nif from vanilla Skyrim, results in this error:

Failed to write block bhkCompressedMeshShapeData (9).

The error did not occur in dev 7.

[W-Drew]

meshes\dungeons\nordic\levers\pullchain\genpullchain01.nif / meshes\dungeons\nordic\levers\pullchain\genpullchain02.nif are also impacted

[Meridiano]

I can confirm this is a real issue for many files. "meshes\landscape\bridges\bridge01.nif" and others. This commit can be related and fix this: UnknownExplorer13@3cb428f. Many thanks to @Candoran2 for his explanation!

[W-Drew]

Looking at that commit, is this a bug in the 0.9.3.0 version of nif.xml where it broke support for compressed mesh shapes, or is it a problem on the consumption side (need to update nifskope to use the new schema)?

[Candoran2]

It's not a bug in the 0.9.3.0 version of the nif xml, just a change - so yes, NifSkope needs to be updated to match it. Most of that has already happened in 1365ca1 . As a result, the display and loading of the bhkCompressedMeshShape seems to go fine. It's only the saving that goes wrong.

[Candoran2]

I think I found the problem. In this line:

nifskope/src/io/nifstream.cpp

Line 640 in a08b0c1

return device->write( (char*)v, 6 ) == 3;

the == 3 needs to be changed to a == 6. That seems to have fixed the problem on my end.

[W-Drew]

That's odd. When I build latest develop, I don't actually encounter this error anymore even though nifstream.cpp does not have the fix @Candoran2 mentioned previously. Saving and re-opening one of the aforementioned files preserves the bhkCompressedMeshShape.

Though, while I don't get the compressed mesh shape save failure, I see on both open/save of genpullchain01.nif / other files.

BSTriShape [16]\Vertex Data [0]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [0]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [1]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [1]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [2]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [2]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [3]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [3]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [4]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [4]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [5]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [5]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [6]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [6]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [7]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [7]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [8]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [8]\Bitangent Z: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [9]\Bitangent Y: Could not convert a value of type Byte (1) to a float.
BSTriShape [16]\Vertex Data [9]\Bitangent Z: Could not convert a value of type Byte (1) to a float.

[Candoran2]

That's odd. When I build latest develop, I don't actually encounter this error anymore even though nifstream.cpp does not have the fix

That'll be because the develop branch doesn't yet have the nif.xml that's used in the release. Copy the one in the release from there into the build folder and compile it again, or copy it into the place where you've put the built NifSkope to get all that recent nif.xml information.

[W-Drew]

Is that just changed outside of source control for the releases? Or are releases building off of some other fork? If outside of source control, are there any other edits needed to get parity with a release build?

[Candoran2]

Is that just changed outside of source control for the releases? Or are releases building off of some other fork? If outside of source control, are there any other edits needed to get parity with a release build?

It's supposed to be edited with the source control, but it's easily forgotten. There's even been cases of edits in the xml that made it into a NifSkope release without ever being in the xml repository, though that's obviously not how it's supposed to happen.

Safest bet for now is just to copy the one from the release. I believe gavrant's fork (the one with the open PR for this fork) actually has it updated already.