sheson

The screenshot shows the base record. If you click an object with console open, the game shows the reference form id. If you use more informative console, that is the number behind Ref form ID. It is most likly 0005D2BE. Look that one up. From the screenshot it seems only Open Cities Skyrim.esp changes it, which is what we would expect. If not other plugin overwrites it after open Cities Skyrim.esp, then try this: Deactivate DynDOLOD mod in the mod manager. Start DynDOLOD as you would for the second pass with Open Cities and patches. Click one of the Low, Medium, High preset buttons to update the rules. Select rest of options as before and generate, then merge this new output with the existing output, overwrite all older files.

If the building shows with only the DynDOLOD plugins deactivated, open console to get its reference form id. Load the load order without DynDOLOD plugins into xEdit, to check which is the last plugin to overwrite it. I need to know which plugin adds/modifies the reference that goes missing.

If there are problems following third party instructions, I suggest to ask their author or on their comments/forum section. It is unclear what the 3rd party instructions were. For object LOD generation, read the description of FNVLODGen For terrain LOD generation, read the included Terrain-LOD-Readme.txt. Ask specific questions if necessary. Do not change the default texture compression/format settings. ALWAYS set a dedicated output folder with -o command line as explained in the description/readme. Install output as a mod with the mod manager. Make sure nothing overwrites any of the generated files. If there are problems check the FNVLODGen_log.txt logfile for errors and warnings. Upload the file if additional help is required.

Read the first post which log and debug log to upload when making posts. Follow the instructions how to properly generate LOD for Open Cities at https://dyndolod.info/Mods/Open-Cities-Skyrim If the building shows with only the DynDOLOD plugins deactivated, open console to get its reference form id. Check in xEdit which is the last plugin to overwrite it.

BSOD, PC freezing, crashing are a hardware, cooling, overclocking, BIOS settings, OS, driver problem.

It is probably a race condition. See if it still happens with the next alpha version. https://dyndolod.info/FAQ "Out of place or floating objects" Test with new game. If the problem goes away, the updating of an existing save game with old DynDOLOD plugins went wrong or maybe there was script lag. If it happens with a new game, upload log and debug log as explained on the first post. Look up the Ref(erence) form id in xEdit, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this reference originates.

Taking Your Firstborn = the second DynDOLODx64.exe that didn't close cleanly after access violation. Usually all file handles are already closed in that state so it can not interfere with anything anymore.

In case a second DynDOLOD is still running (even hidden in task manager because it did not shutdown cleanly because of a access violation) it should only cause file access errors like a file can not be used/read/written because another process already uses it.

Typically Simplygon fills the transparent parts of the textures with the average of the surrounding opaque pixels, so I am not sure why the textures go black for the aeras. Black/White borders around edges with alpha (and pre-multiplied alpha) and alpha blending etc. is a complex topic. Theoretically it should be possible to use GIMP or Photoshop to do something about the edges but I wouldn't know of the top of mu head. I'd rather make these things are right at creation time, e.g when TexGen renders billboards,which doesn't help you here...

Upload the log and debug log as explained on the first post. It sounds you have a problem with the LOD assets included with the mod / Skyrim3dTress and Plants 3dLOD Resources. If the LOD textures shipping with the mod are shrunk when they are added to the object LOD atlas, raise the "max tile size LOD" under the object LOD checkbox to their native resolution. The textures (and 3D tree LOD models) of Skyrim3dTress and Plants 3dLOD Resources are made with an advanced feature of Simplygon. If the resolution of the textures are not changed, than there is not really anything else the tools can do about them since they can only be used as is. Also see https://dyndolod.info/Help/Texture-Resolution. The tests with the single color mipmap may help to determine if the textures would benefit from a larger resolution, though the onyl way to achieve that would be to create the LOD models and larger textures with Simplygon. I suggested to use Simplygon to the author, because the crowns are very detailed and the simple hybrid tree LOD creation is not sufficiently reducing the complexity.

No need to remove the entire mod permanently. Just remove this swap in case the large reference bug is visible in the affected cells. Is this repeatable?

I suggest to read all log message listed in the summary and their explanations. https://dyndolod.info/Messages/Base-Record-Type-Not-STAT-or-MSTT-For-Large-Reference "The most likely cause is a plugin changing the reference to use a different base record. This can also be caused by base record swapping, maybe also for seasons." https://dyndolod.info/Mods/Base-Object-Swapper Large reference bugs are triggered if the new base record type is changed from STAT or MSTT (a warning message Base Record Type Not STAT or MSTT For Large Reference is written to the message log) or in case the volume of the objects bounds of the new base record is smaller than the required minimum (this is automatically fixed by DynDOLOD). The debug log should list the swap for the original base record when the swap/season INI is loaded.

If a line in an INI file does not exist just add it.

If a program is terminated like that, it is not a simple error problem caused my mods. If there is not even a crash log recorded in the Windows Event log, then the OS/3rd party/driver/hardware issue seems likely. Especially if it happens at different times in the process. Set realtimelog=1 in the DynDOLOD_SSE.ini, then check the debug log it has written to see how far it got. If it is at time of high CPU in DynDOLOD + LODGens (open task manager to see CPU and memory usage), make sure cooling is sufficient, BIOS settings for CPU and memory are correct. Maybe test high load with the usual programs (Prime95 for example.)

Check the Windows Event log.

Read the first post, which entire log and debug log to upload when making posts. https://dyndolod.info/Messages/Base-Record-Type-Not-STAT-or-MSTT-For-Large-Reference

https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards "Whenever TexGen is used to generate tree/grass LOD billboards, it will also create text files ..\textures\terrain\lodgen\TexGen_[GAME MODE]_[Tree|Grass]_Billboards.txt which contain a list of all trees or grasses, regardless of any settings or failures. If the line ends in ',False' it means this tree or grass billboard was filtered out." The changelog entry "TexGen.exe - fixed trimming opposite edge of billboard textures" from Alpha-87 is most likely what fixed it.

Lets assume for now that those grass LOD billboards missing is why you see less grass LOD being generated in the BTO. Compare TexGen output ..\textures\terrain\lodgen\TexGen_SSE_Grass_Billboards.txt of the two versions. We would expect the same grass LOD billboards to be missing. Then generate TexGen output with Alpha-87, see if they are still missing or not.

Compare if content/number of grass LOD billboards in ..\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt is the same. Grass cache stayed the same when generating with the two versions?

Compare file size of some LOD level 4 BTO between the versions at same density setting to see if they are closely the same. Compare if content/number of grass LOD billboards in ..\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt is the same.

You can see that the full grass does not render to the edge of the active cells, which it usually does with when NGIO is active and the config it uses sets DynDOLODGrassMode=1. If you set DynDOLODGrassMode=2, it should even render beyond the active cells, provided uLargeRefLODGridSize is greater than 5. If editing the files does not change anything, then either NGIO is not running, the file can not be read or parsed for some reason or the the file it is reading is not being changed. If the config define DynDOLODGrassMode=0 (or the mode is not set for whatever reason), then setting ExtendGrassDistance = True, ExtendGrassCount = True and keep increasing OverwriteGrassDistance you would expect to see the full grass distance to increase as well, but in a circle around player. Check the .Net Framework ..\NetScriptFramework\NetScriptFramework.log.txt that the GrassControl.dll is loaded. I am not aware of NGIO itself writing to a log. Whatever keeps the full grass render distance low has nothing to do with the LOD or DynDOLOD. You might want to ask on the mods comments.

Grass LOD is generated to object LOD Level 4. Make sure the LOD distances for the different LOD levels do not set lower values for higher levels. E.g. the max distance for LOD level 8 needs to be further than the max distance for LOD level 4. https://dyndolod.info/Help/Object-LOD#Settings When in the game, open console, type tll to toggle LOD off. If grass LOD was generated with mode 1, you will see that it reached to the active cells border. If grass LOD starts a couple cells further out it was generated with mode 2. https://dyndolod.info/How-LOD-Works NGIO is responsible for rendering the full grass to either of the two desired distances with the corresponding DynDOLODGrassMode setting in GrassControl.config.txt. Make sure to edit the right GrassControl.config.txt file which is actually used by NGIO. Restore default GrassControl.config.txt and only change DynDOLODGrassMode. Make sure the file can be can be read by the game/NGIO. Make sure NGIO actually runs.

Post the log, debug log as explained on first post and the GrassControl.config.txt. Read https://dyndolod.info/Help/Grass-LOD. Grass LOD generated with mode 1 requires DynDOLODGrassMode=1 in GrassControl.config.txt. Grass LOD generated with mode 2 requires DynDOLODGrassMode=2 in GrassControl.config.txt.

I compared Alpha 65 and the new Alpha 86 and have identical file sizes for Tamriel.4.*.*.bto at grass LOD density 25%.

https://dyndolod.info/Messages/Plugin-Limit Plugins can only have have 255 masters. There is no other solution than to reduce the number of plugins that are required as masters. See the first post which debug log and bugreport.txt (if it exists) to upload. If this happens with Occlusion generation enabled, do not check it. Install output and then start DynDOLOD and only select Occlusion generation in advanced mode or use xLODGen for Occlusion generation. If generating occlusion separately does not work for all worldspaces either, only select all worldspaces but Tamriel. Rename the generated occlusion plugin and then generate another occlusion plugin with only Tamriel selected. If this happens without occlusion, then do not select some small worldspaces (added by mods) you won't be visiting often and hope it is enough to stay under the limit. Ignore all worldspaces added by Vigilant. They are ignored by default, but the list maybe incomplete. Renaming DynDOLOD plugins does not work with dynamic LOD. Use "Copy message to clipboard" paste it as text when making posts.