sheson

ENB only puts out log.log but nothing about ENBoost as far as I know You can use task manager and look for enbhost.exe, sort by memory easy to spot while it grows together with texv.exe If memory servers me right it needs ExpandSystemMemoryX64=true and ReduceSystemMemoryUsage=true and also EnableUnsafeMemoryHacks=false EnableUnsafeMemoryHacks=true is loading the texture away from tesv.exe right into the graphics card without using enbhost.exe. This will make alt-tabbing non functional and only work with windowed.

Based on this screenshot you shouldn't need a memory patch or safety to load since the first block is not used up yet. Keep an eye on it while running around in game. Maybe test with skyrim performance monitor and see how memory and vram usage changes when it crashes. Also, my fullscreen or windowed skyrim is not crashing when alt-tabbing.

Apparently there is a new SKSE version on the way which may have memory settings build in. https://forums.bethsoft.com/topic/1485263-shesons-memory-fix-ctdils-thread-2/page-2?do=findComment&comment=23286497

Please be extra careful in testing with lower than default settings of 256MB. At this time the effects of changing block2 in any way is not well tested and understood. Only go crazy for science. Sheson

Any memory patch dll shouldn't cause noticeable delays. ENB does though when you have lots of effects. The shaders are compiled and loaded into the graphics card. However, I am not sure if it still does that if UsePatchSpeedhackWithoutGraphics=true ? Any .fx file that comes with ENB and is not needed can be deleted and possibly reduce starting times. Even if some ENB graphics effects are used but the bloom effect is turned off the enbbloom.fx can be deleted for example. If you really know what you are doing you can even remove not needed parts from certain .fx files if for example only one of 5 presets is used. Obviously this all depends on the ENB used. Sheson

SKSE team says to use 2008 actually. A log would be indeed the best way to find the value for the first block. At the moment the value of the second block just needs to be high enough so the game starts or a save can be loaded. Simplified: It has 4GB to address. Pre-allocaing memory means we are reserving from this address space. Other parts/processes can not make use of reserved address space. It doesn't matter if the reserved address space is used or not (committed). NINJA EDIT: Any papyrus/script troubles I see happen because of high ugrids, or lots of actors/data not because it is out of memory. The engine can only work on so many items each cycle...

when you do tests with urgids just to see how far you can go... try this in console tll - to turn of distant lod, so you get a feel how huge a ugrid 15/17/19 area really is tb - to turn on the yellow borders combine those 2 while looking on at map Solstheim almost fits into 19x19 for real kicks, use tfc fly out to the edge and look across all loaded cell and not just

I updated my OP on ENB about how to find a good value. I am sure OP in this thread will have update soon. mod please update. :) You should be able to set the first block to any MB number you like. I see no reason it has to be in certain steps, though I am not 100% certain. Feedback would be nice about success/failure in that regard. Just make sure it is enough to never be filled 100% to avoid skyrim allocating additional blocks for the data that usually goes into the first block. There is really no use over allocating. If your setup only needs 300MB for that block there is no use reserving much more. In fact it would mean other processes and parts of skyrim can not use it for something else. That would be bad.

ENB Forum is back. It was the traffic from reddit that overwhelmed the server a bit.

For normal use and normal considerate modding 6GB seems OK of course.Windows will page out unneeded stuff to disk in case it needs to. The fact of the matter is, if skyrim has to deal with so much game data (actors, script) it will slow down to a crawl anyhow, or depending on caps simply not move more than X actors etc. It seems we are now at a stage, even with only a 32bit game, that not memory in itself is the limiting factor but CPU. It is not that CPUs are too slow but the game is not optimized to make use of the latest and greatest.

You are correct, it changes the way Skyrim allocates ram (not the amount it allocates). It is still only a 32bit application so it can only address 4GB. Part of the OS needs to be in that address space as well, that is why we have something that is refererred to as 3.1GB limit. I am simplifying here, but on 64bit only the OS parts that are actually needed to run the game take away from the 4GB address space available to the game. Kernel, DirectX libraries, all that stuff. So for example your browser and other background processes are not taking away from this address space. Enboost frees the 4GB address space even more shifting the textures to another process (enbhost) that uses its own address space. In theory this means with all this Skyrim can use roughly 3GB for itself including world and script data and another 3GB for the (compressed) textures because of ENBoost. 6GB + ~2 GB for OS makes 8GB really a minimum amount these days :) In reality I could not make tesv.exe use much more than 2GB, yet when testing with uGrids 19. ENBoost depends on texture sizes of course, but I typically stay around 2GB for enbhost.exe as well.

Uhm no :) SKSE got an email from me about it. It will just take some time. The good part is, that if SKSE is ever updated it will simply overwrite any modified dll with the correct and hopefully better ones.

Why would you remove or change my awesome ini setting? As punishment you will have to create the holy cow dancing animation. :D No clue what I am talking about? RTFAÂ