sheson

I checked the files you sent. Very thorough which I like :) The effect you are seeing is not static/tree/dynamic LOD generated by DynDOLOD, as your examples are always the full model and its object decal fade - a function to remove detail in short distance for performance. If using DynDOLOD the decal fade can happen earlier because of more objects I suppose. There is a fix and since we run on modern hardware it should not matter performance wise. This mod has an ini fix, you can either download a fake esp/ini combo or just update the Skyrim.ini drectly with [LightingShader] fDecalLODFadeEnd=1.0000 fDecalLODFadeStart=1.0000 That is great. I amm looking forward to it. I just want to mention that anything with fMeshLOD in its name usually has to with the BSLODTriShape fade defined in the nif - meaning they apply to the full models.

Great that it worked, that is all that counts :) Maybe it is just that trees are one of the first things to switch? Is it different in regions with less trees? You using any tree mods? I dunno, maybe changing these settings help? [Trees] bRenderSkinnedTrees=1 uiMaxSkinnedTreesToRender=20

@manguz, @Mebantiza Please download these scripts and overwrite the existing. Then load the interior cleaned save, go outside. Open the MCM and activate DynDOLOD. Wait until the pop-up appears "DynDOLOD activated". Top left should be the successfully initialized. Let me know how it goes...

Use values that work for your setup.

Any file upload service would do, or something google drive. Or send me a private message for an email address. It could just be the things it has to load for the cells itself. It may not even have to send new amounts of data to the graphics card. Static(*.bto)/Tree(*.btt)/Terrain(*.btr) LOD only need to load every 4 cells. I guess put those and their textures on the ramdisk Just for testing, I would test if using the low/medium/high settings of only [terrain] make a difference at all.

Lets see what I can find with manguz save. The numbers of the masters in his esp is simple enough. There is really no reason it shouldn't work with an updated esp with all new form ids for things. It will be great to know why/what for the future. If you like you can upload your files too and I will have a look some time. Load up the new esp in TES5Edit and clean masters before uploading. Yes just untick it and after a few seconds a message should say it is deactivated and you see all waterfalls, fires, windmills and stuff turn off. Use tll in console to switch static/tree LOD on/off For the terrain values I just go with the ultra for now while testing and only raise tree distance to 150000 usually. Truth be told I have not experimented a whole lot with the values performance, only verified what they do, Since I keep saying default INI that is what I use like a baseline for low/medium/high for testing. A cell is 4096, max draw distance is about 100 cells

Don't beat yourself up, there is a good chance DynDOLOD misses something and as I explained before then it uses a default texture. Whenever you get the chance try to get the screenshots and form id(s). I take firstborns of any age. I will have a look, may take a bit.

Millions/Billions of scripts seems impossible, this sounds like an integer overrun in the tool. Could it be 16bit / 65535 + a few?

If I understand this correctly some dirtcliffs have the wrong LOD texture just with vanilla+DLC/Hires and the unofficial patches? Can you go close to such a dirtcliff and open console and click it so it shows the form id and then make 2 screenshots, one while it is while it is loaded OK close up with the form id and one when it has wrong textures as LOD? Regarding the windmill outside of Whiterun, this is the vanilla game optimizing things. Check the folder Options\whiterunexterior\ in the download archive. Can you upload the save, the esp and the json files (just _world and the 2 _tamriel) I like to have a look.

Hi Eddie. This sounds like a mod changes the dirtcliffs and DynDOLOD is not "seeing" the right replacement textures and instead uses a default one. Please let me know the mods name and I am sure I can fix it and make things compatible. Let me know if you need help identifying the mod with the form id and TES5Edit in case you don't know it right away. Ha, copy paste fail, you had the right idea with EnableUnsafeMemoryHacks and in all case I mean the true setting. If ExpandSystemMemoryX64 is set to true and block1 TRUE size needs to be over 512 you may have to raise block2. With all these settings, there is chance of CTD and whatnot - just saying :) While you at it, consider testing windows folder compressions. It could/should have the same effect as BSAs. If there is any. RAMDisk doesn't sound crazy at all. I was thinking it too but just didn't want to go all nerdy on my answer.

I think we can assume the 6GB are not used up and optimizing textures would probably not help. While static LOD is easier on fps/draw calls because of merged meshes and atlas texture it also means more data needs to transferred from disk, so make sure disk access is as good as it can be. There may be a benefit of putting the genereated *.bto and *.btt into a BSA so less data is read from disk because of compression, I haven't tested that yet. It may be a good test to disable dyanmic LOD from the MCM and just see the impact of loading static LOD. You may have better results with actually decreasing LOD4 distance and increasing/decreasing LOD8 a bit. [TerrainManager] fBlockLevel0Distance=35000.0000 fBlockLevel1Distance=70000.0000 fBlockMaximumDistance=250000.0000 fSplitDistanceMult=1.5000 fTreeLoadDistance=150000.0000 If the VRAM never gets full, you could try ENBs DisableDriverMemoryManager and/or DisableDriverMemoryManager Also reportedly ExpandSystemMemoryX64 helps vs stuttor, but has the side effect of occasional CTD, memory patch issues, e.g. needs to raise block2 to start game. But you might be able to find a middle ground playing with these things. Sounds all good. I uploaded newer papyrus scripts a couple posts back. Simple overwrite existing, see if that changes anything

If DynDOLOD doesn't initialize it doesn't mean the save is corrupted. It either means the DynDOLOD.esp is not the right one, or the *.json files are not the right ones or the papyrus scripts are not the right ones. A save game is corrupted if you can not load the save. Any other mods or plugins you updated in the meantime? INI changes maybe? Which PapyrusUtil (skse/plugins/storageutil.dll) version are you using? 3.1 Fixed a bug causing CTD during save load for some users. We know 2.8 was stables over months. 3.0 was only short lived. Do you have NetImmers Override (skse/plugins/nioverride.dll) - it is also included in Racemenu - installed and have you generated with any glow LOD? Version 3.4.4 Fixed string erasure bug causing co-saves to lose data Version 3.4.3 Fixed rare case where if a string could not be mapped to the string table at save time it would corrupt the save If you enable papyrus logging are there any stack dumps in Documents\My Games\Skyrim\Logs\Script\Papyrus.0.log?

Actually this really is a bit odd. It only uses meshes for LOD DynDOLOD World.pas finds in the load order, so LODGen.exe should see them too. Since you are using MO files like f:\steam backup\steamlibrary\steamapps\common\skyrim\data\meshes\lod\rocks\rockl04_lod_0.nif are actually in f:\steam backup\steamlibrary\steamapps\common\skyrim\mod organizer\mods\something and those are virtualized to f:\steam backup\steamlibrary\steamapps\common\skyrim\data\ In MO, the right window, open the "Data" tab, unfold [+] meshes and check for the meshes it can't find. They have to be there. Set a dedicated output folder like f:\output May have to do with the MO version you are using. Check its logfile for files access errors, simply search it for the missing mesh filename

No problem, it is always good if we can solve any issues no matter the cause.

Lets do some targeted troubleshooting: Papyrus Util 3.0, update to PapyrusUtil 3.1 3.1 Fixed a bug causing CTD during save load for some users RaceMenu 3.2.0, update to 3.4.4 3.4.4 Fixed string erasure bug causing co-saves to lose data 3.4.3 Fixed rare case where if a string could not be mapped to the string table at save time it would corrupt the save 3.2.2 Fixes NiOverride occasional crash when loading other saves of the same session

Please let me know if starting a new game (simple coc whiterun from main menu would suffice) works without any error. In TES5Edit you could check for the form id of 'Tamriel_ShesonObject' in DynDOLOD.esp \ Worldspace \ 0000003C \ 00000D74 \ Persistent \ xxxxxxxx It is usually near the top as it is added first. Convert the hex formid to integer without the first 2 load order digits. So change AA1234EF to 1234EF = 1193199 and look up the integer in DynDOLOD_Tamriel.json, there should be a line like "master":[yyy], and yyy should be that integer. If that is the case the game could not read the json for whatever reason. If the integer does not match either the esp or the json is outdated.

The files that are reporting missing are part of DynDOLODs archive data folder. Install that again. If using MO do not close TES5Edit until LODGen.exe completed. Any other mods or plugins you updated in the meantime? INI changes maybe? Which PapyrusUtil (skse/plugins/storageutil.dll) version are you using? 3.1 Fixed a bug causing CTD during save load for some users. We know 2.8 was stables over months. 3.0 was only short lived. Do you have NetImmers Override (skse/plugins/nioverride.dll) - it is also included in Racemenu - installed and have you generated with any glow LOD? Version 3.4.4 Fixed string erasure bug causing co-saves to lose data Version 3.4.3 Fixed rare case where if a string could not be mapped to the string table at save time it would corrupt the save If you enable papyrus logging are there any stack dumps in Documents\My Games\Skyrim\Logs\Script\Papyrus.0.log?

Can you watch closely for any other message top left before that? Are you sure the esp and the generated json files match? You can always do the update cycle anyways, go inside interior, save, start game without esp, save, start game with new esp.

LODGen.exe generate static LOD into that folder. Check TES5Edit\TES5Edit_log.txt for errors. Edit: LOL I meant TES5Edit\LODGen_log.txt Again, I suggest targeted trouble shooting. The underlying cause will most likely still be present. DynDOLOD doesn't change uGridsToLoad.

DynDOLOD is neither a script heavy mod nor does it corrupt saves. I suggest more targeted troubleshooting before jumping to conclusions No problem with DynDOLOD installed.

You always have improved static and tree LOD. The MCM is only about the dynamic LOD. Do you have waterfalls, windmill fans, fires in the distance? If you do its a mystery but hey :)

This is really weird. If all script instance are removed there should be no old data interfering. Everything gets new form ids each generation (unless you delete DynDOLOD_next-object.fid) to avoid overlapping of old data anwyays. Just a hunch, can you rename the *.skse save file with the same name as the *.ess cleaned save to further remove old data when loading the new esp? The latest script I posted may have printed out messages to the papyrus log. Can you check? What does the MCM page information show? You are reporting a CTD. Read the FAQ. So the current beta seems to create some form of invalid data with some mods. The invalid data is always there. Regardless of DynDOLOD trying to use it or not. This needs to be reported on the WB thread. Did you check the patch for errors in TES5Edit, nothing shows I guess?

You can only ever turn it off outside in a worldspace that has dynamic LOD. If it is already of for whatever reason just proceed. If you are going to use the save game cleaner anyways it doesn't really matter anyhow. Not sure what you are asking,. DynDOLOD does not require any other mods. If you have mods that modify the worldspace by adding objects with (new) LOD or if you have mods that add/ modify the base elements of these objects they will end up as masters in DynDOLOD. Rocks have LOD. You have mods that add/modify the base elements of rocks. The three mods you listed are fine and cause no error.

It seems the error message somehow sticks through the saves, though it should be overwritten with the success message when new esp/json is present. The long start up delay with the AI mod is only when you do a coc from main menu. 3DNPC has the same effect. I assume this is because the game is not correctly starting when doing coc from main menu for testing purposes. I do not think it means anything for normal games starts and play through. The steps from PRieST seem fine and should work for any case. I can not judge the quality of LOD tree billboards others created :) But you can adjust the overall brightness of the tree LOD. Click through to advanced and change the LOD Brightness drop down. Uncheck all Generate Static LOD, Create texture atlas and Generate DynDOLOD and it will only update tree LOD, which should be fairly quick.

ATM I have no idea why one save would be different form the other. I am also pretty sure the number in esp is not something that gets backed into the save. I will test that again - checked: It always reads the new number from the esp. If you do the save game cycle before, take the save without the old esp and before adding the new esp check it with a save game cleaner and remove all remaining scripts. Edit: The latest version of the papyrus script adds a 4th MCM page called Information that shows the numbers read from the esp and current worldspace json files. It only becomes visible when doing the save game update cycle - which is required for new generation anyhow. Great. Can't help with the other ::