GrantSP

I think this may actually be a bug with the way MO handles the Oblivion engine. I can verify your findings. No manner in which way I set the flag, Automatic Archive Invalidation is always disabled when returning to MO from Oblivion. Fallout3/NV which also use this method do not have that flag reset. Curiously I see that MO managed Oblivion for me has all the Bethesda bsa files as standard files in theArchives tab, ie. they are not greyed out as they are with Skyrim or Fallout3/NV. To be honest, I have not the faintest idea of how MO's Automatic Archive Invalidation works, but it does strike me as strange the difference in behaviour with Oblivion to the other two games that use it. Additionally I have noticed that the Oblivion bsa files are not shown as essential, ie. greyed out, and can therefore be deactivated. This would render the game unplayable. All other games have the bsa files used by the main *.esm files as essential and greyed out, untouchable by the user. I have posted a bug report.

Well I consider it a must install simply because it does away with a number of other mods, but yeah I guess my statement was over-the-top. YMMV. As to SLI, I am on a laptop so I never have to face that issue, when/if I upgrade I will evaluate its worth. I also love SKSE plugins so maybe I was sucked in to install it simply because of that?

I won't speak as to the recommendation of F&L but the sooner you switch from NMM to MO the better. You will never again have the issue of messing things up because you installed ModA before ModB or changing your mind later and wanting TexturePackA over TexturePackB. NMM, like all managers before it, installs directly into the Data folder and therefore files get overwritten. MO doesn't work that way. You can safely install all the mods in any order you want and then manage them to ensure you get the correct textures or sounds or meshes or scripts or whatever and never worry again about doing a re-install because you messed up the last time. As far as I'm concerned the time it takes you to re-install your mods under the care of MO is made up for 10 times over afterward. Will the initial change over be difficult? Possibly. Will you need to learn new ways of doing things? Definitely. Will your system be free of all errors? More likely than not. Will it be easier for the STEP members to assist you? Yes.

Thank you, I wasn't expecting that as an answer. Is that due to the inadequacies of the script implementation over a purposely built tool such as WB? Maybe someone could strip out the code from the WB repo and create a specific tool just to create patches? Or not! Since the future of WB and its variants hinges on a hodge-podge of code maintained by people not fluent in either the languages or the code itself, it may be simpler to strip it for parts and move on. xEdit seems to be moving nicely along, I was hoping it might be an alternative.

As far as I'm concerned OneTweak is a definite install, don't even bother questioning whether you should, just do it. ;)

Inside the original SKSE archive the first folder is \skse_1_07_01, not Data\, so in the manual install dialog box you will need to expand the folder and set the data folder manually as in this image: Right click on the Data\ folder immediately below the skse_1_07_01\ folder and choose: Set Data Directory This will install only the files under that folder, ie. the scripts, and nothing else. Name it whatever you want and activate it in the left-hand pane. You are now set to go with SKSE. Follow the links at the top of this page to the Mod Organizer wiki and have a read through, it will be necessary as MO does things a bit differently and many new users have some trouble coming to grips with it. EDIT: ninja'd, again.

At the risk of exposing my ignorance to the masses, if someone was only ever using WB to generate a bashed patch, will this tool eventually be used to assist xEdit to apply these tags and generate a 'bashed' patch from within xEdit? Or am I completely missing the purpose of this tool? Since one of the major functions of WB is the management of mods and that is now handled by MO with STEP users, as I see it the only other function left with WB, and the only reason why I have it installed at this moment, is to generate bashed patches. If that too can be handled by another more robust tool, such as xEdit, why the need for WB and its variants?

Since the 2nd mod with the texture change wouldn't need to have a plugin and therefore isn't taking up a plugin spot, there is no reason to merge them, you aren't actually gaining anything.

Michael of GamerPoets has produced an excellent tutorial video that I followed just to see how it functions and his instructions work perfectly.

One more point, I would say the contents of that overwrite folder is either the result of two sessions without clearing it between them, or the result of two separate mods that need to be managed differently. The Safety Load mod, which as @hishutup suggests should be removed, is only generating a log of execution where as the other files may have a specific purpose and need to be in some mod to function correctly. In either case it highlights the need to decide what to do with the overwrite folder's contents and not just leave files in there.

I'm ready to concede that the symlinks are the culprit in my UI glitch. My only question about your setup would be: Are new saves generated in game seen by both tools immediately, or do you need to manually update one of the locations? The reason I used symlinks was because I couldn't see how a new save would appear in two separate locations. The method I used is outlined in this post. Whichever the case, I think this is only an intellectual curiosity, I wouldn't recommend advising anyone to do this. It's just not worth it.

Did you copy the saves to specific profile names when you created them? That was why I had to set symlinks. Everything you say is good, that weird UI glitch worries me though, the profile context menu not showing the profiles. Anyway the main/only reason I use WB, bashed patches, was never broken so all is good.

Thanks, but I know it should be the save game profile but I can't see where that information is saved. In both situations, via MO or alone, Wrye Bash has no profiles anywhere, I removed them. Right-clicking on the Saves tab of WB brings up the context menu from where I can select: Profiles -- Edit Profiles... and it shows no profiles. There should be at least the Default and the listed profile in that context menu. Wait a minute... I re-tried that process again. Right-click, blah, blah, this time I clicked on the only option available, a blank space at the bottom. Now the Saves tab is populated with saved games and the title bar has changed to Default. Also invoking the context menu shows two profiles Default and the Warrior one with Default checked. Tried it from MO and the same thing. Two profiles are shown whereas before no named profiles were visible. From here I have removed all profiles and only have the Default and the UI seems to functioning as expected. This sort of thing bugs me when it gets resolved but I don't know why. I am not blind, there were no named profiles visible and the context menu is now showing the correct information. Maybe I did stuff things up when I tried to link the MO & WB save folders. My question though still remains: Where is that information stored for WB to access it and why did the MO version not look to the same location? As I've been typing this I did system wide search for files accessed during that little experiment, seems I couldn't see the easiest files to see that would change those settings when I looked before. BashProfiles.dat is the culprit. Although it isn't text, the profile listed seems to be referenced in it. So it would seem there is much much more to getting WB & MO profiles synced than just the locations of the save folders. Unless MO could get access to that folder and make changes to it, it will be forever stuck in the last set profile, with dire consequences to saves and settings as I found out before. I think it would be safer for all if we steer clear of trying to use that WB feature from within MO. It may be possible but will need some code change to gain access to BashProfiles.dat and setting up symlinks to save folders isn't for everybody. Thank you both for that extra little push that got me to look harder. PS. The link to your video is set to private so I couldn't view it.

Page updated with your suggestions.

Agreed, but as I can't write new stuff to save my life, it is easy for me to say.

This could quite easily be the understatement of the century. The number of times I have examined that code with the desire to help in anyway I can, I end up in the foetal position on the floor... sobbing uncontrollably. I am in no way a 'programmer' but I can read most languages and follow to some extent the process, but WB code just takes it to a whole new level of complicated, at least for me. Kudos to Sharlikran for sticking with it for so long.

Trust me, using any IDE to see how that code works makes no difference. :O_o: Python is one of the languages I find the easiest to read but I get migraines everytime I try to decipher that stuff.

As far as I can see all those locations contain no information that would point to my MO profile, especially one that might be inactive. I did at one time try to link WB's save game profile system to MO's profile system by adding symlinks to the save directory. That partially worked but only in one-direction, ie. you shouldn't try to change profiles in WB if it is run via MO, it does... bad things! But... that still doesn't help me find where the settings are stored. I made the same assumption you did as to the meta info. I'll keep looking, thanks.

Good idea. My two cents worth: just call it xEdit, that way users can get to realize they are all the same tool, just for different games.

I have just now noticed something which may well be an obvious matter, but since I can't figure out how it is constructed I thought I'd ask. I work almost exclusively through MO so when I tried something just now to see if it might be related to another topic, I noticed something odd about what is contained in the title bar of WB. I have a number of MO profiles one of which is called "Warrior with followers" which as you can figure out is geared towards melee action with follower support. Anyway, of all the times I start WB via MO the title bar says: Wrye Smash 305(Standalone): DefaultI took no notice and assumed that is just the same for all instances of it running. No matter which MO profile I use, WB loads them correctly and it always says the same thing. Now I ran WB outside of MO to see whether an actual bashed patch in the data directory might conflict with WB execution when run from within MO. It doesn't BTW. What I noticed was the title bar from this instance of WB, started outside of MO, had in it's title bar "Warrior with Followers" in place of "Default". Further to add to the confusion, no matter which MO profile I have set in MO the WB run from outside of MO ALWAYS refers to that profile. What I want to know is: How does an instance of WB that is started from outside of MO pull this profile's name into it's title bar? What does this mean as to the way WB handles plugin lists? Is this somehow trying to copy the functionality from WB's save games profile system? Where is that setting stored?

Is there a bashed patch in the actual data folder of Skyrim or are you only trying to update the MO generated one? Nevermind, just checked it doesn't cause the conflict I thought it might.

I tried to install it where I put all my utilities, no such luck, the resultant error log states: Traceback (most recent call last): File "Wrye Flash Launcher.pyw", line 32, in <module> File "bash\bash.pyo", line 294, in main File "bash\bosh.pyo", line 36448, in initBosh File "bash\bosh.pyo", line 36190, in initDirs File "bash\bosh.pyo", line 36101, in getFalloutPath bash.bolt.BoltError: Install Error Failed to find Fallout3.exe in C:\Games\Utils\Wrye Flash. Note that the Mopy folder should be in the same folder as Fallout3.exe.Clearly Wrye Flash needs to be installed in the game folder.

@Sharlikran, am I to conclude from the way the archive is now packaged that you recommend installing this directly under the game's folder? It is now: \Data\INI Tweaks \Data\Docs \Data\Bash Patches \Mopy\whereas previous versions had those 3 folders as sub-folders of Mopy, at least that is how Wrye Bash was packed. Are the Fallout versions needing different access to the game folders?

So a fresh MO installation, as opposed to an update, fixed it?

Question: wouldn't the link from the requirements be better served if it took you to the Nexus page? Seems like going to the forum page only means one more click to get what you require.