keithinhanoi

Yes, I was talking about trying to continue with your game save with so many changes in your load order - not recommended at all.
 
Keep in mind with the max actor AI setting, you don't have to use tonycubed2's numbers. In your normal playing watch for any situations where there are a lot of NPCs (probably fighting, like in the civil war, or in cities if you use mods that add NPCs) and some of them just stand there doing nothing. So bump up the max AI numbers moderately. If you use a bashed patch, you can always move the number down again by rebuilding the patch.
 
As for AutoSave Manager, that's exactly the mod I use for saves every 10 minutes. It does "manual" saves (instead of quicksaves), at whatever time interval you choose, in the background - which does cause a bit of a lag for half a second, but it's way less of an interruption than doing a manual save using the menu. I have read FlexCreator's report about quicksaves not being any different from manual saves, but I guess you can call me superstitious. Anyhow, AutoSave Manager can also be set to do "manual" or quick saves for certain kinds of events. All around recommended.
 
If you do choose to add a mod like AutoSave Manager, which doesn't really interfere with any other of your mods (because of no FormID record conflicts,) you could consider adding it to the penultimate load order slot, just before your bashed patch. That at least makes sure that the load order index numbers for all the plugins used with your already started play through won't change. Then there's the least likelihood of problems.
 
Basically my thinking with only adding new plugins at the end of a load order, or swapping out removed plugins with a place holder is this:
 
Data stored by scripts into your game save file is linked back to the originating mod using the mod's plugin load order index number. If you change your load order, say by adding a new plugin somewhere in the middle of your load order, all the plugins after that new one will then have different index numbers. I fear the script data may not get properly updated to the plugin's new index number, and so the stored data is effectively lost, and a new set of data has to be stored by the script - which probably won't be correct, and then things may start not working as expected. I suppose what would be a good idea is to ask FlexCreator if this theory is true. With his PDT tool, you could actually test it out by comparing game save files before and after adding a new plugin in the middle of the load order. I just haven't had time to try that and consult him on this theory.
 
Ideally, though, you do all your load order changing / adding / removing with a "throw away" set of game saves, that are just for the purpose of testing. Then you "lock down" your load order for your actual play through. This means resisting updating any mods which make significant changes to their plugins, particularly with adding / removing scripted elements. A very difficult thing to resist if there are considerable improvements as part of the mod's updates.

The enblocal.ini looks fine to me, and although reducing VideoMemorySizeMb would be a good idea, that value of 18432 won't cause Skyrim to crash.
 
If running through the vanilla Skyrim launcher, without SKSE, then that rules out any influence of the Sheson Memory patch fix (because it's provided as part of SKSE if using the skse.ini settings), and you don't need Memory Blocks Log because it's only necessary to check on how the memory patch is working out in game.
 
Just to double-check though - are you using SSME (the other implementation of the Sheson Memory patch fix) by chance?
 
If not, then I only have one other suggestion at the moment -
 
I do remember reading on the ENB forums an issue for one user with Skyrim crashing at startup and they resolved it by re-installing DirectX 9.
 
ENB does hook into DX9, even if only using ENBoost, so that's something to try.

@TigerWolfe - If those two lines I mentioned in my previous are not in skse_steam_loader.log, then the heap block memory fix setting in your skse.ini wasn't read, plain and simple. Even your test with Memory Blocks Log confirms this.
 
So, I will go out on a limb and say that you have discovered your problem right there.
 
A majority of the times I've seen people claiming the SKSE implementation of Sheson's memory fix doesn't work either:
did not actually have skse.ini in the correct location, had not updated to SKSE 1.7.1, or had set Windows to hide file extensions, and accidentally saved skse.ini as skse.ini.txt (as Nozzer66 points out) SKSE will look for the skse.ini file in ... Skyrim/Data/SKSE/
 
Alternatively, if SKSE's script files have been installed as a mod in Mod Organizer, the .ini can be kept in there, in a subfolder named SKSE, like this:
 

 
I would suggest this method for storing the skse.ini because then you can edit it directly in MO - just click on the INI-files tab as seen in the above pic of the mod info window, and then choose skse.ini to edit right in that window.
 
Until you see those two lines in skse_steam_loader.log, and verified that block 1 can go over 256, there is honestly no use in looking at other reasons for the CTDs.
 
If your skse.ini is in the correct location but the heap size lines are still not appearing in skse_steam_loader.log let us know, and we can help troubleshoot why it's not working.
 
Good luck!
 
 
@Vulgar1 -
 
Regarding your iMaxAllocatedMemoryBytes setting - with absolutely no personal offence meant towards you, that is a ridiculously high number, and although not necessarily CTD-inducing, will almost guaranteed lead to Papyrus stack dumping, which means at best you get massive script lag, and at worst lots of scripts won't run or finish - in other words, things won't work as intended or expected.
 
I have just posted about this and the myth about another supposed "magical" game-fixing .ini setting in the Correct Enblocal Settings thread, here. I highly recommend reading it.
 
(Post edited to add one more reason why the SKSE implementation of the memory patch may not work - thanks to Nozzer66 for the reminder!!)

Disagree on the advice to raise block 2.
 
The truth is that the game never accesses more than 256 for block 2, even if you set it higher. Sheson tried to figure out why this is true, but that is still unknown. Personally, I've played with block 2 fully maxed out at 256 for hours without any CTDs.
 
Back when Sheson first introduced it and many people were running tests, it was found that for many people (myself included,) block 2 only needs to be raised to 512 when block 1 (as reported in Memblock) is set to either 768 or 1024. You will know that block 2 needs to be raised if you set block 1 higher and then Skyrim crashes on start up.
 
My advice is to keep Memory Block Log going until you've had a chance to run through a number of areas known to push the block 1 heap usage quite high, such as around Solitude and/or Windhelm.
 
However, based on your Memory Block usage log, your skse.ini is fine. Which means your crashes are being caused by something else. Perhaps your enblocal.ini / ENBoost settings?

Okay, that's very strange - I can't give you a screenshot, because it's now working properly!  :O_o:
 
Here's what happened.
 
Last night, the last thing I tried was to log out, and I still got the 403 error.
 
This morning, I tried viewing the issue tracker site when not logged in, and I can view the summary page and of the issues pages, etc.
 
I tried logging in with my existing account credentials, and for some reason I got shot directly to the MO page on Nexus Mods. 
 
So I went to the comments tag, clicked the Issue Tracker link (which points to https://issue.tannin.eu/tbg/modorganizer), and everything is now working for me while logged into my account.
 
Sorry to say I have no idea why, but I'm happy iit's resolved (for me at least).

I did a quick search, and Boris has not explained any requirement or lack of requirement of deferred rendering for the mist effect.
 
However, I have observed that any effects that won't work with UseDeferredRendering=false in enblocal.ini will be greyed out in the ENB in-game GUI, so I tried checking this with the Mist effect option.
 
Interestingly, when I turn turn off deferred rendering, the Mist effect option is turned off (even though it was set to "true" in enbseries.ini) but it is not greyed out and can be turned back on, as seen here:
 

 
Unfortunately, when I tried turning the mist effect on and off, I did not see any visual change on screen.
 
Therefore, it seems that deferred rendering is required to use the ENB mist effect.