dunc001

Nice work on the persistent records toggle. I may just have to overcook things again just to test it! After the previous discussions I stripped out four or five mods and have been running 'lite' ever since :P

I may be wrong but in the MCM menu in the latest version you can toggle all of the aforementioned things - strangers are strangers until you have spoken to them, no naming of corpses or dragons.

Try installing an ENB. I had this a while back and changing the ENB binary for an older one fixed it with just ENBoost, actually installing a complete ENB with latest binaries also solved it. Edit - Hang on sorry, just realised you were talking about ILS, I was getting a CTD on all alternate starts or on entering Helgen Keep on vanilla start. Yours is a different issue. As Paul said, ILS is usually an OOM issue so look to your Crash Fixes install and ini.

Likewise, and autodetect has never displayed an incorrect value for me. Just saying

Guys, seriously - VRAM test tool/subtracting 170/blah blah blah - none of this is needed. Just set AutoDetectVideoMemorySize to true. I have had this set for months as per advice from Hishy and it works perfectly, you'll see the video memory size displayed on the menu screen when you see the ENB info pop up in the top left as it initialises and I'll guarantee it will always show the value you'd have arrived at setting it manually. The added benefit is that if you are dual booting say Win7 and Win10 it will adapt itself as required.

Congrats on the new guide! I am really liking the format - guide layout, modular patches, etc. Extremely well done both of you.

So here you go: So in the case of Persistant my working load order currently has 52231 records. The strange thing is the last thing I removed before it finally loaded again was Vigilant which only adds 18! And DynDOLOD.esp contains more than Skyrim.esm! Does this discount override records (ie are these counting unique records or could the same record be being counted every time it appears in a new esp?) And in case it's Worldspace in general:

That would certainly explain it. I'll try tonight running the count on everything in Tamriel>Persistent and see what that returns (assuming I can run it on REFR that is?).

OK, so running the script on Tamriel on my full load order (excluding DynDOLOD as I still have it to regen) there are: 7314 ACTI records 141511 STAT 115865 TREE 3774 CONT

Well if you want to be complete about this (and you REALLY need the space) what you could do is use SPLUFF to extract everything in your Mod Organizer virtual /Data directory which would basically make a complete copy of every file which is actually being used in the game. Then place that last in your load order and activate it so everything is overwritten. Then go ahead and delete every original mod leaving just the one giant combined mod. Any mod which subsequently updates you would just install as normal after the combined mod, hide anything you don't want and let the rest of the new files override. This does however completely negate the whole point of Mod Organizer :P Just saying, because you can :D The irony being of course, that you actually need enough space in the first place to be able to make the copy before you can then use that copy to free up the space...

So I can confirm that DynDOLOD itself is not the issue. Nor it would appear is Holds. It seems that just as per THIS thread over on reddit I actually am hitting some kind of ceiling. Here are the results of the past hour of testing (DynDOLOD Tamriel only): Full load order including Holds and DynDOLOD - CTD Full load order without DynDOLOD - New game starts fine Full load order including Holds and DynDOLOD, deactivated Wheels of Lull, Forgotten City and Dreamborne Isle - New game starts fine As above but reactivated Wheels of Lull and Forgotten City - New game starts fine As above but reactivated Dreamborne Isle (so full load order again) - CTD Deactivate Wheels of Lull and Forgotten City, leaving Holds, Dreamborne and DynDOLOD active - New game starts fine I could keep testing activating and deactivating other large mods but I don't think there is any need. This appears to confirm the suspicion that there is some kind of arbitrary limit beyond which, without any hint of OOM, the engine just doesn't want to play. So whilst this is frustrating it does provide a simple solution. I will just remove three or four of the big expansion mods to give myself plenty of headroom and play them on a seperate build. Sorry that I have taken so much of your time on this. I am just glad, nay delighted, that I can actually get on with playing with both Holds and DynDOLOD active!

OK, I'll try this evening. In the meantime if you have a hotline to Meh it would be extremely useful to get anything he can provide on the crash address... BTW, thank you for taking so much time and interest in my most unusual of issues. It goes above and beyond [tips hat]

OK, well I'll spend some time trawling through the records in Holds.esp and maybe adjusting load order to see if I can turn anything up. Still not really getting why this would be the case if it all runs OK when DDL isn't in the load order though. Surely if DDL is forwarding the last override in each case then this will still be the same whether DDL is present or not?

Yes, tried starting the game in all combinations - Holds/Hold Patches/DynDOLOD; Holds/DynDOLOD; Holds/Holds Patches; Holds - loads fine with Holds and/or Holds Patches as long as DynDOLOD is not active. I can't really sort anything after DynDOLOD as most are masters to either my CR and compatibility patches or to BP/ASIS/Grimy/DSR. VIGILANT has been in the load order for a while, before the recent addition of Holds, and hasn't ever been a problem with DynDOLOD before. What does DynDOLOD have to do with navmesh BTW? Not sure why this would cause an issue when the complete load order loads up fine otherwise?

Latest version - 0.0.3 Patches used: USLEEP, VIGILANT, The Notice Board, NSUTR, Interesting NPCs, Helgen Reborn, Frostfall, ELFX, ELFX Exterior, Bijin AIO, Arissa, Falskaar I found errors in several of the patches BTW, Holds.esp formIDs weren't forwarding correctly in several patches, Dawnstar being renamed DawnstarDUPLICATE by the 3DNPC patch, etc. I fixed all of these, and as per the Holds OP I left the patches (merged) deactivated while running DynDOLOD generation. I have re-downloaded Holds and the assets in case it's a corrupt asset issue. I'm fairly sure it will be an issue on my end and that you won't be able to reproduce it. 2 questions - does Skyrim have some sort of 'cap' on the number of records it can handle that wouldn't necessarily manifest as an OOM issue? - Is Meh likely to be able to tell us what type of crash the address points at?

OK, another night on this and I might be getting somewhere - although I don't understand it! After much testing and editing of DynDOLOD.esp itself without anything conclusive I end up with this summary - if I have both Holds.esp and DynDOLOD.esp active in my load order I have the CTD. If I disable one or the other the game loads fine. And it makes no difference whether Holds is included in the DynDOLOD generation or not, and by that I mean if I exclude it from DynDOLOD generation and try and activate both together I still get the CTD. Which brings it back to is it a memory issue? But if so then why am I seeing absolutely no indication in SPM prior to the crash, not even a slight ramping? Believe it or not I have had heavier load orders before which haven't suffered with this - at one point I had full SRLE Extended plus REGS plus Rigmor plus Summerset plus other worldspaces, and it never once crashed with DynDOLOD. So why am I getting this now? I am about at the limit of what I can test and look for. If you have any way of getting in touch with Meh then the crash is always exactly the same, completely repeatable, and doesn't alter regardless of what I have active or not each time: This is with a fresh run of TexGen/DynDOLOD running generation only for Tamriel, nothing else.

Grim Grass had already been updated to 3.1 with the errors fixed Darth

Try disabling the chandelier meshes in SMIM and see if that makes any difference.

OK cool, but you'll have kittens when you see the merged_maps ;)

Well I could but I don't think it would be much use to you unless I also load up my various merged plugins which are still masters to DynDOLOD at that point.

I spent three and a half hours on it last night. Started by removing all other worldspaces - CTD. Removed everything but persistent from Tamriel - CTD. Removed all overwrite records from persistent - CTD. This left me with just the DynDOLOD unique records in Tamriel>>Persistent. Then started reducing by halfs, which took forever at 8 minutes a time to xEdit/save/load game/crash. I finally got it down to what I thought was a range of 256, then 128, 64, 32, 16...and finally no crash. So I added back in the last 8 records I'd removed to confirm the range of records containing the issue and it bloody loaded! So I added a hundred or so more records back in and it still loaded! Adding more back in I could induce the crash again but I now have no idea what's going on! I'm going to try again tonight, and will try generating without the one or two mods enabled which I suspect are the root cause (most likely the Homes and Locations merged plugin, although I can't see why as this has been included in numerous previous generations without issue). Anyway, I'll persist as there's no way I'm going to let this get the better of me...

OK, I'm on with this now. So should I only be focusing on methodically removing worldspace records? My DynDOLOD.esp also has Activator, Container, Door, Furniture, Keyword, Moveable Static, Quest , Static and Tree in it. So far I have removed everything from Worldspace with the exception of Tamriel Persistent, and from that I have removed all carried forward records so only the ones contained only in DynDOLOD still remain, and it is still crashing. I'll carry on thinning.

I have previously adjusted the Custom Memory block size in Crash Fixes. It is set at 150, and that gives me 80-95%. And the 1280 figure was not something I ever used - I think it was a hang over from an earlier desperate attempt to get something working! Bashed Patch isn't a master for DynDOLOD. I've been focusing on the Holds patches and found issues in several of them which I have corrected, but I don't think that has been the issue as the patches merge was disabled when I ran the current generation. I'm going to test another hunch, and if it doesn't bear fruit I'll follow your instructions on narrowing things down in the DynDOLOD.esp. Thanks for taking time to assist, much appreciated.

Update - OK coc whiterun from Main Menu doesn't cause a CTD, but does end up in an infinite load screen. I'm using Skyrim Unbound though so could be something to do with that?

That's exactly what's happening (with a very slight pause of maybe a second) This is my current SKSE.ini: [Display] ;fix for problem with overlay texture like tatoo iTintTextureResolution=2048 [General] ;Skse try to clean unused script, can't harm anything ClearInvalidRegistrations=1 ;show missing esp when you try to load a save EnableDiagnostics=1 ;Sheson memory patch ;[Memory] ;DefaultHeapInitialAllocMB=1280 ;ScrapHeapSizeMB=512 ;[Debug] ;WriteMinidumps=1 So yep, EnableDiagnostics is on. Using Crash Fixes hence memory patch commented out. Like I said I know there are no missing plugins/masters/critical errors as the game starts perfectly every time without DynDOLOD activated. OK, I'll give that a try Yes, been on with this build for about six months, know it pretty much inside out. Been through them all again and there are no new errors I can see. I have one or two navmesh errors which have been there forever and never caused an issue before. No, I haven't changed the load order. I'm running Paper World Map as I mentioned, and I have tried both running DynDOLOD without it enabled and enabling it afterwards, last in load order as PWM OP states, and also tried generating DynDOLOD with it active then cleaning masters, which removes PWM, and moving PWM below DynDOLOD. I'll try sort masters anyway but I doubt it will make any difference. Papyrus scripts are latest version and PapyrusUtil Modders Resource is placed pretty much at the bottom of my left pane and is not being overwritten by anything. https://drive.google.com/open?id=0B1L2ydV_CsIVSk03NHYtbFk2dlU That log I think contains the last few generations. You'll find one error about Worldspace bounds out of range. This was in one of the Holds patches I had merged. I assume this is a wild edit, and corrected it in the merged plugin prior to the next run. Initially the Holds patches were included in a merge along with all my other compatibility patches (plugin named One Patch To Rule Them All.esp). Latterly I removed them from that merge and they are now in Holds Patches.esp so I could test various combinations of running the generation with and without them included. I hope something in there helps because this one is driving me nuts!