sheson

Oh yeah, CK is the one that ignores the ESL flag when editing plugins, meaning it happily creates new form IDs outside the allowed limits. Odd that this resulted in an assertion error and not the invalid object ID error message.

Note that xEdit often continues to load despite a plugin having problems so that it can still be worked on and fixed. Pay attention to the log messages. See if loading/saving plugin in CK makes a difference. Since DynDOLOD is based on the 4.1.4 experimental, test with that if possible. Otherwise send me link in a PM.

Check what happens if you load the load order in xEdit 4.0.4. If hat works, see what happens with xEdit_4.1.4b_EXTREMELY_EXPERIMENTAL from the xEdit discord #xedit-builds. What mod is Ayleid Aquarium.esp from?

https://dyndolod.info/Help/Object-LOD LOD generation with CK/xLODGen/DynDOLOD uses models to create combined supermeshes, e.g. object LOD. https://dyndolod.info/Help/Mesh-Mask-Reference-Rules "VWD - Visible When Distant - apply rule only if a matching LOD model exist" "The rule is only applied if a matching LOD model is found. If no matching LOD model exists the rule is ignored." That means, if no LOD model exists, do not check the VWD flag if you want the rule to apply.

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

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

Just do the usual clean save updating procedure like you would when generating from scratch. To verify if the generated output has an effect on something, test without it.

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

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.

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.

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.

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.

Calmwater.dds is not a vanilla texture? The vanilla fxcreekflatlarge.nif defines textures\effects\FXwaterTile02_n.dds for that shape which happens to follow the naming convention. Can you provide an example of a vanilla NIF that defines a vanilla normal map texture that does not end in *_n.dds? At the moment the check has no exceptions for any vanilla NIF / normal map textures other than grass NIF. Since the grass shader does not use/support the normalmap textures, the normalmap texture file name is irrelevant. All other vanilla NIFs/normal map textures that are being checked follow the naming convention. So atm I have no evidence or example for why/how to add an exception. Edit: Is this a water noise layer1/2/3 texture that you also repurposed to be used in NIFs?

The vanilla fxcreekflatlarge.nif defines textures\effects\FXwaterTile02_n.dds for that shape which happens to follow the naming convention? Can you provide an example of a vanilla normal map texture used by a vanilla NIF that does not end in *_n.dds?

Thanks! It seems the item not found is caused because a mesh is missing. [20:06] <Warning: File not found Meshes\effects\elfx\mountains\elfxmountainpeak02.nif Skyrim.esm MountainPeak02_Blackreach [STAT:000487E7]> You may want to reinstall Enhanced Lights and FX. Next version should not fail with an item not found error and only print the warning message and continue.

DynDOLOD generates tree and object LOD. DynDOLOD does not generate water LOD. Water LOD is part of terrain LOD meshes. DynDOLOD does not change water in active cells. What is the connection of the problem to DynDOLOD? If removing DynDOLOD or Occlusion plugin makes any difference, it means the plugins were generated for a different load order. Generate anew for the current load order. eFPS is a mod that adds occlusion planes or boxes as reference that only load in active cells. It has zero overlap with LOD or occlusion generation. If removing eFPS makes a difference you are probably missing a patch. Why do you mention it?

What does that mean you dealt with the issue? You can not fix problems in the code. Please upload the log and debug matching the bugreport.txt uploaded earlier or provide information how to reproduce the error. Always use the latest version. Pay attention to all log message and the summary. Especially the ones about "Texture resolution ... not a power of 2". From the log: <Warning: Texture resolution 256x171 not a power of 2 Texture textures\rbroriksteadtextures\planks_lod.dds Used by meshes\rbroriksteadmeshes\woodentowerrorikstead03lod.nif RedBag's Rorikstead.esp 000WoodenTowerRBRorikstead [STAT:460012CE]> It's known since a long time. See bug reports/comments on mod page.

Zip the log and debug log and upload them to a file service as explained on the first post.

See the first post of the DynDOLOD 3 Alpha thread where to make posts. I moved the post. Post the log and debug log as explained on the first post.

This version should work as expected.

Unless you play Skyrim on a vertical 4k monitor setting such resolutions for the texture does not make much sense. See https://dyndolod.info/Help/Texture-Resolution If the system also has a dedicated graphics card, make it the primary/default one.

That's a bug. Can you check if this also happens with the LODGen.exe from xLODGen terrain LOD beta 90? TexGen does not generate _3.dds billboards. It generate 2 billboards, a front view _1.dds and a 90 degree side view _2.dds if HD billboards is selected.

Unfortuanately the debug log seems incomplete. The actual error message returned by Texconv from the log: "FAILED [compress] (887A0005: The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action.)" There seems to be a problem with the graphics card. Update to latest drivers. Disable overclocking if used. Maybe disable power saving. There probably is an Windows event log entry from the graphics driver that might shed more light on the cause. If that does not help, try setting MaxTextureSize=8192 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini What settings did you use when generating textures with TexGen? What max texture size settings did you use in DynDOLOD?

2. *_1.dds is used for billboard_1.dds and billboard_3.dds, because 1) it matches the number and 2) is used as default if there is no match. *_2.dds is used for billboard_2.dds because it matches. Also see https://dyndolod.info/Help/Ultra-Tree-LOD#Internal-Billboards-and-External-Billboards, though it may not be as specific. Object LOD always uses normal maps. If a normal map texture does not exist, the default flat normal is used as a substitute. Have you installed 3rd party LOD models for any of the waterfalls? Do not do that. See https://dyndolod.info/Mods/Waterfalls If the problem persists, open console and click the waterfall to get the reference form id of the waterfalls to see which plugin is placing them. Look it up in xEdit to find the base record and NIF or use More Informative Console, to find out which plugins and mods are involved. The flickering could mean there is more than one model active. You could test that by disabling the clicked object via console. If any of the reference are from a DynDLOD plugin and the screenshots show active cells, this could mean the clean save routine went wrong. https://dyndolod.info/Help/Clean-Save Also see https://dyndolod.info/FAQ "Out of place or floating objects" Post the log, debug log as explained on first post and use https://modwat.ch to upload load orders instead of screenshots.

1. DynDOLOD_flat_3x2_lod.nif defines 3 textures for each plane. LODGen replaces them with the corresponding object LOD atlas texture paths. 2. If HD billboards are selected, TexGen generates a *_1.dds front and a 90 degree (right I think) side view _2.dds diffuse and normal map. LODGen does not care what the arrangement and orientation of vertex data and triangles in NIFs is. 3. We have thoroughly discussed this before. It works. It is bad. Do not use this for the users and cathedral modding sake. https://dyndolod.info/Help/3D-Tree-LOD-Model "As a last ditch effort before using the billboard as fallback, DynDOLOD checks if there is an object LOD model with the typical filename convention of full model filename_LOD_[0|1|2].nif as usual for object LOD. This should only be used by properly made mods that use new unique filenames for every changed full model or texture and use new or updated base records to use the new assets to avoid conflicts. As soon as there are different variants (even through updates or patches) for the same full model filename, use the preferred CRC32 matching to guarantee the correct LOD model is used every time regardless of a user's load order since users like to mix lots of different mods or different versions of mods and their assets all the time." 4. If I do not find Billboard4 in LOD Level 4 being good enough, one more plane is not going to much better, hence 3D hybrid tree LOD for LOD Level 4.