FO4/76 official file problems

[Capostrophic]

A bunch of minor things I noticed while batch-testing OpenMW's NIF parser on official files a while earlier. OpenMW's parser is not directly based on nifly, but I used nifly and NifTools XML as references.

• meshes/actors/mirelurk/ls_mirelurk.nif in the main meshes archive of FO4 uses stream version 132 and I'm pretty sure it'll fail to be parsed correctly by nifly because nifly erroneously skips backlight power in BSLightingShaderProperty for that version. I don't know what the precise version range is, but I haven't stumbled into any problems with official files after simply omitting the 130 version check, i.e. use [130, 139] range like NifTools. Granted 131-139 stream version is rare.
• 3 meshes in SeventySix - Meshes.ba2 contain a block type that seems presently unknown to both nif.xml and nifly, NiPSysRotDampeningCtlr. These are the following: meshes/actors/ultraciteabomination/ultracite_fissure_entrance_vfx.nif, meshes/actors/ultraciteabomination/ultracite_shockwave_attack.nif, meshes/actors/ultraciteabomination/ultracite_shockwave_attack_(d11).nif. I haven't researched these myself, but it sounds feasible that rotation dampening is relevant to the unknown part of 76's version of NiPSysRotationModifier.
• There's something sus about triangle data in meshes/scol/seventysix.esm/cm003f16ba.nif in SeventySix - StaticMeshes.ba2, but I can't quite put my finger on what it is. NifTools and OpenMW can't handle it in any case. Any potential insight would be appreciated.

I don't remember offhand if there are any other problems with nifly's parsing of files from these games, though on NifTools side 76 support has been mostly broken for a while due to an oversight or two in Starfield-relevant changes.

[ousnius]

@Capostrophic Thanks for the issue. The specific Mirelurk file with version 132 should work in nifly as there is a test for it: https://github.com/ousnius/nifly/blob/main/tests/input/TestNifFile_Static_FO4_132.nif

That doesn't mean the condition is correct, though. I'll check the rest in detail in the coming days when I'm home.

[ousnius]

@Capostrophic I fixed the conditions for the stream 132 and 139 files. with 9aa5dd3. The files were fully read and written, but float values ended up in the wrong members in nifly. The conditions now match the nif.xml.

As for the FO76 files, I haven't modded the game personally and only carried over the decoding from other tools/people. I'm installing the game to check out of curiosity, but other people are probably more fit to help with decoding here.

[ousnius]

@Capostrophic I made some fixes with commits ad75c4a and c9b2e7f, the latter of which fixes the issue with for example cm003f16ba.nif.

[ousnius]

The following are the still unknown block types to nifly with one example file for each after scanning ALL .nif and .bto files of FO76 as of September 15, 2024:

• NiExtraData (FO76 meshes\actors\character\characterassets\morphs\basemale.nif) (not abstract?)
• NiPSysRotDampeningCtlr (FO76 meshes\actors\ultraciteabomination\ultracite_fissure_entrance_vfx.nif)
• BSCollisionQueryProxyExtraData (FO76 meshes\setdressing\workshop\vendingmachines\workshopplayervendingmachine01.nif)
• BSDistantObjectExtraData (FO76 meshes\terrain\appalachia\objects\appalachia.16.-110.-29.bto)
• BSDistantObjectInstancedNode (FO76 meshes\terrain\appalachia\objects\appalachia.16.-110.-29.bto)

All NIF files in FO76 use stream version 155.

[ousnius]

See #47

[Capostrophic]

Very nice. I should note that in files up to 4.2.2.0 non-abstract NiExtraData respects its own record size field and can seemingly store binary extra data on the record, but I guess nifly doesn't target NIFs that old.