sheson

You should also enable bLoadDebugInformation=1 so we know which line number to message is from. That would help. Have you checked if any of the stuck LOD objects is indeed listed in the log? The Form ID you get with console from such object is in the log? If an object is "None" it usually means it is not loaded and consequently should not have a 3D model in the world at that time. However the object was in the world when the script attached it which produce the error was started. This could indicate some timing issue. It all depends which objects generated the error and if you can replicate it. Maybe put this aside for the moment and lets see what the debug tests below reveal: Find the attached papyrus script to replace in the DynDOLOD Resources installation. It allows setting a (integer) form id in skse\plugins\StorageUtilData\DynDOLOD_Worlds.json Find the line "debug":"false" and change false to the load order zeroed integer of a dynamic LOD object. A dynamic LOD object is a reference that has *_DynDOLOD_LOD as EditorID A zeroed form id means to 00 the first load order byte. So if the form id is e90043af, it becomes 000043af Then convert it to an integer which is 17327 in this case, so the line becomes "debug":"17327" The papyrus log should then show activate and disable lines like this [07/12/2017 - 07:54:42PM] [sHESON_DynDOLOD_LODObject ] Activate #1 [Form ] using lod\windhelm\elfxwhclancruelsea_lod_2.nif [07/12/2017 - 07:54:42PM] [sHESON_DynDOLOD_LODObject ] Activate #2 [Form ] using lod\windhelm\elfxwhclancruelsea_lod_2.nif [07/12/2017 - 07:57:40PM] [sHESON_DynDOLOD_LODObject ] Disable #2 10 [Form ] using lod\windhelm\elfxwhclancruelsea_lod_2.nif In my case when I coc windhelmexterior01, this particular LOD object does not activate, because its position is actually inside the uGrids and the *_DynDOLOD_TOWN reference shows. I need to go towards the stable first. The Disable #2 happens when I enter Windhelm. For now do these tests with new game / coc from main menu. Just pick any stuck reference inside the city you like. The log messages record just before executing the command, not if it actually worked. My current questions are: Do you see the Activate messages (the 1/2 paring is normal) for LOD objects that are actually inside the loaded cells? (use tll, tb, tfc commands) Do you see a Disable message when entering the city Does it seem any different if you coc further away and just walk towards and then into the city? You can check the papyrus.0.log in realtime with something like snaketail-net

Those are some great suggestions. Lets ponder about a few thing: My first question is if Game.GetPlayer() is actually a costly function or not. It could be just as fast as using the variable. You know / any tests? Otherwise I plan to do some timing test sometime soon. In this case it is only used twice. Assigning it to a variable may just negate the potential time win - if there is one. If Game.GetPlayer() is costly I would think the best solution would be to set it globally in the script OnInit so all events benefit. The value of Game.GetPlayer() is never going to change in the game, is it. I consequently removed all strings variables and cast to string as much as possible because of the save game string count issue. The same questions as above arise. Is self.GetWorldspace() actually a costly function or not and is assigning it to a variable and reusing it faster? Any tests? Since most of these are inside a if (MyMaster == None) it should only run once ever, so speed optimization is not really required. And not using string variables that count towards the string count seems more important. Yes, this could use some work. The file is only read once and then the data is kept in memory. It seems silly and can probably be removed. I need to check.

I would appreciate if you send any suggestions for improvements to me for discussion / implementation.

This suspiciously looks like papyrus problem to me. It usually spits out errors left and right when things go bad dumping stacks etc. I have some ideas for some tests by adding some additional debug.trace() to the scripts and manually editing the json files so we can focus on only 1 or 2 objects for some tests. Can you edit/compile payrus scripts yourself or would you prefer me to upload already compiled versions?

That is great news, glad we found it.

The last line of log shows us that it actually gets as far trying to start LODGen.exe, which is right after it creates the atlas. Do the atlas textures files in D:\CHARLY\steamapps\common\Skyrim\Modding Tools\DynDOLOD\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_Atlas_Tamriel.dds and *_n.dds actually exist? I probably should have asked that earlier :) Does the command prompt window ever spawn? There should be a new icon in taskbar. If not something external seems to prevent it. Typically I would suspect something antivirus or UAC. It could be that Windows Event Viewer has a message. If you can not find out anything that way, see if manually starting it shows us something. First just use explorer and doubleclick LODGen.exe in D:\CHARLY\steamapps\common\Skyrim\Modding Tools\DynDOLOD\Edit Scripts\ A command prompt window should briefly open and close. It will create a short LODGen_log.txt in the same folder that should contain something like Skyrim Object LOD Generator 1.5.0.0 Created by Ehamloptiran and Zilav Updated by Sheson Log started at 21:58:40 Nothing to do Log ended at 21:58:41 Code: 1If that worked without problems, try to run the command line it uses to generate LOD for Tamriel: Open a command prompt (add binary C:\Windows\System32\cmd.exe to MO Executables) and copy/paste (click c:\ icon top left of command prompt window, Edit, Paste, or enable quick edit mode to use right mouse button) this single line and see what happens when you try to execute "D:\CHARLY\steamapps\common\Skyrim\Modding Tools\DynDOLOD\Edit Scripts\LODGen.exe" --inputfile "D:\CHARLY\steamapps\common\Skyrim\Modding Tools\DynDOLOD\Edit Scripts\Export\LODGen_TES5_Tamriel.txt" --logfile "D:\CHARLY\steamapps\common\Skyrim\Modding Tools\DynDOLOD\Logs\LODGen_TES5_Tamriel_log.txt" --dontFixTangents --removeUnseenFaces --skyblivionTexPathSee what happens.

I didn't find anything out of the ordinary in the file. Are you knowingly using any mods that update LOD textures? DynDOLOD just closing without notice is weird. The fact that this also happens to MO is even more weird. This could either mean a cpu/memory hardware problem (overclocking, CPU temps) or something going on with MO virtual file system. Check MO logs for an errors. ModOrganizer\logs\*.log I would empty the folder first without MO running, then it is easier to just have the log which matters for the last run. Obviously it would be best to try doing the same run without MO, but that requires some work... in case you know how to do it, give it a try, otherwise do not worry about it for now. You could also try right clicking DynDOLOD in the task manager and change its "affinity" to use less cores or even only one to see if that makes a difference. You can do that any time, right after start or just shortly before it starts doing the atlas.

There is nothing wrong with a program using 100% CPU. Do you mean it keeps working with high CPU usage forever? Upload/Post DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_SSE_tamriel_textures_used.txt There is a chance one of the used textures is corrupt. Just maybe I can spot something.

Disabling Gildergreen Regrown is nonsense, it is dynamic LOD with full models only - no relationship to the static object LOD texture atlas. If that actually would work, I suggest to scan the entire load order for error in xEdit and fix them as much as possible. If doing the recommend unticking of bashed patch works, it means the same. It has errors that should be fixed. Try these things that we have discussed here in the past couple of months a few times: Try this test version https://mega.nz/#!Bc5gmArQ!IzFTE3LCFLYPSlXdUzfVXcs2YiVV0qy4-W3-L1_o7Hw Set FasterBase=0 and/or FasterCreate=0 in DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini Check this thread https://forum.step-project.com/topic/12183-error-out-of-memory/?hl=+out%20+memory Make sure not to install DynDOLOD, the game, or anything else related to special Windows folders like Program Files etc. If none of that helps, try to generate the problematic worldspace all by itself. If it runs through then, install output as normal. Then start DynDOLOD.exe with the DynDOLOD.esp in the load order and generate LOD for the remaining worldspaces. Install new output, overwriting any old output files, including DynDOLOD.esp.

That list is not how you do things for Skyrim or Skyrim SE. I suggest to read the included documentation and docs\DynDOLOD_Manual_SSE.html in particular. Also have a look at this thread https://forum.step-project.com/topic/11518-dyndolod-skyrim-special-edition/

I already saw the mod couple days ago. It is cool. When I find some time I will try to check typical DynDOLOD generation for users that generate themselves and add it to the list of compatible mods. With specific overwrite notes if necessary.

FAQ: Skyrim: ILS or CTD A: More LOD uses more memory and this can cause infinite loading screen (ILS) or crash to desktop (CTD) if the game is not setup correctly. Double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Or use alternative OSAllocator from crash fixes with pre-loader. Remove satefy-load if it is used to verify it doesn't cause CTD. Set ExpandSystemMemoryX64=false in enblocal.ini If heap memory is not the cause of CTD see Docs\ DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause.

Beyond Skyrim - Bruma The current available download of Beyond Skyrim - Bruma does not contains all cells, references or LOD models that were used to generate the included LOD. This affects the southern non-accessible area. TES5LODGen/SSELODGen/DynDOLOD can only generate LOD for trees and objects for which references exist in the plugins. For users generating their own LOD to match their load order this has some side effects: If generating tree LOD, the existing tree LOD "meshes" in the south will not be overwritten. They may use the wrong LOD tree from the index, but overall that should be OK, since the player wont get there. If generating object LOD, the map and the larger lod levels will miss some objects to the south which are part of the included object LOD. Unfortunately the missing cell data does not cut off at a 32 cell group, so there is a obvious gab when it is known what to look for. The next update of DynDOLOD will know about the mod and make a best effort LOD generation. However, by default the BSHeartland worldspace will be ignored for now while the mods lacks the required data and resources to correctly generate LOD for a user load order. Beyond Skyrim - Bruma Tree LOD billboards (Skyrim) by mobiusbelmont Beyond Skyrim - Bruma Tree LOD billboards (Skyrim Special Edition) by mobiusbelmont Bigger Heartland Aspens for Beyond Skyrim Bruma by mobiusbelmont Imperial City LOD fix for custom lods (Beyond skyrim Bruma) by C0331 AKA Privata Check this thread for more disucssion

Awesome, great to hear all is solved.

I am confused about your modwatch, as it shows JK's Whiterun.esp instead of JK's Whiterun-Open cities SSE.esp If you generated object/tree without Open Cities Skyrim.esp and without JK's Whiterun-Open cities SSE.esp, then discarded the DynDOLOd.esp, and then do the second pass with the OCS and JK esp with ;ChildWorlds= commented out and object/tree LOD unchecked, whatever objects you might be seeing are most likely not added by DynDOLOD, but other mods. Get the objects form id in console and then look it up in xEdit. If it is not added by DynDOLOD.esp, then LOD generation went correctly.

That is a funny question, since that is part of what you edit in the DynDOLOD_SSE.ini for the second pass. ; Child Town worlds to check for new LOD ChildWorlds=MarkarthWorld, RiftenWorld, SolitudeWorld, WhiterunWorld, WindhelmWorld So, you could remove Whiterun from ChildWorlds= for the first pass, though I have not tested that everything would work correctly when generating static object LOD. When using Open Cities, there is no point in having any mod in the load order that changes the childworld cities, as they will be all part of the Tamriel parent world. All mods that change cities and are somehow linked to Open Cities, should all be deactivated for the first pass. Did you do that?

Is that a Windows 7 default installation? I thought it already had 4.0, but it seems it comes with 3.5.

That means LODGen.exe does not run and can not generate static object LOD. Open a command prompt (add binary C:\Windows\System32\cmd.exe to MO Executables) and copy/paste (click c:\icon top left of command prompt window, Edit, Paste, or enable quick edit mode to use right mouse button) this single line and see what happens when you try to execute "G:\DynDOLOD\Edit Scripts\LODGen.exe" --inputfile "G:\DynDOLOD\Edit Scripts\Export\LODGen_TES5_Tamriel.txt" --logfile "G:\DynDOLOD\Logs\LODGen_TES5_Tamriel_log.txt" --dontFixTangents --removeUnseenFaces --skyblivionTexPathSee what happens. There could be something preventing it from starting etc.

2D tree LOD is done by xEdit/TES5LODGen on which DynDOLOD is build. If there are LOD trees without full models, generate tree LOD for the current load order. Make sure none of the generated *.btt are overwritten by other mods. 2D tree LOD generation only generates tree LOD for tree references existing in the load order at the time of generation. FAQ: Tree LOD: LOD trees show in child worlds / towns A: This is a game engine limitation. A mod added trees into the same area in the parent world. Either disable that mod when generating tree LOD, or add a XESP - Enable Parent to the player reference 0x00000014 to each tree in question. Tree LOD generation skips all trees with enable parents leaving them to be done as static or dynamic LOD which don't have the limitation. In this case USLEEP adds duplicate trees into the Solitude Worldspace to cover up LOD trees from the Tamriel worldspace that do not unload, because of that limitation. Edit: Looks like an unintended duplication in USLEEP. It is doing it for a few trees around Solitude, but only a few have that problem. I will try to clean that up and submit an update.

Try this test version https://mega.nz/#!Bc5gmArQ!IzFTE3LCFLYPSlXdUzfVXcs2YiVV0qy4-W3-L1_o7Hw Check this thread https://forum.step-project.com/topic/12183-error-out-of-memory/?hl=+out%20+memory If none of that helps, try to generate the problematic worldspace all by itself. If it runs through then, install output as normal. Then start DynDOLOD.exe with the DynDOLOD.esp in the load order and generate LOD for the remaining worldspaces. Install new output, overwriting any old output files, including DynDOLOD.esp.

If it works with the real roads esp still in the load order then it is most likely because the mesh is in its accompanying BSA and somehow wasn't copied over when creating the merge.

I did a first test just with USLEEP and ELFX installed with your options without problems so far. None of the other mods should really matter as it is all about the references and base records you listed, which are just Skyrm, ELFX and then DynDOLOD in this case. Doublecheck the DynDOLOD Papyrus scripts are the latest version with timestamp 2016-10-28 I wonder if you could generate LOD just with USLEEP and ELFX to verify if it still happens then. Then test the game with just those couple mods, but also test with the full setup to see if that makes a difference. Check if the papyrus logs show any errors. To clarify, when you say floating objects, it is always the correct LOD objects for that position, right. They just don't disable as they should.

This will be fixed next version. I will also try to add a additional updates for those mods.

The log shows there is an existing DynDOLOD.esp in the load order when you started DynDOLOD.exe. From scratch means that there should be no old DynDOLOD.esp when start DynDOLOD.exe, so that everything is created new. So your step 2. means keep the old DynDOLOD.esp deactivated/deleted.

Again, this is how the engine works. If two models show in the same 3D space there will be flicker. Unless they are 100% identical in every aspect, maybe. I think it still happens a bit even when using full models for LOD. Make sure the full models detail settings are push to the max. uGrids is the only solution to push it further away. With Skyrim SE it could use the large reference to push the full model trees, but that requires Bethesda to fix the bugs, or me writing a patcher doing some "drastic" workarounds.