DynDOLOD 3.00 Alpha 196

[sheson]

55 minutes ago, Vernon said:

Reinstalled ELFX and the warning still appears

The warning means the file does not exist at the shown path in the data folder, which it should after the mod was installed and activated. Sometimes download archives are not complete and there is no error message while unpacking.

[sheson]

46 minutes ago, TechAngel85 said:

Calmwater.dds is from Realistic Water Two and it is a noise level that been placed on the mesh to replace the vanilla normal. SparrowPrince created all the meshes and they've been working well so far.

I don't know of mesh of the top of my head, no. The warnings presents a bit of false perception and has caused one user to ask about it already. I was wondering if you could ignore it, else I expect that is not the last we'll hear of it from users. I suppose I can duplicate the texture to add the '_n' and update the meshes to simply get rid of the warning, but that would be the only reason I'm doing it...to stop DynDOLOD warning about it.

I need some kind of a generic rule why this normal map is OK to not follow the file naming convention. If the texture filename is defined on a record that implies it is a normal map then that could be a way to do that.

[TechAngel85]

18 minutes ago, sheson said:

I need some kind of a generic rule why this normal map is OK to not follow the file naming convention. If the texture filename is defined on a record that implies it is a normal map then that could be a way to do that.

I don't want you to have to design something just for this because we're doing something out of the ordinary. I thought there might be something already in place. We can easy just update it to typical naming convention. Though, this does bring into question dealing with false positives, because there is nothing preventing anyone from doing this. As far as I can tell, it's just a naming convention that has been established and followed for normal maps, however, there doesn't seem to be anything preventing not using the '_n' (as it clearly works just fine and is used in vanilla for water normals (noise layer)). I'm sure there are other mods out there that have done this, but that list is likely short.

[Vernon]

34 minutes ago, sheson said:

The warning means the file does not exist at the shown path in the data folder, which it should after the mod was installed and activated. Sometimes download archives are not complete and there is no error message while unpacking.

Ok thanks, cheers

[sheson]

1 hour ago, TechAngel85 said:

I don't want you to have to design something just for this because we're doing something out of the ordinary. I thought there might be something already in place. We can easy just update it to typical naming convention. Though, this does bring into question dealing with false positives, because there is nothing preventing anyone from doing this. As far as I can tell, it's just a naming convention that has been established and followed for normal maps, however, there doesn't seem to be anything preventing not using the '_n' (as it clearly works just fine and is used in vanilla for water normals (noise layer)). I'm sure there are other mods out there that have done this, but that list is likely short.

It is not a false positive unless there are vanilla NIF that use a vanilla normal map texture that do not use *_n.dds in the normal map slot. Bethesda seems to stick 100% to their file naming convention. I have not come across an exception yet.

The reason that the check was added are NIFs from mods that have copy paste errors of the diffuse filename to the normal map slot.
Textures can have any filename you want, but sticking to conventions makes Cathedral modding, patches and programming tools a lot easier.

Be that all as it may, getting the texture names from the WATR noise entries, which are required to be normal map textures, is a good and future proof way to programmatically allow exceptions. It is implemented in minutes. So next version should not report calmwater.dds anymore since it is defined on WATR records and thus guaranteed to be a valid normal map.

[TechAngel85]

3 hours ago, sheson said:

Be that all as it may, getting the texture names from the WATR noise entries, which are required to be normal map textures, is a good and future proof way to programmatically allow exceptions. It is implemented in minutes. So next version should not report calmwater.dds anymore since it is defined on WATR records and thus guaranteed to be a valid normal map.

That's good news! Sounds like a reasonable solution.

[xytyyy]

Just found a soft conflict when it comes with the pre-3.0 Better Dynamic Snow mod and the parallax meshes.

For instance, in the DynDOLOD.esm the WHmarket02[3839F] get replaced by the WHmarket02_DynDOLOD_NOFLAG.

When one has installed the BDS2.11 and a corresponding parallax mesh for that object, it works well, because BDS2.11 has modified the direction material to its own one.

When the object get replaced by the the DynDOLOD, the BDS modification get nullifyed, because the WHmarket02_DynDOLOD_NOFLAG copies the vanilla direction material, which doesnt work with a parallax mesh. after activating DynDOLOD, the object in game becomes texture-less.

this problem can be solved manually by making a compatibility patch of DynDOLOD and BDS by reproducing BDS modifications to WHmarket02 on the new WHmarket02_DynDOLOD_NOFLAG. The in game effect works perfectly.

I dont know if it is posible to make a xedit script to automize this kind of process, but anyway i report it here.

[sheson]

5 hours ago, xytyyy said:

Just found a soft conflict when it comes with the pre-3.0 Better Dynamic Snow mod and the parallax meshes.

For instance, in the DynDOLOD.esm the WHmarket02[3839F] get replaced by the WHmarket02_DynDOLOD_NOFLAG.

When one has installed the BDS2.11 and a corresponding parallax mesh for that object, it works well, because BDS2.11 has modified the direction material to its own one.

When the object get replaced by the the DynDOLOD, the BDS modification get nullifyed, because the WHmarket02_DynDOLOD_NOFLAG copies the vanilla direction material, which doesnt work with a parallax mesh. after activating DynDOLOD, the object in game becomes texture-less.

this problem can be solved manually by making a compatibility patch of DynDOLOD and BDS by reproducing BDS modifications to WHmarket02 on the new WHmarket02_DynDOLOD_NOFLAG. The in game effect works perfectly.

I dont know if it is posible to make a xedit script to automize this kind of process, but anyway i report it here.

https://dyndolod.info/Updating
"If a plugin is added or updated it is possible that there are new conflicts which require solving. This can either be manual conflict resolution or updating or generating LOD from scratch."

The LOD mod is a snap shot of the load order at generation time. The DynDOLOD and Occlusion plugins are patch plugins created by copying existing records and data. If the load order changes, generate the LOD mod for the new load order. DynDOLOD *is* the xEdit script to create/update its patches.

[xytyyy]

1 hour ago, sheson said:

https://dyndolod.info/Updating
"If a plugin is added or updated it is possible that there are new conflicts which require solving. This can either be manual conflict resolution or updating or generating LOD from scratch."

The LOD mod is a snap shot of the load order at generation time. The DynDOLOD and Occlusion plugins are patch plugins created by copying existing records and data. If the load order changes, generate the LOD mod for the new load order. DynDOLOD *is* the xEdit script to create/update its patches.

I reported it because it is not a updating issue, but a persistent problem which didn't get solved by generating new dyndolod data.

[sheson]

1 hour ago, xytyyy said:

I reported it because it is not a updating issue, but a persistent problem which didn't get solved by generating new dyndolod data.

Read the first post which log and debug log to upload when making reports so I can try to reproduce the problem.

[xytyyy]

https://ufile.io/f/orpg5 Here are the logs.

1 hour ago, sheson said:

Read the first post which log and debug log to upload when making reports so I can try to reproduce the problem.

 

[sheson]

4 hours ago, xytyyy said:

https://ufile.io/f/orpg5 Here are the logs.

Thanks, this helps. The issue should be fixed next version.

[ignotus_patronus]

Hi, I've tried searching for this to no avail. I have multiple new worldspaces added to my Skyrim. I generated a DynDOLOD Output using the 2.0.0 guide after about 45 minutes. I recently added LOTD to the Tamriel Worldspace. For updating DynDOLOD, can I just select the Tamriel Worldspace? Will this overwrite all of my other worldspaces or only the Tamriel Worldspace?

[sheson]

2 hours ago, ignotus_patronus said:

Hi, I've tried searching for this to no avail. I have multiple new worldspaces added to my Skyrim. I generated a DynDOLOD Output using the 2.0.0 guide after about 45 minutes. I recently added LOTD to the Tamriel Worldspace. For updating DynDOLOD, can I just select the Tamriel Worldspace? Will this overwrite all of my other worldspaces or only the Tamriel Worldspace?

See https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins

[ignotus_patronus]

6 hours ago, sheson said:

See https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins

Thank you! I will see if I can figure it out.