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.

They look interesting - new locations, NPCs, and even some quests. Definitely worth checking out to see how much they overlap Unique Border Gates. Thanks for mentioning his mods.

Those are some pretty crazy stress tests. I've had a similar thing to your experiences in the first test you described (Papyrus stack meltdown, dragons moving backwards with no flapping wings and sometimes disappearing, people standing around like cows on acid), which happened much earlier in my current play through. I blamed DCO + Run for Your Lives though, for wigging out at the time. You're not using DCO, so I suppose it doesn't apply. Important thing to mention here is that I promptly deleted my most recent 5 saves (I save at least every 10 minutes, and keep a rotating backup at least the past 5 days worth of saves). Things were fine after that. The thing about your second test, although it seems to show things are working just dandy - are you planning to use this new loadout with your current save game? That would seem like bit a of a stretch. That said, after a few recent Papyrus stack meltdowns, I just yesterday ripped SkyBirds out of my load order (it's load slot replaced with an empty plugin as I suggested above,) and after using the PDT - Save Game Scalpel tool, watched my game saves drop 10MB in size, along with an apparent return in stability. Miss those birds, though. Oh, one last thing - you really should use the AI Max Actors limit increase tweak when making your Bashed Patch in Wrye Bash, as explained in Tonycubed2's mod, Artificial Intellidence Limit Increaser.

Thanks for mentioning this - It's really hard to "discover" recent major updates / changes to old mods that you have tried but deleted because they didn't fit your needs at that time. A bit off-topic - but SIM has about the largest number of FOMOD installer options I've ever seen in one mod.

Removing plugins mid-game is messy, and not recommended unless absolutely necessary. If you have to, though, besides following any author instructions for shutting down their scripts, I'd recommend finding a way to put a new mod's plugin in the same load order slot as the ones you remove, so that the load order position of everything else remains the same. Just do a "swap" as it were. And after loading that, go to a quiet interior, save, and then run one of the two well know save game "cleaner" tools to get rid of any lingering remnants of the removed mods. Also, with 8GB of system RAM, the recommendation for VideoMemorySizeMb is to set it the same as your amount of VRAM. It's unlikely this is connected to your CTDs though.

Ones that showed errors which you do not need to worry about are: Falskaar.esmBetterQuestObjectives.espJaxonRenamer.espSkyrim Immersive Creatures.espThunderchild - Epic Shout Package.espNonEssentialChildren.espimp_helm_legend.espChesko_Frostfall.espGrassOnSteroids_NaturalEdition_SFO.esp I'm not sure about You Hunger.esp, though. I agree with DoubleYou that Elysium Estate HF - No Kids is highly suspect. It's got references to a mod with a load order number of 06, but they're coming up as "Could not be resolved" because mod 06 in your load order is not what Elysium Estate was built to expect seeing in that load order slot. In your Modwat.ch page with your mod list, I see that 06 is HearthFires, so that's pretty strange. The thing is that when I read the author's description page, she/he mentions that the mod has been checked in TES5Edit, so I'm not sure why there are so many errors. Maybe something is wrong with your copy of HearthFires? Also note that Grass on Steroids is not necessary if you are using anything newer than SFO v1.79e, and in fact it may make unwanted changes if used with any newer version of SFO. Vurt has already incorporated the grass performance "tricks" of GoS in the newer versions of SFO.

It's especially important to understand that if VideoMemorySizeMb is set to be a value greater than your videocard's VRAM, ENBoost will to try to use system RAM when all VRAM is used up. Conversely, if you only want ENBoost to use available VRAM and not use system RAM, then make sure VideoMemorySizeMb is set to a value that is equal or lower than your videocard's VRAM. However, ENBoost will not use the VRAM set aside for buffering via the ReservedMemorySizeMb setting. I've just edited the ReservedMemorySizeMb and VideoMemorySizeMb descriptions in the ENBlocal INI/Memory page of the wiki to make them much clearer about how the two settings work in terms of VRAM and system RAM usage, and also the relationship between the two settings. Tech, if you think it's still not clear, please by all means make additional edits.

Well, actually you can force ENBoost to only use VRAM for it's texture / object data caching. Just set VideoMemorySizeMB to be equal or less than the amount of VRAM you have. Skyrim still uses RAM to cache some data, though. That's just the way the program was designed. ReservedMemorySizeMb set the amount of VRAM that ENBoost does not use for caching texture / object data. In other words, it's reserved for your video card to do things it needs to do with VRAM. Boris has never said it explicitly, but I've always assumed there's going to be some VRAM which the video card must "lock" away for its own use, for example your frame buffers, which is what is actually displayed on screen. That's always in VRAM. The reason why there's no absolute number that everyone should use for ReservedMemorySizeMb is because is depends on so many factors - how much VRAM you have, and how much memory your textures take up (which is affected by both the texture file resolution, aka 1k, 2k or 4k, and also the screen resolution you play at), and then your video card driver, and your system. For me, with a 4GB card for example, and I don't go crazy with high resolution textures everywhere, I hardly ever see my VRAM usage get maxed out, so my ReservedMemorySizeMb being relatively low (128MB) seems to work fine - for me. But with a 2GB card, maybe it should be higher so you don't see performance hits from the card's driver having to constantly swap things out in the VRAM that isn't being used by ENBoost. Really, of all the ENBoost settings, ReservedMemorySizeMb is the one that deserves the most individual user testing so they can find the "sweet spot". Sorry that I can't be more exact than that. You could try running yourself ragged by reading all of the ENB forum threads, as I've done, and realize there's no one-size-fits-all answer.

Now that there's the mod Lockpicking Interface Redone which completely replaces the vanilla lockpicking interface model, it seems to me that there must be a way to change which mesh is used, depending on the container / door being picked. I don't know hardly anything about scripting, but something with OnEvent of attempting to open something with a lock, checks what is being opened, and points to a specific set of meshes / textures. Heck, a majority of things with locks already have a mesh that could be used as a starting point. Unfortunately, though, the same mechanism of rotating keyhole + pick would have to be applied to all the different lock mesh models, so it would be purely a visual enhancement, not any improvement on the lock picking interface itself. Nevertheless, I'll put in my vote for Gamwich's re-texture over the current STEP recommendation.

Yeah, I know - don't worry about it, I'm just being a super nerd!

Bizzare. I use the DDS plugin with GIMP instead of Photoshop, and the preview for the 1024 res map normals in GIMP looks terrible compared to when viewed in DDSopt, as seen here: However, after processing / optimizing in DDSopt, then it displays the same in GIMP as in DDSOpt. I then did a compare in Compressionator (v1.50) and surprisingly, it also displays the original 1024 texture in the same way I see in GIMP, but the DDSopt processed copy looks fine. Here's the comparison with the same file as the above screenshot: But here's the punchline: Although the file info shows up the same for the original and processed normals in Compressionator, I see some different stats for them in DDSopt: Original normal - "Infos" in DDSopt Type: Planar texturePrimary use: World-space normal-map for terrainAlpha use: noneDimensions: 1024; 1024; 11Format: DirectX texture; DXT1Processed normal - "Infos" in DDSopt Type: Planar texturePrimary use: Tangent-space normal-mapAlpha use: Specularity-mapDimensions: 1024; 1024; 11Format: DirectX texture; DXT1Settings - Steepen 1.777778The addition of a specularity-map and the steepen adjust are, of course, a result of my current DDSopt settings, but if I had to guess, what I'm seeing in Compressionator / GIMP with the originals is a result of the normal map levels not being rendered properly. Or another possibility is that the primary use tag of "World-space normal-map for terrain" isn't recognized by Compressionator, and some kind of default normal map rendering state is used which results in the "blocky" effect. However, if Octopuss also had the Steepen setting turned on when he processed the normals in DDSopt, that would explain the apparent quality difference when the map is viewed in-game. I'm no expert, but I think the blocky preview in Compressionator / GIMP / Photoshop is just the normal map being incorrectly rendered, and it does not negatively affect the appearance in-game. This theory is mainly based on the fact that the DDSopt preview looks correct, and DDSopt was specifically designed for working with TES / FO textures, whereas Compressionator / the NVidia plugins were designed for general use. "World-space normal-map for terrain" sounds very specific to TES / FO games to me. That said, for some people increasing the "steepness" of the terrain map normals may be more visually appealing.

Just to clarify on that formula for 64-bit users with 8+ GB of system RAM: It's [VRAM] + [system RAM] - [2048], not [VRAM] + [system RAM] - [VRAM]. Even though 2GB is the same as the amount of VRAM your have, that 2048 number is meant to allow overhead for system RAM used by Windows. Keep in mind that setting VideoMemorySizeMB just sets the limit of what ENBoost will use. It will not use any system RAM if it isn't necessary. In Harpalus' case, since he was getting errors about Windows running out of memory, it means ENB was using all or nearly all of the VRAM + system RAM he had allotted with the VideoMemorySizeMB setting. When he set VideoMemorySizeMB to a lower value, that probably resulted in ENBoost freeing up cached texture / object data more frequently to give room for new data to be cached. This would possibly lead to some performance hit - but it's hard to say to what extent. Bottom line is that that situation it was completely necessary to lower VideoMemorySizeMB so that ENBoost wouldn't step on the system RAM required for Window's system resources.

Well, that's a shame, since there have be a lot of improvements, etc. since 0.262. So, Aiyen, are we talking about ENB-supplied shaders, or ones specific to Vividian's ENB preset files? If it's in ENB-supplied shaders, then has it been brought up to Boris? If yes - does anyone have any links to posts where the problem is described / discussed?

Hi Mangaclub and all. I don't think I've chimed in here to say that I've been using Vividian Vivid for a couple of months and still loving it. I've just run into my very first graphical "glitch" which is definitely ENB-effect related. I notice it with only a few magic might "glow" (particle?) effects, as seen with these Staff of Magnus screenshots: As you can see, the "glitch" is that the magic glow effect doesn't blend with some background effects - such as fog / mist, I am going to guess. Shift-F12 / no ENB graphics makes this disappear, of course. I have Vividian Vivid 6.508 with the RCRN option, Normal ENB Lighting option, and Mindflux meshes installed. I've tried both the last available 0.265 and the newest 0.266, with no change. Any ideas would be greatly appeciated, and I apologize in advance if this issue has been asked about before - I tried skimming back to January in the thread.

Been using this for a year. With all the dragon battles I get into, i I had to give this mod up, I think would just quit playing Skyrim.

This is great, Aiyen, and very timely for me personally, as I've finally just entered Blackreach for the first time after a year and a half of Skyrim. I'll try out the latest plugin and post any FB here.

Certainly it's worth testing non-default values for iBlurDeferredShadowMask=3 along with EnableZPrepass turned on, as that's the setting that most people would be playing with from Boris' short list. I will mention though that on my rig, with some of the shadow settings off from defaults, but iBlurDeferredShadowMask=3, I have a very minimal "halo" when using Vividian - Vivid 6.5x. Most of the time, I don't really even notice it. I have read that the relationship of the value of iBlurDeferredShadowMask and how much of a halo you see depends a lot of which ENB preset you're using, and my somewhat limited experience with a number of presets backs up this claim.

You should post your findings on the ENB 0.266 thread so Boris is aware of this. Mention which card you have, too.

I've read through all of the 0.266 thread up to present, and it's clear that this binary is still in a state of flux, still experimental. I'm wondering if you or anyone else has noticed if the framerate limiter bug in 0.265 is gone. I don't normally use that myself, but know it's been mentioned quite a bit in other threads here. Some really interesting info has come out from this latest release thread - for example, I need to query Boris for more explanation on this: Want to know which kind of memory he's referring to.

There's no need to add any bash tag(s). Just build your Bashed Patch as normal, and Wintermyst's items will be merged into the item lists, as can be seen here in my Bashed Patch report: There's more further down, but I think you can hopefully get the picture! ;)

No, mindflux's particle patches is a set of meshes which have been "fixed" so that the particle effects associated with those meshes look correct when using ENB graphics - but not just ENBoost. However, they won't hurt anything visually if you are not using an ENB graphics preset. Also note that a lot of mods and ENB presets available on Nexus either include mindflux's meshes, or have incorporated his fixes in their further edits to those meshes. For example, I use Vividian ENB, which supplies a full set of the particle patches meshes. Also note that texture replacer mods should work fine with mindflux's particle patches meshes, as long as the texture files are using the same names / directory structure as the original "vanilla" ones used in Skyrim. If a mod supplies edited meshes so they use differently named textures, then the particle patches version of the mesh will be incompatible, in that mindlflux's meshes won't use the mod's custom-named textures.

Yeah, those are pretty "old" from REGS v3.03 (now it's at 4.03).

Thanks for sharing this a little early - it will help with preparing timely compatibility patches!

I have some good news for all PerMa stealth mages: Over at the Audio Overhaul of Skyrim 2 (AOS) comments thread, some PerMa users have reported getting a permanent looping burning fire sound after a successful sneak attack using magic. After some investigation, I discovered this is caused by one of PerMa's scripts, and actually isn't related to AOS. The reason why AOS users are more likely to notice it is because that AOS makes the sound a little louder and clearer. Digging a little deeper, I figured out the exact cause in the script itself, and found a way to fix it so the "stuck" looping sound is gone. T3nd0 has confirmed the issue with the script, and has very kindly given permission for the replacement fix script to be hosted over at the AOS downloads page. You can find the fix script in the Optional Downloads section. Note that this script will fix the looping sound problem for all PerMa users, even if you don't use AOS. So, I recommend this to everyone using spells in PerMa until an official fix hopefully comes included in the next PerMa update. For some more information, please see my read me for the script fix here on pastebin.com.

I am so very happy to hear that solved your problem! Regarding SSME - you don't need it if you follow the STEP instructions to set up SKSE with the skse.ini file that will enable the Sheson Memory fix patch. Best of luck finishing your Skyrim set up and happy gaming!