oqhansoloqo

There must be some better more permanent way to handle those plugins than to have to manually reactivate them every time a bashed patch is created. What can be done to have them not automatically deactivate? This should be in the guide. I will put it in there if people give me the right information on how to do this. In other words, I don't want to edit the guide and state that those two .esps have to manually be reactivated. I want to edit the guide and either state what can be done during each of the two mods' installations to permanently correct this issue, or state what can be done after everything is installed in order to permanently correct this issue.... Or EssArrBee can do it... or someone else. :)

SRO covers many textures that the current STEP compilation does not cover. You *might* want to keep SRO installed so that it overwrites vanilla files, then have all of the current STEP mods with conflicts install on top of it. That way you get more enhanced texture coverage than the current STEP... Of course, we don't officially support this method. :)

Even from the compares (without motion) I'm in agreement with Tech about the bubbles option looking most like a stream. Just look at the spots in the water where there are no splashes - the way the see-through parts looks. And the fact that the splashes are not so prominent. It just looks better I think.

FAR more time. Sometimes I lie awake in bed desperately saying to myself "when will it end!" lol

TechAngel - what do you think about this?

I know... but everyone I know who was getting stuttering issues from ENBoost stopping having those issues when using "EnableUnsafeMemoryHacks=true".

Can we get a link to the mod in the OP? There appears to be a video or something that my browser is not allowing me to see (that I purposely have set), but no link to the mod otherwise... EDIT: Thank you. :)

I agree.

This is basically a "fix" for the ENBoost issue that me and at least a few others realized a while back. Doing what I said up above prevents ENBoost (aka - ReduceSystemMemoryUsage=true) from causing strange stuttering issues: Try using "EnableUnsafeMemoryHacks=true" in enblocal.ini and see if that fixes your problem.

I agree, if I was building a new system or doing a major upgrade I would buy more than 8GB of RAM these days.

It "knows" because what you are doing is editing your Nvidia driver profiles whenever you use Inspector. Inspector basically unlocks driver settings so you can modify them - settings that you can't normally access through the standard Nvidia driver control panel.

Why do you say that? BTW - you never responded to my question to you about your conflict patch.

I'm not sure if it will affect a saved game or not... but I believe you may also have to disable a patch in ILO related to NS. In addition to this, you may want to try Realistic Wasteland Lighting Enhancement (RWLE) instead of RWL - it's MUCH better than RWL in my opinion.

Maybe the next version of MO should do this: have the sort button set by default to use the internal LOOT, but will alternately use the external LOOT if installed.

Do you have any mods outside of the F&L guide added to your mod list? If you don't, and your mod list is standard F&L, can you provide a link to your conflict patch? I'm assuming you ran the bash tag script on your mods and have everything bashed properly. I was thinking about doing this (conflict patch) myself as I did for Skyrim, but being that I haven't customized FNV past F&L, I don't really want to bother if I don't have to.

That was really good. Thank you - the examples help a lot. So why would someone want to set block 1 higher than this example?: ExpandSystemMemoryX64=true DefaultHeapInitialAllocMB=768 ScrapHeapSizeMB=256 What benefit could I gain by doing this instead?: ExpandSystemMemoryX64=false DefaultHeapInitialAllocMB=769 or higher ScrapHeapSizeMB=256 In other words - Is it better to have the expanded X64 system memory or have more MB (greater than 768) in block 1? If it's not better to have more than 768, does the game run worse or better with the use of expanded X64 system memory (set to true)? My hunch would be that it's better.

I just went into Wrye Flash and used the "List Bash Tags" function on the 1nivVSLArmors.esp file to see the bash tag implementation. Here are the results: === Current Bash Tags: * 1nivVSLArmors.esp * From Description: Actors.Stats, Graphics, Invent, Names, Relev, Stats * From BOSS Masterlist and or userlist: Deflst, Delev, Graphics, Invent, Names, Relev * Result: Actors.Stats, Deflst, Delev, Graphics, Invent, Names, Relev, Stats Apparently, Wrye Flash does get bash tags from either LOOT or the outdated BOSS Masterlist. It takes those and combines them with the bash tags marked in the mod itself (which I edited with the script I guess). So if LOOT/BOSS Masterlist has added incorrect bash tags, it could screw things up because Wrye Flash seems to automatically add those in (compare "Result" tags to the other groups of tags). EDIT: I just manually removed the Delev tag through Wrye Flash since the script did not use it, and here are those results: === Current Bash Tags: * 1nivVSLArmors.esp * From Manual (if any this overrides Description/BOSS sourced tags): Actors.Stats, Deflst, Graphics, Invent, Names, Relev, Stats * From Description: Actors.Stats, Graphics, Invent, Names, Relev, Stats * From BOSS Masterlist and or userlist: Deflst, Delev, Graphics, Invent, Names, Relev * Result: Actors.Stats, Deflst, Graphics, Invent, Names, Relev, Stats EDIT2: Also, what this means is that if all of the correct tags are set in LOOT/BOSS Masterlist, then we do not need to run the script ourselves except for merged mods or custom mods we add in ourselves that aren't in the F&L guide or in the LOOT/BOSS Masterlist.

Without me testing this right now - I'm wondering if it is possible to edit a header in xEdit and successfully change the name of a master in it or if that would screw things up. If this works properly, that could possibly be a solution.

My EVGA GeForce 770 graphics cards just barely fit my case. I could have got a slightly better card for a good deal, but I didn't because it wouldn't have fit my case if I got it.

While I admire your extensive knowledge about a lot of Skyrim-related technical issues, my system is not suffering from these memory constraints that you brought up as being issues when using ExpandSystemMemoryX64 set to true. My SKSE.ini settings: [Memory] DefaultHeapInitialAllocMB=768 ScrapHeapSizeMB=256 In enblocal.ini I have ExpandSystemMemoryX64 set to true. I rarely ever suffer from CTDs. According to what you just said, if I set that enblocal.ini setting to true then I would have to set block 2 to 512. I didn't have to do this. I also don't get CTDs from having block 1 set to 768.

Check out the "Mod Tables Legend" in the STEP guide. Your answer is there.

They may need it soon, due to some expected mod changes in the next version of the guide.

I don't think I did. Also, re-running LOOT is something that's going to happen as it should be done regularly when changes are made to a mod list. According to EssArrBee, LOOT doesn't actually set the bash tag on the mods anyway - it just gives a list of which tags should be set manually for the majority of the mods (and it's not as thorough as the script is). Though something tells me that Wrye Flash has a way of automatically setting bash tags on mods and I'm wondering if it is getting the list from LOOT.

I'm a little confused with how this bash tagging works. I've been running the script on all my plugins. I finally got to 1nivVSLArmors.esp. The script said it removed delev and deflst, but it added other tags. So I then went into Wrye Flash to add deflst back in. Here's what confuses me: 1nivVSLArmors.esp was listed in Wrye Flash as having both delev and deflst bash tags, even though I just had the script remove them (and saved the plugin). Why is Wrye Flash ignoring the plugin bash tag data and adding those removed bash tags back again? I hope it didn't remove added tags to ones that the script added too. Especially since I spent a while doing this and am 2/3 of the way done. Got any ideas?