sheson

10 minutes is quite a long time. I'll update the Skyrim: Out of place objects / floating objects / flickering full models with suggestions we found out here

You can try to use the MCM toggle in Tamriel worldspace (not in any town). If it is off, go inside a building. Go out, wait a couple seconds, then toggle it on if it isn't already. If that doesn't work, do the clean save routine as already suggest. Disable from menu if active. Go inside. Save, Disable esp, start game and save again, enable esp, load last save, go outside and after it loaded the exterior, wait for it to activate by itself before moving about. If script lag is already bad to begin, try to generate LOD with less dynamic LOD objects. Consider some or all of these suggestions: use low instead of medium do not check candles or glow rules do not check Windows high lower size of FarGrid BTW ELFX replaces the buildings models with their own new path to windows textures, which is why you won't see the rustic windows textures and DynDOLOD LOD Windows will not match perfectly. I guess you could either remove the updated architectures models, if you want to have the rustic windows, or just not use rustic windows (run TexGen afterwards so the windows LOD textures are vanilla again, which will match the textures from ELFX better).

There are no errors in the papyrus log. If something only works on a new save, then this usually means something went wrong when updating an existing save. You can try a clean save routine where old and new esp are the same. The NetImmerse option should only change the brightness of LOD windows. Make a negative test where you turn it off again and check if it consistently changes things back. Repeat to see if it always affects the same objects. Verify that the scripts in ..Data\Scripts\SHESON_DynDOLOD_*.pex are the version from latest Resources archive and none are overwritten. They should all have the same date August 26 (may be off by a day depending on your time zone) Make sure none of the generated files are overwritten by anything (MO overwrite folder can be sneaky sometimes) Please post/upload the ..DynDOLOD\Logs\DynDOLOD_TES5_log.txt from the generation Also post/upload ..skse\plugins\StorageUtilData\DynDOLOD_Tamriel_Objects.json

Typically it would be better to fix errors in plugins before using them in the game. Then there also would be no need to disable them before generating LOD.

Are you using the latest versions DynDOLOD 2.35 standalone and DynDOLOD Resources 2.30? Make sure there are no files from older version lingering around. Post the log from the generation. Enable Papyrus logging. Start new game by coc SolutideExterior01 from main menu. After DynDOLOD initialized go into Solitude. Check if there are any errors from DynDOLOD scripts in Papyrus log.

There is no reason to change the steam installation folder, only alternative download versions do that. It will mess up installation paths in the registry. It is enough to replace the SkryimSE.exe to run older engine versions. The log shows DynDOLOD version 2.27. If you search this forum for this type of error, you will find similar reports back 6 months ago.

DynDOLOD only works with the official steam version of Skyrim SE. Use the latest DynDOLOD version.

We are obviously only interested in the first exception. No surprise that there are more problems later. No surprise that updating LODGen.exe does not change problems that happen with TexGen.exe/DynDOLOD.exe. Are you using the latest version 2.35? Did you check the entire load order for errors and fix them as good as possible with xEdit? Post the log of the x64 start up error and the log of the x86 out of memory error if possible. Other make screenshots of the message window.

You need to replace xx with the hex load order of the plugin of your load order.

Add -sse as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Skyrim SE mode. See DynDOLOD-Shortcut.txt for help.

Yes, I was awaiting for this new version to be released.

Do not install DynDOLOD standalone into game folders. Do not install DynDOLOD into special folders like Program Files x86. Test if it works then. In addition, do not install the game into special folders like Program Files x86 and clean dirty plugins including Update.esm and DLC.

That setting would mean it will try to use the hybrid LOD models in LOD level 16. LODGen.exe (32 bit version) might actually run out of memory because that can mean a lot of 3D data to process for a single LOD supermesh. It could also be too much data to properly fit into the supermesh nif. Billboards for level 8, 16 should always be good enough visually.

Can you try to make a screenshot of the entire error message and upload it somewhere? You do not have to re-run the entire process. Just change to Expert=1 in ..DynDOLOD/Edit Scripts/DynDOLOD/DynDOLOD_TES5.ini Start DynDOLOD as always, change the drop down to Tamriel, then click "Execute LODGen.exe" button to start it directly with the already gathered LOD data.

See if replacing ..DynDOLOD/Edit Scripts/LODGen.exe and LODGenx64.exe with this latest version changes anything. If not, try to bring the command prompt window to the front and make a screenshot of the error and check the ..DynDOLOD/Logs/LODGen_TES5_[Worldspace]_log.txt. If DynDOLOD.exe stops/freezes see if setting FasterBase=0 or FasterCreate=0 makes a difference. Otherwise make a screenshot where it stopped working. Make sure CPU temps and/or overclocking settings are fine and not the problem.

The script version posted here is outdated and incompatible with DynDOLOD 2.30 and newer. It probably "works" because it is not working at all and thus no error messages are showing on screen. There probably will be lots of errors messages in the papyrus log, though. Follow the update instructions from the update post https://forum.step-project.com/topic/12479-dynamic-distant-objects-lod-dyndolod-235/ Make sure no old files are lingering around in the load order.

Generate a new DynDOLOD from scratch so updates to other plugins are carried forward correctly.

Check the load order for errors with xEdit.exe before generating LOD. In xEdit, mark and right click plugins and select "Check for Errors" Fix all errors as much as possible. See this video for help.

Great we could solve it. These bugs affect everybody the same, some people are just not that observant or are used or just live with them by now.

It will still have large reference flicker because large references (the makers) are edited (moved) by an esp. However, iff you rename the plugin to an esm it might be the same now between 5 and 11 because they are not disabled anymore. The LOD to non LOD transition is usually always the same for all objects with the distance LOD flag. Only the Has Tree LOD flag can change the timing. You could test what happens if you create an overwrite record and remove the Has Distant LOD flag on the base records, for example 00105567 that is used by the reference you mentioned). Then test what happens if you set Has Tree LOD (this should not be set when generating LOD). It probably takes longer the more objects need to be loaded when the cells attach. You should compare to vanilla game but with the same INI settings. If renaming the plugin to esm and using a Large Ref distance of 11 works better now, you can push that transition further away and reduce number of objects that need to be loaded when the cells attach, because the large references already loaded ahead of time.

Compare flickering between or Large Object Distance slider moved to the left (uLargeRefLODGridSize=5) and right (uLargeRefLODGridSize=11) If there is flicker with 5 or Large Object Distance slider moved to the very left, then it is not the bug. If it is a brief 1 second or so flicker, then this is normal as this is how the engine works. It first loads all full models and then unloads the LOD. In that brief overlap textures flicker. With 5 that switch happens much closer to the player than with 11. If there is flicker that continues as long as the player is in the same cell, then get the form id of the objects involved so I know what to look for.

Regarding the remaining reference that flickers, that is not the normal 1s transition flicker? It continues until a new cell is loaded? If it is just a brief 1s or so, then this is how the engine works and it happens for all LOD objects being switched out when the cell is loaded. It may be just a bit more prominent for some large structures. What is its form id? Does it happen with vanilla LOD also or only with LOD generated with SSELODGen? Edit: The plugin overwrites these large references: [REFR:0010E31A] (places DragonMarker [sTAT:000138C0] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at 28,27)[REFR:0010F8C5] (places DragonMarker [sTAT:000138C0] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at 28,27)[REFR:00107F53] (places SnowDriftM01 [sTAT:0006021F] in GRUP Cell Temporary Children of WinterholdCollegeExterior [CELL:00008E62] (in Tamriel "Skyrim" [WRLD:0000003C] at 28,27))[REFR:00107F51] (places SnowDriftM01 [sTAT:0006021F] in GRUP Cell Temporary Children of WinterholdCollegeExterior [CELL:00008E62] (in Tamriel "Skyrim" [WRLD:0000003C] at 28,27))[REFR:00107F52] (places SnowDriftM02 [sTAT:00060220] in GRUP Cell Temporary Children of WinterholdCollegeExterior [CELL:00008E62] (in Tamriel "Skyrim" [WRLD:0000003C] at 28,27)) which causes the large reference flicker. The first two are persistent markers with no visible object (yes, that is how bad Bethesda screwed up). Disabling existing persistent large references always causes the large reference texture flicker regardless of the plugin being an esm/esl/esp. That is why large reference texture flicker still happens after renaming the plugin to esm. The only working solution I have found so far is to "delete" (which is bad) or move them (or not using large references by the already explained settings)

Sounds good. i suppose that means you have nice looking 3D tree LODs all around as well now?

Looks great. Enjoy.

If you set LOD 16 to empty then there will be no tree LOD in that furthest LOD level in the world and on the map, which by default uses object LOD level 16. If you do not want that, then use the alternative option that makes use of LOD level 32 for the map instead. Choose only one of the 2 different options. Choose the one that fits your needs.