sheson

Yes. If high resolution terrain LOD meshes are used it will take even longer to optimize the result. If you are repeatedly testing different settings for a single worldspace, change to expert mode in DynDOLOD_TES5.ini and on the expert options uncheck Remove unseen faces. It will be faster but produce larger *.bto files which are fine for visual control but take longer to load/need more heap memory.

Is LODGen.exe still doing something or not?

Great. news, thanks. No need to worry about the other questions anymore since the newer LODGen.exe fixes it. Is LODGen.exe still doing something or not? Is it using CPU? Which worldspace is it calculating?

That is odd because somebody mentioned this happening with the older versions. When you installed 1.47 did you remove all old 1.46 source files that you copied from the download archive or did you just overwrite? Are you using an ore replacer mod of any kind that changes the files in meshes\dungeons\mines\ore\*.nif or the textures textures\dungeons\mines\*.dds? It only happens in that area and nowhere else? That is even more odd :) I believe this has to do with glow LOD in static object LOD. Did you use Window Glow LOD? I kind of hope you use MO and may still have the 1.47 generated files around. If that is the case could you hide the meshes folder and only keep the esp/skse/textures folders that you coped from the output path and see if the problem is gone? If that is the case, could you overwrite with this /../TES5Edit/Edit Scripts/LODGen.exe and generate static object LOD with latest version and see if that fixes the problem? It would help if you could generate once with and without Window Glow LOD - that is if you used that option in the first place. LOD for will not look correct for latest Legacy of Dragonborn. Should only be a visual problem, though. But I would be better if we can find out the cause of the problem so I can fix it.

The static LOD just for Legendary is about 700MB for medium and about 1 GB for high. It will be more depending on mods or mesh rules. That didn't really change. If it was lower it might have been low settings or something else caused it to stop *.bto generation prematurely. Good, you found the post. Next version will ignore the empty worldspace automatically.

Use external data types from PapyrusUtil instead of native variables. Use integers IDs.

The important part is to get a newer LODGen.exe from that download. The LODGen_log.txt should start with something like "Skyrim Object LOD Generator v1.0.0 beta" - v 0.9 will crash for sure.

This problem affects every mod. I did not fix the problem. Removing any mod from the load order will free up "strings". In the linked thread a few mods that actually use a lot of "strings" are talked about. With the updated scripts I just made sure that DynDOLOD uses as few "strings" as possible. Other authors of certain mods should try to do the same. This is a principle problem in the architecture of the game. Some possible workarounds would require a lot of creative programming. Do not confuse the term "string" with the content of string variables. Those are only a small number of everything that is a "string" in this context. There only should be unattached scripts if you didn't follow the update procedure for example. No dynamic Forms are created. Forms in the esp do not go missing by themselves. As mentioned in the update post, update to a newer xEdit/LODGen version. If the latest LODGEn.exe crashes take a screenshot please. Great news. If you ever have to update LOD or just the LOD atlas texture you could try to reduce the atlas tile size from 512 to 256 to test if a smaller LOD atlas texture for that worldspace helps.

Since you are only reporting what you think is an issue and not looking for help, I guess there is no point telling you how script instances are not a problem whatsoever. A script instance is just data that doesn't do anything while it is not used. There could be millions of them stored in the save and all they do is use space without causing any problems. The point of performance friendly LOD is to pre-compute data in advance so it doesn't happen at run time. The data needs to be stored somewhere so it can be accessed when it is needed. The most likely cause of your problem is the string table in the save which can only hold 65535 entries. The real issue is the total number of mods and their use of strings. You removed one mod that uses strings. You could have removed another mod and have the same effect. It depends on the mods and their settings how many strings they use, some use more, some use less. No point linking to this post to markdf or this thread [NSFW because ads] either I guess.

The current requirements for DynDOLOD are stated on the first post, description page on nexus, the update posts, in DynDOLOD_QuickStart.html and in docs/DynDOLOD_Manual.html. Both the description of the video and Michael in the video link/show and mention the dev version of TES5Edit with link to https://www.afkmods.com/index.php?/topic/3750-wipz-tes5edit/, which has a post "All new builds will be uploaded to FO4Edit Nexus page for a while." It seems really hard to miss

You didn't generate static object LOD or didn't copy the generated static object LOD from OUTPUT FOLDER\Meshes\Terrain\tamriel\Objects\*.bto to the game/mod folder. Or LODGen.exe didn't find required files, check ..\TES5Edit\LODGen_log.txt for errors. Or LODGen.exe crashed and didn't generate any/few bto files. Make sure you have the latest LODGen.exe. If the latest version crashes, please post screenshot of error.

Great news. Glad you found it.

No rebuilding while we do this troubleshooting. Always use the same esp.

There is no need to answer questions to others users with different problems. Back to the TES5Edit log: When DynDOLOD Worlds.pas processes the load order, it can only access files that TES5Edit "sees". At startup TES5Edit lists the BSA and game folder. [00:00] Background Loader: starting... [00:00] Background Loader: [skyrim - Misc.bsa] Loading Resources. [00:00] Background Loader: [skyrim - Shaders.bsa] Loading Resources. [...] [00:02] Background Loader: [C:\Steam\steamapps\common\Skyrim\Data\] Setting Resource Path. The patcher uses a TES5Edit function called ResourceExists. If it returns false, it means the resource does not exist in the currently loaded BSAa or loose in the game folder. Check these files which were reported missing when LOD was generated. meshes\prometheus\architecture\statuessnow\statueofmeridiasnow.nif meshes\prometheus\architecture\statuessnow\statuedibellasnow.nif meshes\prometheus\architecture\statuessnow\mehrunesdagonsnow.nif meshes\prometheus\architecture\statuessnow\azurastatuesnow.nif Also check the installation of Farmhouse Chimneys. There we several reported cases of missing nifs causing CTD with that mod before. Troubleshooting means eliminating all possible causes of an error. Disable every mod that is not required to successfully start the game. Lets rule all out any possible causes of invalid/missing meshes/textures. Only enable mods with esm or esp which are required to start the game with DynDOLOD.esp to narrow down the list. If that then still CTDs, we can continue to trouble shoot by removing data from the esp in groups.

If you have the same problem than the same fix applies. Very unlikely. Does it also happen with a new game? Did you click the object and get a form id? Could you disable it manually? Why do I feel like a broken record? :p

Meshes from No Snow Under the Roof are reported missing in the log. I assume this happens because they are in a BSA that is not loaded by TES5Edit. The "required" load order is the minimum one to successfully start the game with the generated DynDOLOD.esp. I can run the DynDOLOD.esp you generated by just activating the esp it requires. Vice versa, disable every mod that is not required to start the game with DynDOLOD.esp. It will produce a result either way. There is no need to have hundreds of meshes and texture replaces active. In one large swoop you can eliminate them as the cause or the culprit. I have not yet asked to generate anything again with certain mods disabled. That would be the next step if the other steps did not work. An quicker alternative is to edit the existing esp and remove chunks of objects. It is pretty simple actually. But narrow down the load order first. With MO it should be a matter of a minutes with using a second a profile.

Got it. In the meantime I was able to replicate most of the required load order using the latest versions of the required mods with some guesses to the install options. I only had to use 3 empty esp dummies for cot patches, rbb -sr merge and sr conflict. They should not matter since they do not add objects, just update cells records. I can run from Morthal to the mine and around Whiterun no problem. Note that I always unpack all BSA (including DLC) but not the Vanilla BSAs. If you merge mods either unpack the BSAs or rename the BSAs to the new merged mod file so that all assets are available in TES5Edit at LOD generation time. Make sure all meshes from Farmhouse Chimneys are installed properly. There were reports about similar problems with this mod in the past. The log shows that it is ignoring meshes from No Snow Under the Roof. That should not be no problem, but since you have a merged esp either rename it or unpack it as explained above. There is always the chance that the mods required as master are all fine, while a non listed mod replaces a mesh that causes trouble. Create a second profile in the mod manager, disable all mods which are not required to make the list as small as possible. Process of elimination... Let me know if that helps - if not we can try to disable certain mods before generating mod. The list won't be that long as most mods added as master are generally known to be fine.

it is only the esp and jsons in the download

Got it, thanks.

Yes, that will fix that problem for now. I will update this for the next version so it can stay active. I somehow forgot to make my own patch compatible with recent changes to the patcher

Ah, I see. Install/Enable whiterunexterior.esp afer generating LOD. I need to update it so it is compatible :) The meshes from DynDOLOD are valid of course. The mod/mesh can work fine and only when the mesh is used as dynamic LOD it can be problematic. I had no chance to download your file yet. Please re-upload. Can you also please upload ..\TES5Edit\TES4Edit_log.txt with the generation log for Tamriel.

Meshes from DynDOLOD are fine. It is meshes from other mods that get picked up for LOD that are problematic. I will look at the files you uploaded and see what I can find it out. Looks like updating an existing save game went wrong. Test if problem is present with a new game. coc whiterun from main menu will be good enough for a quick test.

Just to verify, this is the last line of the log right? That nif won't cause problems and anything else is 2, 3 seconds earlier so they all should be fine too. Can you reproduce the CTD with a new game? If you "coc morthalexterior01" from the main menu and go towards the mine? Does it also CTD with the esp active, but the json files in skse\plugins\StorageUtilData\ disabled? Do not worry about it complaining not being able to read the json files for this test. Would you mind uploading the esp and DynDOLOD_Tamriel.json, DynDOLOD_Tamriel_Objects.json and DynDOLOD_Worlds.json from skse\plugins\StorageUtilData\

You asked if you need the esp active for some reason. I simply answered that question. Nothing is forcing you to have it active - as in it is not required for the game to work. There will be visual downsides or features missing. I suggest to read the manual and/or this thread for further information. I probably need to work on the trouble shooting steps in the readme for a better procedure. Please post the papyrus log before you manually disabled any nifs... so basically with everything active. Just the last 2 or 3 seconds worth of lines are enough. See discussion about missing/invalid nif above. However, those are usually 100% reproducible. Anything else is typically just the higher overall usage of resources - VRAM for example. Make sure to not use questionable Skyrim/Prefs.ini settings. Set ExpandSystemMemoryX64=false in enblocal.ini etc...

Check for invalid/missing nif as outlined in the FAQ/Readme. The esp is used so new static LOD objects on cell borders do not z-fight with full models and it contains all dynamic LOD data. However, nobody is forcing you to use anything from DynDOLOD.