kyd462

Dragon Lord, I agree. It's been a very long time. Bethesda has always been a good sport about modding though, I wonder if they would share information about the settings if someone asked nicely? And yes, the LOD solution would be no surprise were the hardware running the game as old as the game. But the frustration isn't that Skyrim can't compete with other titles when it comes to displaying large open worlds, it's that Skyrim can't compete with other Bethesda titles, and it's the newest iteration of an engine they've been using for years. It should be more optimized than the previous games, they did say it would be (specifically in regard to realistic distance rendering). I actually doubt if the Creation Engine isn't still 90% Gamebryo. But it is what it is. Perhaps I will find a nice balance within all of the LOD settings at some point.

Keith, thank you for all your insight. It's been very helpful. I've got a few interesting things to share, but best of all... NO MORE STUTTER!!! Found some settings that got rid of it almost entirely! First on the list: iMaxAllocatedMemoryBytes... Another case of "woops, forgot to set everything back to default before testing a new line out." I blame the new gray hairs, but my wife tells me I've always been forgetful. I don't remember that ever being the case, so maybe she's right. But I digress... If you want some good fun, set this ridiculously high and start a new game. I had mine at 12884901888, and it was like bumper cars in Helgen! That much is repeatable every time, but sometimes you get some bonuses. Especially in combination with all the "thread" settings Keith warns about. A Thalmor floating up into the air while Ralof's head tracks him during his dialogue. A horse cart glitching so bad it topples over and never gets to its destination before the rest of the scripts start running. Then rights itself during General Tulius' speech and plows through everyone. lol... really great stuff. Well worth breaking the game to see. The Elusive Stutter Fix: This was so obvious, I would've faceplamed if I weren't so excited to see that it worked. When I say "worked", I mean that stutter is practically gone! I can finally ride a horse from Whiterun through Labyrinthian and back without even a little skip. But it comes at a small price, and leads me to believe there's a better solution that would take a lot more time testing. SkyrimPrefs.INI [TerrainManager] fTreeLoadDistance =57500.0000 fBlockMaximumDistance =200000.0000 fBlockLevel1Distance =50000.0000 ;Primary Solution fBlockLevel0Distance =25000.0000 ;Primary Solution fSplitDistanceMult =1.3 The settings above are averaged between Ultra and High defaults. The result in-game is actually very close to Ultra, hardly noticeable, but without any stutter. The two that mattered most were the "fBlockLevel" lines. I only altered the others to keep consistency with the new load distances of the others. Now, this particular solution assumed that decreasing would solve the issue, but I'm still testing to see if the inverse is true as well, but have yet to find a sweet spot that doesn't drop my FPS as well. I believe the major cause of the "bottleneck" that leads to stutter is in the engine's handling of LOD. These settings seem to affect mid-level LOD switching the most. For me, it is a little bit of a trade off. I always try to push the LOD settings to get a better view. I do notice that actors and scenery load just a tad closer than I'd like (I actually felt that Ultra's distances were just right, not perfect, but not bad either). Still, I use Dynavision, so at least most of the LOD switching is blurred in the distance anyway. STEP also has a few good LOD mods in the list that make certain things a little better as well. Finding this almost makes me want to dig even deeper now. I'm certain there's a combination of settings that could fine tune the whole LOD system to be a bit more graceful, and not have to sacrifice any distance to get rid of that stutter. Essentially, the goal would be to load as much terrain info as possible within a reasonable distance, and adjust the fade-in distances for low, medium, high to be more gradual and less abrupt. Of course, I'm pretty sure most of the control over LOD lies within the nif files themselves though. sigh... INI Categories and Such: Well, I did a ton of tests with this today, and discovered some useful stuff in the process. Categories DO matter. That's a fact, Jack. Juxtaposing settings from one category to another forces the engine to use whatever the default for that setting usually is, and the misplaced setting is just ignored. If anyone has any plans to compile an INI guide, then I'd say it's in everyone's best interest to determine exactly what goes exactly where. Order within a category DOES NOT matter at all. If someone says to specifically place fDefaultFOV at the bottom of the [General] section, feel free to disregard this and place it between iHWThread3 and iHWThread4 if you like it there. As long as the setting is in the correct category, it doesn't matter where it appears in that list. (Most) Settings only work when placed in the correct INI. Earlier I'd mentioned that fDefaultFOV didn't need to be in SkyrimPrefs.INI to work correctly with the FOV solution, that it could go into Skyrim.INI and work just the same. This is true. However, the reverse is not true. fDefaultWorldFOV and fDefault1stPersonFOV will have no effect if placed under [Display] in the SkyrimPrefs.INI instead of Skyrim.INI... So, one setting is interchangeable, but two others are not. Strange but true. So, again... it may be helpful to determine exactly what goes exactly where, however... Gobbledygook is completely ignored in these files. If you want to add "bICanHasCheesburger=1" to your Skyrim.INI, go for it. If you want add "iNumDamnsGiven=0" to your SkyrimPrefs.INI, you can do that too. It will do absolutely nothing, but it won't break anything either. So what, right? Here's why that's cool for everyone... It's not always clear whether a setting is supposed to go into Skyrim.ini or SkyrimPrefs.ini or both, just like every previous Bethesda game before it. But the good news, after hours of testing today, I think it's safe to say that a solution of the past holds true today as well. If you really want to go crazy experimenting with INI stuff, you can essentially combine all the settings into one master file, then copy the contents into both INI files. Yes, one will overwrite the other when it comes to certain settings. Yes, the game will mess with these files itself from time to time, same as when you start the launcher and change something. But it doesn't break anything that I've seen, and I've double checked the important lines to make sure they are still active and behaving the way they should over quite an extended play-throughs. This isn't magic, and it's not anything that's going to improve performance for you in any way. All it means is that if you really want to see if something works, but aren't sure which file it goes in, put it in both. If it works at all, then it will work. Same is true for categories. Not sure if a setting belongs in [General] or [Display]?... put it in both. One isn't going override the other, because one just flat-out won't do anything if it's not in the right category. Just keep to the syntax and basic rules though. You still can't type sentences without the comment designation ";", and it's still not good to put comments on their own lines, etc... So, that's all I've got. Maybe it's useful. I know it's a massive digression, and I do apologize for that. It just all stemmed from the same topic, so I just went with it. But I think it ended on a high note with a solution to the original problem, a follow up on some sub-topics, maybe some useful info, I don't know. Thanks a bunch for the hospitality and all the help. I'll come back if I find anything else that might useful while I still have the time off to do so. Been waiting to play this game for a long time though, so we'll see. Maybe it'll turn into a "weekend warrior" type thing. Cheers! Happy Holidays! All the best!

Sorry to bother with so much "old news", Keith. I'm 100% new to this particular game, and have some time off before going back to work soon, so I thought I'd share a new perspective and maybe learn some new things about the new engine. My days of scouring the internet, sifting through crap to find a diamond have passed. STEP seems to know their stuff, or at least how to go about finding it, so rather than going round taking everything for granted, I came here to get your insight and confirm. This is why I ask questions, and want to know detailed information from people who have tested these things themselves. I feel like you're reading my posts with a voice in your head that makes me sound like a hyper-active 12-year old who's just learned that ~ brings the console up in practically every game since somewhere in the 90's... {mind blown} I was a QA tester at EA for 7 years, so I can assure you it's not uncommon to get stuck in the mindset that "everything that's been tested is true and will always be true", then some punk figures out that an entire block of code works differently than even the programmer thought. lol. Unintended functionality they call it. So I apologize if challenging the accepted norm comes off annoying and redundant. I'm one of those people who likes to see things for myself before believing anything, especially on the internet, and especially when it comes to the functionality of games. One case in particular that I can share where old news is just that, and challenging it can produce new findings, was in the STEP guide itself under 3.B.1 Optimize Field of View. Changing the FOV in the INI does persist. Looking further into it, one can easily find out how with Google as well. In addition to the following lines in Skyrim.INI [Display] fDefaultWorldFOV = 120 fDefault1stPersonFOV = 120 You'll easily find that adding this to SkyrimPrefs.INI [General] fDefaultFOV=120 Allows the change to persist. However... personally... I found that you don't need to add that line to SkyrimPrefs specifically. You can add it under General in Skyrim.INI and it works exactly the same. And if you start a new game you never need to enter an FOV in the console either. Extremely small finding, I admit. Most of which can be found through Google in fact. But I hope it goes to show that not everything which is set in stone is infallible, and that rehashing old notions can be a good thing if you're goal truly is to be thorough and discover optimal configurations. Currently, I'm testing certain background loading settings in the INI files. One of them causes the horse carts in the beginning of the game to speed up and jump over large rocks in Helgen, turning around, flipping upside down, then eventually pushing the carts from the back. In one instance, Hadvar ended up inside my character's cart, never got off his horse, and asked me who I was while mounted on a horse inside the cart... Strange things. Seemingly unrelated, yet producing absolutely bonkers results. Same settings out in the world?... never noticed an issue anywhere at all. I'm about to pinpoint exactly which of the lines caused it, so I'll share that later today. It's pretty fun to watch actually.

Quick question. I'm nearing the end of my testing. I've exhausted nearly everything at this point lol. This is sort of off-topic, but it's related to helping me test the effects of INI settings combined with enblocal.ini settings, so I hope it's not too far off the mark. There's several sources for tweaking INI settings, and not all of them are consistent about what settings go where. My question is; does it really matter where anything goes? hahaha... I know it's logical that it should matter, but there's quite a bit of speculation out there about whether Skyrim.INI and SkyrimPrefs.INI are simply combined during runtime anyway. Essentially read and loaded on top of one another. Some even suggest literally working in one, then copy-pasting the entire contents into the other. This actually works perfectly fine for Fallout and Fallout NV, but I wonder if it holds true for Skyrim. So I'm curious if anyone has any insight about this or if anyone's tested it thoroughly. Also, for that matter, do the [sECTIONS] matter? Some say to put such and such under [General], while a default INI will list these under [Display] or somewhere else. Etc etc... For an INI, I see no reason for sections other than visual aid when editing the file manually. Most applications use parsing algorithms to find the value of specific settings. Coding to search for sections and then the settings seems too redundant. I'm tempted to remove the sections altogether and alphabetize the file just to see. I would bet it makes no difference, but many people say to put a line specifically after X, or between X and Y, or at the beginning or end of [XSection]. What I'm most curious about is combining the INIs though. If one really could just combine the two INI files and copy-paste the contents to either or, it would make testing and tweaking a helluva a lot less tedious if/when experimenting with INI settings.

Still only testing with Vanilla Skyrim (no mods whatsoever). One thing remains consistent throughout all my tests: I can increase stutter, but I haven't been successful with reducing it yet. By reduce, I mean beyond a baseline I've observed while running several dozen tests with vanilla skyrim, default INI, no ENBoost files, and only the SKSE mem patch enabled. There are specific areas (in fact specific coordinates within said areas) that always produce stutter, every time. It's not a matter of 2/100 times. It's reproducible every time. Some of these areas are mentioned in one of my previous posts above. Essentially, the goal of my testing now is to determine what, if anything at all, can reduce or eliminate these particular instances of stutter. So far, I've only discovered the ability to increase frequency of stutter to areas which are completely unaffected in vanilla Skyrim. The only observable benefit to using ENBoost that I've seen so far has been the total elimination of CTDs and freezing (with one exception where I pushed the game beyond any reasonable limit.) I recently stumbled onto https://www.nexusmods.com/skyrim/mods/48387/ which a vast majority of commenters seem to agree works wonders for solving their issues with various types of stutter and CTDs. I'm currently testing these settings out in combination with a baseline enblocal.INI (128/2048) and standard SKSE mem patch (768/256). I'm curious to know if anyone has thought about or tested the effects of iPreloadSizeLimit or iMaxAllocatedMemoryBytes in Skyrim.INI in conjunction with ENboost? I know STEP in general has a strict "Do not mess with INI files whatsoever" policy, but these do seem like the sort of settings that could have a dramatic effect combined with ENBoost. For instance: Could iPreloadSizeLimit actually be set too low by default for ENBoost to have any real excess of data to manage if one isn't using any mods. And if that's the case, could the baseline performance of Skyrim be improved before/without the use of mods. Imagine if it were possible to configure a perfectly smooth-running Skyrim experience. That sort of environment would be a huge deal for testing the performance impact of mods, because if if anything changed negatively you'd know for certain it was the mod that caused it. Anyway... I understand most players have probably moved on by now, or soon will, but I'm still on a mission to learn what I can to get the game running as best as possible before committing to a 300+ hour playthrough. :)

Thanks for your informed response, keithinhanoi. I removed the thread settings from my INI, and adjusted my enblocal.ini settings according to your recommendations. My performance and overall smooth experience was significantly worse. Increased cell load stutter, increased overall stutter, terribly stuttery during combat. It was worse than if I'd simply removed ENBoost altogether. I would go so far as to call it unplayable. By "stutter" I hope I'm referring to what I think everyone else is: Sudden and brief stops/stalls (like a frame or two was skipped or paused briefly) while moving around the open world. It almost never happens indoors. As I've said above, there are specific areas that will always do this regardless of any settings, but the effect can be increased with certain settings, never decreased it seems. I call this "load-stutter" because it only happens when assets are loading (visibly apparent by scenery and NPC fade-in and pop-ins, sudden changes in NPC behavior, etc...) Now, there is another sort of "stutter", the kind I would usually use the term for (and occurs in many other games with improper settings or hardware that isn't up to the job). That's when it feels like only every other frame is being rendered. It's hard to look at without getting dizzy, input is laggy, overall experience feels like the game is struggling to run. I get this sort of effect with the settings you recommended in addition to the other variety of "load-stutter". Previously, the game wouldn't even come close to running like that until I'd spawned my 60 guards and 4 dragons at the docks. I know the first inclination would be to assume it's perhaps a hardware issue, but this system is in perfect running condition, and has no problems running anything else I throw at it but this game. For work, I'm constantly running Adobe Premiere, After Effects, and Maya simultaneously while rendering complex scenes and/or video (typically out of 2 applications at a time with live-preview enabled) and watching an HD movie and browsing the web without even a hiccup. My rendering progress bar smoothly tracks from left to right without ever stopping to think. If swapping from Ram to Vram to Hard drive and any combination of them had a bottleneck somewhere I would have noticed by now. But this game... ooooh... fine-tuning the performance of this game has become an obsession. lol I'd like to know more about the ideal performance scenario for Skyrim to give it the best conditions to perform under. Is it more efficient when RAM is being utilized at a higher capacity than VRAM or vise verse? Is it best at swapping smaller amounts of data, larger amounts? I can shift the balance between RAM and VRAM on the performance graph quite a bit, but what does Skyrim like best? Under the "perfect scenario" I'll just have to accept that the game runs like crap sometimes all on it's own and just can't be helped. But I'm encouraged to keep trying anything because I read for some people certain things have made their game "completely smooth", that stutters are "practically non-existent", or that "loading pop-ins etc aren't even noticeable anymore". Is this just cognitive dissonance? Placebo? hahaha

No problemo! Done and done! Edited the post with settings comments and a detailed run through of my test routine.

Thank you for your reply, Dragon King. I've returned to that guide many times in the last couple weeks, but my primary issue still remains. I believe the inevitable answer is that macro-stutter and pop-ins during cell-loading is just an unsolvable fact of Skyrim's engine. Neither ENBoost nor SKSE provides the solution for that, so I will look into what INI settings may achieve, like in previous bethesda games. EDIT: Significantly improved performance and reduced stutter/pop-in with the following settings. Namely the Skyrim.ini settings combined with enblocal.ini settings. System Specs above... Performance especially improved during combat, with only occasional minor stutters when NPCs switch from passive to aggressive. It's easily repeatable on NPCs specifically coming out of idle behaviors mostly. Probably just a quirk of the engine. Occurs with or without any adjustments to settings. Skyrim.ini [General]iNumHWThreads=8 ;Telling the game I have 8 cores wasn't enough alone, but needed for below. iHWThread6=6 ;Default has 6,5,4 sharing work with iAIThread2HWThread. iHWThread5=6 ;So I offloaded that work to 6 (aka '7' based on sequence starting at 0). iHWThread4=6 ;The reason being that allegedly Bethesda accommodates up to 4 cores. iHWThread3=4 ;Since '5' is nowhere to be found in defaults, I didn't want to chance using it. iHWThread2=4 ;I tried several variations. Only measurable change is to threads 6,5,4 iHWThread1=4 ;By offloading 6,5,4 to a new core, Threads increased by ten, and performance improved. iAIThread2HWThread=3 ;Again, no measurable difference by changing these at alliAIThread1HWThread=2 ;I kept them included at defaults to keep them the same.iRenderingThread2HWThread=1iRenderingThread1HWThread=0 bRunHighLevelProcess=1 ;Very slight boost when other applications are running. ;The following are purely speculative and based on 'feeling'.;When all are disabled the game feels more stuttery and sluggish to me.;Especially true when using the above changes. bMultiThreadMovement=1bUseThreadedParticleSystem=1bUseThreadedBlood=1bUseThreadedMorpher=1bUseThreadedTempEffects=1bUseThreadedTextures=1bUseThreadedMeshes=1bUseThreadedLOD=1bUseThreadedAI=1 uStaticNeverFade=1 ;This was recommended elsewhere. I honestly can't tell if it has any effect. bUseHardDriveCache=0 ;Increased HDD access when enabled, bytes used unchanged. Impact is nil [Decals]bDecalMultithreaded=1 ;Same as bUseThreadedETC... abovebForceAllDecals=1 ; Slightly less stutter frequency, but a little more 'punch' when it does happen. Everything else is default except for Interface, VATS, Gamma related settings. ENBlocal.INI[MEMORY]ExpandSystemMemoryX64=trueReduceSystemMemoryUsage=trueDisableDriverMemoryManager=falseDisablePreloadToVRAM=falseEnableUnsafeMemoryHacks=falseReservedMemorySizeMb=512 ;1/4 VRAM, STEP Extended installed. All is well. Avg 50-60fps in most areas.VideoMemorySizeMb=16384 ;Standard RAM+VRAM-2048 suggestion. Makes no difference I can observe.EnableCompression=false ;This particular setting is critical to my smooth experience*AutodetectVideoMemorySize=false *With compression enabled, I experience a lot more stutter, and an overall laginess like my hardware is struggling, despite the logs and graphs suggesting everything is fine and still well under load capacity. Still plenty of room to operate safely as well with it turned off. This combination runs smooth as silk, apart from infrequent minor stutter caused when loading cells and large amounts of assets, but those areas are isolated. The area around Whiterun and that entire field is still fairly choppy to ride through on horseback, but getting away from there reduces my load-stutters almost completely. I guess there are some areas in the world (like all bethesda games before it) that are just poorly optimized and will cause hiccups now and then. [EDIT:] My test run is as follows: From a Clean Start Save (No Mods / Essentially STEP 2.D up to Unofficial HighRes Patch) outside of the cave immediately after completing first quest out of Helgen. TGM + Player.setav Speedmult 200... Switch to 3rd person with two drawn swords (because it looks cool running like that. It really serves no purpose. lol). Sprint to the nearest bandit cave, kill the bandit, kill the wolves, run through Riverwood, cross the bridge, round the corner to the right. [NOTE] Whether it's 100% vanilla, SKSE mem patched, ENBoost, 300 mods... doesn't matter. There will be two brief stutters. One immediately after rounding the tree stump, and another shortly after. Not surprisingly, two wolves appear down the road chasing a bunny after that. I'm 99% sure that is a scripted event. Doesn't happen often with other encounters. [/] Kill the wolves, sprint forward, catch up with imperials walking a stormcloak prisoner. Free the prisoner, give him loot from Helgen, kill everyone (why not? it's just a test). Sprint to the stable, steal a horse and ride it all the way through Labyrinthian, right off the ledge (killing the horse). Run around outside a bit, go back in and fight some trolls, then sprint back towards Whiterun. [NOTE] Whether it's 100% vanilla, SKSE mem patched, ENBoost, 300 mods... doesn't matter. Riding a horse from Whiterun to Labyrinthian is the most stuttery experience I have had no matter what. It's a good trip to take though, because it tells me right away if anything I've done has improved my core experience issues at all or made them worse. Sprint down the road and across the bridge near Whiterun. Fight the guard on the bridge, kill him, but don't kill the other that comes to help so I leave a hostile NPC instance in a cell. Jump into the river and sprint and swim to the bandit fort. Kill everyone, jump off the bridge into the water, sprint and swim downstream all the way to Windhelm docks. Spawn 30 Windhelm Guards, 30 Whiterun Guards, 20 Necromancers, and 4 Dragons... Fight a laggy 18-35 fps battle for a good while until everything is dead. TCL + Player.setav Speedmult 600... Sprint (or fly) back up the river to Riverwood (because that whole set of transitions from cell to cell and all the waterfalls love to crash). From Riverwood, speed back to Whiterun. Go inside, speed around, leave. Go back in, leave, go back in, leave. (This is aggressive. Must want the game to crash!) Spam menu and inventory and exit before anything loads like a crazy person. After this, I try to fly to all the edges of the map, major cities, buggy areas especially, back and forth, swinging view quickly to try to catch the engine and hardware by surprise. If I can do this for a solid 5-minutes without completely freezing or crashing, then I boost the speed to 1000 and return to spots that froze a little longer than others. I do this for another 5-minutes. If it doesn't crash or completely freeze, then I dual cast fire spells flying as close to the ground as possible for another few minutes (sometimes the game crashes like this no matter what settings, but that's a lot to ask of it). If all goes well, then I go to Rorikstead, set speed down to 300, tcl back on, and run back to Whiterun, down the river again to Windhelm, and swim onto the docks. I take that path so often because it crashes so often (before at least). [NOTE] Just today I managed to complete this test, only this time I had the full STEP Extended lineup installed. It was a glorious moment when I made it back to the docks for the last time and didn't crash or freeze up before even making it to Whiterun.

This posters recommendations are wildly different from anything else I've seen on the ENBoost topic (and I've been researching the heck out of this for entirely too long at this point), yet I figured "what the heck!" and tried it anyway since it doesn't seem anyone has a real firm grasp on the proper settings to use. I had to add my two cents to the mix and say, this actually produced the most consistent results for me. I understand his settings essentially negate ENBoost, but still... my game still ran smoother than it did without ENBoost, so there may be something to it. But it's still not as smooth as it should be. I apologize for the wall of text, but I really would like some help learning what these settings actually do, and how to begin honing in on the proper settings for my system. Hence, here is all the system and configuration info I could provide off the top of my head to paint a clearer picture. I see far too many "these are my settings" posts, and far too few "this is the system I'm running" details to go with them. It makes all these numbers seem so arbitrary. SYSTEM: Win 7 64bit WD Caviar Blue HDD 7200rpm CPU: AMD FX 8320 8-Core 3.5Ghz GPU: Nvidia GeForce GTX 660 2GB RAM: GSkill 16Gb (8Gbx2) 1600 SETTINGS: GPU is handling Vsync + Triple Buffering + 60fps Frame Limit + 16X Anisotropic Filter + Ambient Occlusion Skyrim is handling Antialias @ x4 MS ENBoost is handling... I'm not sure yet... allegedly memory management in some way... Skyrim.INI and SkyrimPrefs.INI are Vanilla Ultra with only minor tweaks for UI, VATS, etc [Papyrus] - What SkyrimLauncher.exe produces as DEFAULT SETTINGS.fUpdateBudgetMS = 800.0fExtraTaskletBudgetMS = 800.0fPostLoadUpdateTimeMS = 2000.0iMinMemoryPageSize = 256iMaxMemoryPageSize = 512iMaxAllocatedMemoryBytes = 2457600bEnableLogging = 0bEnableTrace = 0bLoadDebugInformation = 0bLoadDebugInformation = 0 [Papyrus] - Current Settings fUpdateBudgetMS = 1.6 fExtraTaskletBudgetMS = 1.6 fPostLoadUpdateTimeMS = 2000.0 iMinMemoryPageSize = 256 iMaxMemoryPageSize = 512 iMaxAllocatedMemoryBytes = 115200 bEnableLogging = 1 bEnableTrace = 1 bLoadDebugInformation = 0 bEnableProfiling=0 Installed SKSE 1.7.1 Scripts + 512mb mem Patch and Steve40's ScriptFixes LOAD ORDER (Bare Essentials): Skyrim.esmUpdate.esmUnofficial Skyrim Patch.espDawnguard.esmUnofficial Dawnguard Patch.espHearthFires.esmUnofficial Hearthfire Patch.espDragonborn.esmUnofficial Dragonborn Patch.espHighResTexturePack01.espHighResTexturePack02.espHighResTexturePack03.espBashed Patch, 0.esp A) enblocal.INI (Based on CovertSlinky's recommendations) [MEMORY]ExpandSystemMemoryX64=trueReduceSystemMemoryUsage=falseDisableDriverMemoryManager=falseDisablePreloadToVRAM=falseEnableUnsafeMemoryHacks=falseReservedMemorySizeMb=2048 ;Set to exactly 2Gb (full VRAM)VideoMemorySizeMb=16384 ;Set to exactly 16GB+2GB-2048)EnableCompression=falseAutodetectVideoMemorySize=false B) enblocal.INI (Based on Nvidia 2Gb INI that came with old ENboost) [MEMORY]ExpandSystemMemoryX64=trueReduceSystemMemoryUsage=trueDisableDriverMemoryManager=falseDisablePreloadToVRAM=falseEnableUnsafeMemoryHacks=falseReservedMemorySizeMb=256VideoMemorySizeMb=1920EnableCompression=trueAutodetectVideoMemorySize=false I've tried installing STEP EXTENDED (using medium options when available) and it just bogs down my performance to near unplayable (30fps and below with increased macro-stutter during cell loading), despite meeting the requirements. So my tests have been whittled down to STEP 2.D until I resolve the root of these performance issues. After far too many tests just to make a game more stable to play, I've noticed hardly any difference no matter what settings I throw in there. However, CovertSlinky's recommendations have indeed given me the best reduction of macro-stutter (sudden stops when turning corners and loading new areas). This was all I was really after in the first place. But the trade-off is that the game just "feels" a little less smooth. By all other accounts it actually is more smooth though. It's strange. Oddly enough though, stats don't lie, and setting ReduceSystemMemoryUsage=false does seem to revert system memory use back to default. Making me curious if this is just placebo, or if there is more to enbhost.exe than just off loading ram use to vram. Does it simply improve the process of swapping between the two if you don't take advantage of it's ability to dump everything onto the GPU? I'm very confused because no matter what I never come close to hitting even 400mb of the 512mb ceiling enabled with SKSE. Even if I spawn 50 Windhelm guards 50 Whiterun Guards and 4 dragons at Windhelm Docks I don't use more than 400mb of that first block, and Performance Monitor backs this up. It shows plenty of headroom between my peak VRAM usage and the 2GB limit of my card... yet I still experience FPS drops, load-stalling/stutter, pop-in, etc... My HDD is hardly used at all too. That is odd to me. I thought ENBoost was designed to help with these issues, but it's so confusing to figure out how to configure it and what the settings actually do. I know many people say "results will vary from system to system, play around with it and see what works." But I can't subscribe to that mentality blindly. It's a program with specific parameters. Someone has to know how it's supposed to be used correctly, and how to interpret the configuration to adapt to other systems. The overall "effect" may vary, absolutely! But not the settings. That should be straightforward, A+B=C.