search

hexabits / nifskope

Other
245 stars 54 forks source link

NifSkope Not linking BSShaderTextureSet to respective BSLightingShaderProperty on Load #78

Open StarFluxGames opened 4 months ago

StarFluxGames commented 4 months ago

image image image

When opening a .nif from Fallout76 in NifSkope and saving the .nif without making any adjustments, it seems to be changing a byte of data towards the end of the file from a 01 to a 02 or a 03, this seems to be causing issues with collisions in the game where props can no longer be interacted with.

StarFluxGames commented 4 months ago

^ I will also note, It also seems to add on 07 00 00 00 at the end, with the 07 being different each time, but that doesn't seem to cause any issues.

StarFluxGames commented 4 months ago

After chatting to some people on Discord, we've found that NifSkope is in-fact loading the .nif files wrong, and not correctly linking BSShaderTextureSet to its respective BSLightingShaderProperty when loading.

image image

fo76utils commented 4 months ago

The BSShaderTextureSet blocks are really not linked in the NIF, because if a material file is being used, the BSLightingShaderProperty block is cut short after the controller field, and it is typically only 12 bytes long. Therefore, it does not contain the link to the BSShaderTextureSet either, which is not actually used in these cases, but the (unused) block is still stored in the NIF file.

The problem with the saved files is caused by the dangling shader texture sets being incorrectly added to the footer as root links.

This commit to my NifSkope fork fixes the root links, and if the block before the BSShaderTextureSet is a BSLightingShaderProperty, then it also tries to link the former as a child of the latter. There is a build with these changes here.

StarFluxGames commented 4 months ago

The BSShaderTextureSet blocks are really not linked in the NIF, because if a material file is being used, the BSLightingShaderProperty block is cut short after the controller field, and it is typically only 12 bytes long. Therefore, it does not contain the link to the BSShaderTextureSet either, which is not actually used in these cases, but the (unused) block is still stored in the NIF file.

The problem with the saved files is caused by the dangling shader texture sets being incorrectly added to the footer as root links.

This commit to my NifSkope fork fixes the root links, and if the block before the BSShaderTextureSet is a BSLightingShaderProperty, then it also tries to link the former as a child of the latter. There is a build with these changes here.

Thanks for looking into that. It seems like your fork doesn't load materials correctly on my end. image

fo76utils commented 4 months ago

This issue is most likely caused by the archives not being correctly loaded, I would check the resource settings, and make sure that Fallout 76 is enabled and that the data path (the "Data" folder where SeventySix.esm is located) is added under Paths. Also check that shaders are enabled in the render settings, and that the Fallout 76 environment map path is valid (it defaults to textures/shared/cubemaps/mipblur_defaultoutside1.dds).

If everything is configured correctly, then it may also be an OpenGL compatibility issue.

StarFluxGames commented 4 months ago

This issue is most likely caused by the archives not being correctly loaded, I would check the resource settings, and make sure that Fallout 76 is enabled and that the data path (the "Data" folder where SeventySix.esm is located) is added under Paths. Also check that shaders are enabled in the render settings, and that the Fallout 76 environment map path is valid (it defaults to textures/shared/cubemaps/mipblur_defaultoutside1.dds).

If everything is configured correctly, then it may also be an OpenGL compatibility issue.

image image

All seems to be fine in terms of the settings, I will note this issue doesn't occur on the latest hexabits release.

Ignore me, it wasn't added in the Paths tab, only Games.