sheson

Thanks, found it. Will be fixed next version. You do not have to wait for next version or generate again once it is out, just click the low res object in console like you already did, then type disable in console. It should not come back.

That is the form id from your screenshot. Unless the load order of plugins changed, there has to be a reference for that number. If DynDOLOD.esp is not at load order A7 anymore adjust the number accordingly. Alternatively, while in the game click the object that supposedly is the full model for which the LOD models shows to get its reference form id directly.

Tamriel_FirstbornActivators do not have objects in the world. I need the Editor ID of A70953B5 from the screenshot (made a typo earlier) which should look like LegacyoftheDragonbornesp_[form_id]_DynDOLOD_LOD

Do you mean Legacy of the Dragonborn? Either save game update gone wrong (test with a new game by using coc whiterun from main menu) or could be an object from a city child world needing a manual setting. Look up the reference a70963b5 in xEdit and let me know its Editor ID which looks like [plugin-name]_[form_id]_DynDOLOD_LOD If [plugin-name] is DynDOLODesp, look up that FormID by adding DynDOLOD load order id A7 in front of [form_id]. The Editor ID of that should look like [plugin-name]_[form_id]_DynDOLOD_TOWN. From the Editor ID we will know which mod and which original object the LOD is for.

DynDOLOD and TexGen are based on a very recent version of xEdit that you can download here. The only difference is that they do not prompt the user to select plugins at startup like xEdit does. So, you have to make sure all those plugins are already active in the correct plugins.txt (in MOs case that should be the one in the current profile folder) which the gets "symlinked" to the normal plugin location which usually is C:\Users\[username]\AppData\Local\Skyrim\Plugins.txt. xEdit, DynDOLOD and TexGen all write a logline "Using plugin list: C:\Users\[username]\AppData\Local\Skyrim\Plugins.txt" so you can verify which plugins.txt they are using. If all else fails with MO I guess you could try to copy the plugins.txt from the profile folder to that location. All 3 tools should show the same file in the log if they are all started through the same means with identical parameters. They should all behave exactly the same. Start the tools without MO to verify. Make sure DynDOLOD is not installed in any MO folder, not installed in any gamer folder and not installed in any special operating system folder like the Program Files folder.

Do a test with 'cow tamriel 8 -4' from main menu and then 'cow tamriel 0 -43'. The second loads into virtually empty cell with no references.

It should count each record once, regardless of its overwrites. Yes, 64k is the only number that would make any sense as a limit if there is one. Looks like something else is the limit. It could be the total number of 'current' loaded references. So 25 cells + 1 persistent cell - since you reported it crashes right when clicking "new" that seems unlikely. Though you could try to 'cow tamriel x y' into a deserted area in the border regions. It could also be just the real space all these records need for their data - not likely too though, since that would be the block1 for all I know.

Load the load order in xEdit. It should show the same error. The error message is self explanatory, this is a problem with the plugins load order. Use LOOT and a mod manager to fix the load order of plugins instead of editing the txt files. I suggest to follow a modding guide like STEP.

It is a tiny bit more complicated than that. Here is a script to count all references in persistent cells. If you are just interested in Tamriel, in the left pane click [+] to unfold Skyrim.esm / Worldspaces / 0000003C Tamriel then right click the 00000D74 persistent Cell and apply this script. Otherwise run it on Skyrm.esm / Worldspace It will count for each plugin and then have a total at the bottom.

The script is for xEdit. Load complete load order into xEdit. Right click on Skyrim.esm (or even unfold Skyrim and right click on worldspaces) in the left window, select 'apply script', then select 'new script'. Copy and paste the script, replace everything from the default, give it nice filename and let it run. Do it whenever, no rush. It it is just that you can use it to verify how many references for a certain type of base record are there to test your theory. Change the sig 'ACTI' to any other signature of valid base records, like STAT or TREE etc.

Maybe there is a limit of 65535 ACTIs per worldspace? Count them with a simple script like below. Just right click a worldspace and apply this unit userscript; const sig = 'ACTI'; function Process(e: IInterface): integer; var l: TList; begin Result := 0; if Signature(e) = 'WRLD' then begin l := TList.Create; wbFindREFRsByBase(MasterOrSelf(e), sig, 0, l); AddMessage('Total number of ' + sig + ' = ' + IntToStr(l.Count) + ' in ' + EditorID(e)); end; end; end. Edit: updated script so it counts a worldspace across all loaded plugins

Vanilla Skyrim LOD Billboards are always needed for every setup. Enderal also uses vanilla trees and it is not guaranteed that tree mods like Enhanced Vanilla Trees replace all vanilla trees or supply all billboards for them. Since you only have one tree mod it is really simple: It overwrites the base game (in this case Enderal which requires Vanilla Skyrim LOD Billboards and Enderal LOD Billboards). Any mod that replaces trees of the base game needs to have its billboards loaded after the billboards for the base game, since that is what the full model trees do to the full models of the base game. If the billboards for a plugin are always placed right after the mod itself, the load order is automatically correct. In MO mods with higher priority load after mods with lower priority. So your screenshot looks correct.

If you use Enhanced Vanilla Trees, its LOD billboards need to be after the Vanilla Skyrim LOD Billboards (which seem to be missing) and the Enderal LOD Billboards. The TexGen output needs to be after DynDOLOD Resources (it has no billboards and DynDOLOD output needs to after everything else.

Well, we know activators do not work outside certain cells dimensions. But I have never seen them cause trouble if they are placed outside that dimension. Currently I think the limit may be more general to any type of records. Maybe just to reference using any type of base records. With xEdit and some pascal scripts you could fill an esp with lots of records of a certain type quickly for tests. Personally, I am holding off spending any more time on the old engine and look forward to the problems of the new one - with the slight hope that such (memory) limits are just gone... I can dream right.

That is interesting, though on the r post they talk about another address, but otherwise I do agree. If you can just remove any mod of a certain size to make it load the has to be some kind of limit for some type of data the load order is reaching. I guess we will have to wait for Skyrim SE + some undetermined time for mods to catch up to see if we can get around the issue. I wonder if it has to with a max limit of data per worldspace, since you reported removing references from the world would make it load. Don't worry about my time. These kind of problems always peek my interest... in the end though it is a lot of poking in the dark.

I don't think it has anything to do with data from last overwrite being carried forward or not. I have generated with 0.0.3 Holds.esp complete with no patches but with the mods you listed you use patches for. One time holds being sorted by LOOT and one time with it being last. Never have a problem using new or coc. Seems to me there might be a third thing involved somehow. The CTD when clicking new can reportedly be a script problem as well, even harder to track down. My question now would be, if you generate with Legendary, USLEEP, Holds only, does that work?

DynDOLOD has nothing to do with navmeshes. However some CTDs are caused by deleted records or nav mesh problems. The problem may only happen because DynDOLOD.esp has data in the same cell where another mod has such broken data, even if the data is not in DynDOLOD.esp.

Skyrim works with 32 bit FormIDs. So it can handle 4294967295 records. Memory should always get you first. Meh probably could probably have a look what kind of function is at that address. I have long retired my virtual machines debugging setup. My gut feeling is either a deleted record or a record referencing something that is missing, or navmeshes causing a problem. That the available patches have errors and need to be disabled is a red flag. I will have a look and see if I can find anything. Using the (merged) patches or not makes no difference if I understand you right? Vigilant is a plugin that DynDOLOD ignores. You could do a test by editing \DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini and removing ", Vigilant" from the IgnoreModFileName= or remove Vigilant from the load order while generating. Whatever plugins were not part of the generation run should probably be sorted after DynDOLOD.esp when starting the game.

1) Upcoming version 2.19 will create static LOD billboards matching the lighting of original tree LOD better. To not have trees on the map either set LOD 16 to empty or turn off all static LOD on the map by setting in Skyrim.ini [MapMenu] uLockedObjectMapLOD=32 2) You only need to run TexGen.exe / DynDOLOD.exe. There is no need to run TES5LODGen.exe. 3) You can not optimize billboards for LOD8/16 any further. But you could optimize the 3D static LOD trees (the ones like Meshes\DynDOLOD\lod\trees\treepineforest01passthru_lod.nif) used in LOD4 by trying to remove a couple branches. But then they won't match as nicely to te full model. Check DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_tamriel_mesh_count.txt for which tree is used the most and try to optimize those first. One trick maybe to not set a few specific trees to not use 3D static LOD but a billboard instead. So there will be some closeup LOD trees using billboard, bit since they are mixed with the 3D LOD trees you may not notice. Can you let me know the exact version / installation options of Holds and any patches you are using, so i can test myself? Is any of the used plugins report any error at in xEdit?

Consider it last resort, but I can still look at the esp data, even if masters are missing just to see if anything sticks out. If you clean masters and supply the merged_map.txt files for the masters in use even better.

You can upload the "cleaned" esp that still crashes with the "few" records so I can try to replicate and have a look to.

Also Line by line disable, then test if it loads these 3 possibilities. Meshes/Textures folder so we are not confused by static/tree LOD SKSE folder which contains the data for the dynamic LOD objects All Core files including the Scripts, but also Meshes/Textures so that no scripting is active If you managed to narrow it down to a worldspace, try to remove data in batches. Typicaly the half things works the fasted. It can be the world or cell record itself. So try removing entire content first. You should keep the base records like ACTI, DOOR, TREE, STAT, MSTT because they are needed by references in the worldspaces. But if nothing else if left to remove. then try those as a hole. Use "Clean masters" function as well after removing data. You could also try to generate LOD for a reduced load order without the mods you find the most likely to not cause any problems. Just copy to a new MO profile and work of that. First see if only generating for Tamriel with full load order also has the problem. Then you save the time generating for all worlds, or you might find it only happens when some other worldspace is part of the generation which could also provide clues.

ILS is an indicator something just runs out of memory. Since you are not using memory patch, but crash fixes with UseOSAllocators=1 and our pre-loader, you may have to adjust CustomMemoryBlockTotalSizeMb while using CustomMemoryBlock=1. You may want to check its discussion thread for pointers - it just should not have ILS. You could also quickly check with old memory patch instead. Though the DefaultHeapInitialAllocMB=1280 seems unusually high. Did you actually derive that number from checking with Memory Blocks Logs back when it was active? On a first glimpse, try to generate without based patch. Your load order is quote big. Can you let me know which mods are masters in DynDOLOD.esp? If none of the above helps just yet, a quick method to narrowing down things is to make a backup of DynDOLOD.esp and then start removing certain data from the esp and see if anything changes. I would start by removing all Worldspaces not Tamriel to see if it starts only with it. Then remove all temporary cells, then the persistent cell. Whenever it it starts to load take note of what you removed last, restore from backup and remove only half of what you removed before that it made it work. You get the picture. No need to try to narrow it down to the last record, just try to remove as much data as you can while it still has the problem. Then let me know and/or upload that esp.

If a new save doesn't have the problem, do follow the clean save procedure. Go inside a buildings, save and remove DynDOLOD.esp from load order. Load last save, wait a bit, save again. Now enable DynDOLOD.esp and load last save. The problem should be gone.

Looks like a save game update gone wrong. Test if problem also happens with a new game by using coc whiterunexterior01 from main menu console and walking into the city.