Updates to nif.xml based on NifSkope dev8 nif.xml

Changes to spec

Default `type` attribute to `onlyT`

For easier parsing, the type attribute of the <default> tag was changed to onlyT. The type attribute in default tags means that the associated value only applies when the struct or niobject it's in is that type. The onlyT attribute on field tags takes a similar place, meaning the field only exists when the struct or niobject it's in is that type. The change was made to unify this (the type attribute in fields is already used).

Addition of the `<verattr>` tag.

The verattr tag is introduced to make it easier for codegen to link the attributes of versions to global variables (like those used by the vercond attribute). Essentially, it functions like token replacement specifically for attribute names of the version tag. It can also be used to specify priority between the different attributes that define a version number, in order to more robustly define the ordering of version IDs. Example:

<verattr name="num" access="Version" index="0" />
<verattr name="user" access="User Version" index="1" />
<verattr name="bsver" access="BS Header\BS Version" index="2" />

<version id="V20_2_0_7__11_3" num="20.2.0.7" user="11" bsver="21">Fallout 3, Fallout NV</version>

The name attribute of the verattr tag corresponds to the attribute name in the version tag. This should not use any of the predefined attributes (id, supported, custom or ext). The access attribute defines the associated global variable (using the same definitions as the vercond attribute). The index attribute defines the priority of each verattr token. These should start at 0 and each index should only be used once. The lower the index, the more significant the version attribute. So in the example, a version with a higher num attribute than another version, is always later than that other version, regardless of any other version attributes.

In the cobra-tools repository some verattr tags also got the type= attribute, which was necessary because otherwise there was no way to know if it was a bitfield or not (and hence how to do assignment). The default is interpretation as versions/integers, so in nif.xml it was not necessary.

Changes originating from NifSkope dev8

The ver1 and ver2 attributes were renamed to until and since, respectively. This was already done on most tags, but not yet on <field> tags.
The <compound> tag was renamed to <struct>.
The arr1 and arr2 attributes were renamed to length and width, respectively.

Other NifSkope dev8 changes

Compounds (now structs) were organized into modules.
Additions of some new version tokens.
Addition of stopcond attribute to BSLightingShaderProperty and BSEffectShaderProperty (not sure what this is for or what it is supposed to do).
Addition of two FO76-specific structs.

Changes to BSInvMarker

Changed default values to reflect how they are when the BSInvMarker block is missing (0 for all rotations).\

Identifications of unknown material values.

I have identified a number of previously unidentified Skyrim Havok Material values. This was done via the following process:

Give all materials the WPNArrowBounceImpact in the WPNzArrowImpactSet.
Test suspected unmapped materials in a test nif by shooting at it with a bow.
If the arrow bounced or stuck, it means that there is an associated material in-game.
Check which material it is by changing the 'arrows stick' flag on the material. Skip already mapped materials and ones that don't match the observed behaviour. Most were relatively easy by which mesh they appeared in.

Any option that was left unmatched did not have a response. I think these materials are not actually used in-game, or at least not in the traditional way. Some may have some other function (I suspect 1574477864 and 1591009235, since they appear with relative consistency in creature skeletons under the character controller) and some may just be mistakes (I suspect 2290050264, since there are vanilla objects with that like the sabre cat pelt. It simply has no sound when colliding at all). The value for any given material is obtained via a hash of the lower case material name, using this hash (also used in Fallout 4 for material and ba2, thank you zilav for pointing that out). In python this can be easily replicated using the following code:

binascii.crc32(bytes(material_name.lower(), 'utf-8'), 0xFFFFFFFF) ^ 0xFFFFFFFF

Changes to bhkCMSChunk

Use of UshortVector3 in the Vertices field instead of single values and explanation of how those values are calculated.
Addition of small doc string to Indices field.
Addition of small doc string to Strips field.
Change of "Welding Info" field to better show what is stored there.

A detailed explanation follows below. An example mesh to study would be genkitrmwall01.nif, or farmhous01walkway.nif.

Use of UshortVector3 in the Vertices field.

Previously, the vertices field was regarded as one array of ushorts. However, these numbers are actually associated per vertex, like so:

Vertex0 X
Vertex0 Y
Vertex0 Z
Vertex1 X
Vertex2 Y
etc...

This stores the havok coordinates for each vertex. However, they are still ushorts, rather than floats (or hfloats). The values, however, are actually the havok coordinate*1000, giving some measure of precision. Negative coordinates are not needed: the lowest X, Y and Z are alway 0, and the translation entry in the chunk itself gives allows for the final position to be negative.

Doc string in indices and strips field

The strips field defines strips of vertices within the indices field. Let an example be the following: indices field: [7, 4, 6, 5, 15, 11, 14, 10, 17, 16, 6] strips field: [4, 4] This defines strips [7, 4, 6, 5] and [15, 11, 14, 10], with the numbers referring to the vertex index in the vertices array. The single-triangle at the end ([17, 16, 6]) is not included in the strips field (there can be multiple of these, each taking three entries). In the example above, the resulting triangles would be:

[7, 4, 6], [4, 6, 5]
[15, 11, 14], [11, 14, 10]
[17, 16, 6]

Here, even-index triangles (starting from index 0 within every strip) are defined counterclockwise and odd-index triangles are defined clockwise.

Changes to welding info field

This is the most difficult to decode, and there are still some mysteries remaining. However, I believe the most important parts are here.

Welding info is always as long as the indices field. This way, one entry in welding info is associated with one entry in the indices field. Each entry in welding info contains information about the edges of the triangle which is defined by the associated indices entry and the two following entries. This means there are some welding info fields which contain information for non-existing triangles. So in the example above, the welding info would look like this:

Welding info for triangle [7, 4, 6]
Welding info for triangle [4, 6, 5]
Welding info for nonexistent triangle
Welding info for nonexistent triangle
Welding info for triangle [15, 11, 14]
Welding info for triangle [11, 14, 10]
Welding info for nonexistent triangle
Welding info for nonexistent triangle
Welding info for [17, 16, 6]
Welding info for nonexistent triangle
Welding info for nonexistent triangle

The welding info for nonexistent triangles is often the same as the indices entry it is associated with, but I think they are entirely inconsequential entries. The welding info for existent triangles is formatted as follows (expressed in bits): 0 xxxxx xxxxx xxxxx Here, each group of 5 bits contains the exterior angle that an edge of the triangle makes with another triangle, measured as shown below. Edges without an other adjacent triangle are considered to have an angle of 180. Illustration of how to measure the exterior angle. Blue arrows show the normal facing direction of a triangle This mapping of course isn't perfectly smooth, because there are only 5 bits to store this information in. The association of various exterior angles with the decimal representation of the welding info for that edge is shown below, with an included trendline. The best approximation that I have found so far for a function that matches exterior angle to the outputted value is as follows :

edge_weld_info = 15 + int((degrees - 180) * 15 / 180)

While this function does not exactly match all the data points I have, the uncertainty is, from some experimentation, close enough to be due to precision limits.

The way in which these angles are associated with the edge is as follows: If the triangle is even-index in the strip (counterclockwise), reverse the vertex indices. Otherwise, leave them as they are. The weld information is now in the same order as the vertex indices. The weld information for an edge is associated with the vertex that edge goes to. For a more concrete example: Let's consider the indices above, looking only at the first strip ([7, 4, 6, 5]). This has two triangles. Let's consider the situation where they make a 270° exterior (90° interior) angle with each other, as shown below, and all the other edges are unconnected or connected at 180° to another triangle, except that edge 5-6 also makes a similar angle with another triangle. The following weld information would then be associated with that strip:

0 01111 10110 01111 (or 0 15 22 15, i.e. flat, 270°, flat)
0 01111 10110 10110 (or 0 15 22 22, i.e. flat, 270°, 270°)
Weld information for nonexistent triangle (could be ushort(6))
Weld information for nonexistent triangle (could be ushort(5))

[7, 4, 6] is reversed to become [6, 4, 7], so: [7-6 is flat, 6-4 is 270°, 4-7 is 270°] And the other triangle remains [4, 6, 5], so [5-4 is flat, 4-6 is 270°, 6-5 is flat]

niftools / nifxml