Bashed Patch in Overwrite Folder (clarifications)

[TommyH]

I'm new to MO but am well versed in modding TES. Before modding SK, I also modded Oblivion extensively. I am very familiar with WB (using it for OB and SK) and made the change to MO for the convenience of maintaining different profiles for different playthroughs.

 

I'm struggling with the Overwrite folder. After reading this thread and the "Sticky for Creating Mods out of Overwrite folder" thread and the Overwrite chapter in the STEP guide, I think I have a certain understanding, but not really sure if it is the correct one.

 

I use several Profiles, and I build Bashed Patches (BP) for each of them. Say now I work with "Profile 1". I start WB (from within of MO), build the BP, close WB. Back in MO, I now have the BP twice so to say:

• One BP is in the right hand pane (actual current load list for this profile). This is the BP I just build and this is the correct one to use for this profile now, right? Let's call this the "correct BP" (CBP).
• And I get a BP inside the Overwrite folder in left hand pane. This one I understand is some "old" BP that I built before, for some other profile?  Or is it the old version of the BP for the current Profile 1? Or could it be both? Regardless, this is DEFINITELY NOT the correct one for the CURRENT profile and load list. Let's call this "Overwrite BP" (OBP).
• This is probably crucial: If I do NOTHING with the OBP and I start the game, the OBP will override the CBP during game load, right? I will end up playing the Profile 1 game with the wrong BP?
• If 3.) was true (not sure), then you ALWAYS HAVE TO deal with the OBP in SOME fashion, right?
• And this would be my most important question for now: If I don't mind the inconvenience of rebuilding the BP every time when switching to a different MO profile, I could just as well DELETE the BP in the Overwrite folder and be done with it, correct?
• The alternative to 5.) is to create a "BP Mod" for each profile and select the corresponding "BP Mod" when switching profiles, yes? (create a folder, name it e.g. "BP-Profile 1", "BP-Profile 2"... and move a BP into each of them).

Thanks a ton for some help. Make it easy on yourself, just recite the number and say Yes/No if my points allow for that.

[rootsrat]

Every time you rebuild Bashed Patch, MO will place it in Overwrite folder. Anything that's in Overwrite folder will, yes, overwrite the ESPs and any folders of exactly same name from your MODS folder (it's where the mods are installed in MO, and the virtual Data folder is created out of it).

 

The right pane is representation of that virtual Data folder, therefore the Bashed Patch you see in the right hand pane is the representation of the Bashed Patch from Overwrite folder.

 

When you run WB from MO (via executable files) it will the build Bashed Patch and replace the one in Overwrite folder.

 

As for Profiles - the easiest thing is to recreate Bashed Patch when you change the profile and intend to load a game from it. You can of course keep the Bashed Patch files per profile, but that's a bit tedious :)

[TommyH]

As for Profiles - the easiest thing is to recreate Bashed Patch when you change the profile and intend to load a game from it. You can of course keep the Bashed Patch files per profile, but that's a bit tedious :)

 

OK..... I was thinking the same. At least then you know that the BP is correct for the selected profile. And rebuilding the patch is a quick affair on a good PC.

 

However, this method will always result in MO "complaining" that the Overwrite folder is not empty and will show you the warn triangle in the upper right of the GUI, no?  But as long as there is only the BP in Overwrite, you just ignore it, right?

 

Thanks so much for your help.

[rootsrat]

Yup, easily. I have a ton of stuff in my overwrite folder :)

 

Sent from my GT-I9505 using Tapatalk

[DoubleYou]

Yup, easily. I have a ton of stuff in my overwrite folder :)

 

Sent from my GT-I9505 using Tapatalk

Which I would discourage, but nevertheless, this has been how many people have decided to handle this. Personally, I find this method to be contrary to the goal of having an organized mod setup.

 

In normal usage, you should have a bashed patch for each profile. I have profiles named Step 1 and  Step 2. For profile Step 1, I create a bashed patch, which goes into overwrite. I then immediately right-click and Create Mod named Bashed Patch for Step 1. Then I switch to Step 2 profile, and create a new bashed patch (I suggest you have it named differently from the first one, so say Bashed Patch, 1.esp instead of Bashed Patch, 0.esp). This new bash patch goes into Overwrite. I Create Mod from this and call it Bashed Patch for Step 2. This way I know which bashed patch I should use for each profile, and every time I have to recreate the bashed patch, I move it out of overwrite and back into the correct mod (open overwrite file view and drag and drop into mod).

[TommyH]

OK... in principle I agree with Double You. But just leaving the overwrite folder "dirty" in a controlled way seems very convenient.

 

Thank you Guys. I will see how it goes. At least I have a better understanding now what's going on with the overwrite folder. Certainly, many points of my original post I had dead wrong. So thanks again for your help.

[rootsrat]

Yup, easily. I have a ton of stuff in my overwrite folder :)

 

Sent from my GT-I9505 using Tapatalk

Which I would discourage, but nevertheless, this has been how many people have decided to handle this. Personally, I find this method to be contrary to the goal of having an organized mod setup.

 

In normal usage, you should have a bashed patch for each profile. I have profiles named Step 1 and  Step 2. For profile Step 1, I create a bashed patch, which goes into overwrite. I then immediately right-click and Create Mod named Bashed Patch for Step 1. Then I switch to Step 2 profile, and create a new bashed patch (I suggest you have it named differently from the first one, so say Bashed Patch, 1.esp instead of Bashed Patch, 0.esp). This new bash patch goes into Overwrite. I Create Mod from this and call it Bashed Patch for Step 2. This way I know which bashed patch I should use for each profile, and every time I have to recreate the bashed patch, I move it out of overwrite and back into the correct mod (open overwrite file view and drag and drop into mod).

 

A ton of necessary stuff ;)

 

Sent from my GT-I9505 using Tapatalk

[GSDFan]

TommyH, I have been looking into the use of third party mods and the way they use the overwrite folder. Sorry if this is not clear, I am still in the testing of this, but the concept looks sound. I thought it was important enough to comment here.

 

EDIT:  your number 3, the BP and any files in the overwrite folder always wins any conflict. the overwrite folder has the highest priority of all mods in the left pane.

 

Following are some of my observations If you want a “clean†overwrite folder and profile specific mods from the overwrite folder.

 

Due to the way they write to the overwrite folder there is no easy way to separate out an already populated overwrite folder. If you are going to use this, then create a mod from the overwrite folder and do not enable it in the left pane or just delete what is in there. Most tools create a new version of the ESP and files anyway.

 

If followed you can use “sync to mods†to sync some of the files written to the overwrite folder back to tool that created it. Those would be the ESPs and the FNIS behavior files. The rest I call variable data and is only needed when the tool is run.

 

The procedure is like this and the overwrite folder needs to be clean:

• Run only one tool at a time. The exception is SUM.
• On the first run of a tool create a mod from the output, naming it for the profile and type of tool that was run. Example would be “Profile-1 FNIS output†Or "Profile-1 WRYE Uotput ESP".
• Enable the new output mod.
• Do this for each tool you need to run. Don’t forget to create a mod from the output after each.

Running the tools a second time to update because of adding or removing mods:

• Again the overwrite folder should be clean if you did the run tool / create mod step above. This is where it gets complicated with the way mods write to the overwrite folder. I will just list my observations in the way I ran the tools.
• FNIS writes a lot of files that will never sync to mods. On the second run leave the original output enabled and run FNIS. When it finishes right click the overwrite folder and select “sync to mods†to sync what will sync.
• When finished there will be files in the overwrite folder that cannot be synced, right click the folder and create a mod from it and call it something like “FNIS Variable data 001â€. This will create a mod for this data and clean up the overwrite folder. It does not need to be enabled for the game to run.
• The next time run FNIS enable “FNIS Variable data 001†so that FNIS will see it. FNIS will again leave these files in the overwrite folder. Do the sync to mods to write back to the original mod. The “FNIS Variable data 001†will most likely be empty now and can be deleted. Create another mod from what is left in the overwrite folder, naming it appropriately.

WRYE bash, this would match 2 of your question.

• If the ESP is in its own mod, wrye will see it, but due to the way it writes files will send the output to the overwrite folder all the time. When you run WRYE for a second time you can use the Sync to mods to write it back to a mod. Good for profile specific mods.

 

TES5Edit.

• TES5Edit will not let you create a merged patch with the same name in the system. So if the ESP is in a mod of its own, you can disable the mod before you run TES5Edit, create the Merged Patch and it will be written to the overwrite folder. If you re-enable the original mod you will be able to sync to mods the Merged Patch and have a clean overwrite folder.

SkyProc patchers is similar to FNIS above and makes my head spin when I try to write this down.

Just follow the rule, clean overwrite folder, run tool, make mod form output, enable mod. On second run make sure the output mod is enabled Sync to mod and create a mod with the left over variable data.

 

Again this is not a complete study of all of the tools out there.

[TommyH]

TommyH, I have been looking into the use of third party mods and the way they use the overwrite folder...

GSDF Fan,

thank you very much for the most detailed post!

 

Well, let me say to all who heve helped me here that MO and me have come a long way together over the weekend and by now we already make a pretty effective team. As an eternal and happy WB user, I of course was somewhat sceptical and hesitant to switch to MO. But now I'm rather WOWed!!! The whole idea of virtual directories and mod list building on the fly is a strike of genius! The convenience and speed is incredible. And the program itself is a joy to use. There is a little bit of black box behaviour here and there, but this is at least partly due to my inexperience.

 

After a couple of days of practice and experience gained, the overwrite folder is really not so difficult to understand as I initially thought it was. Looking back at my the initial struggles, I think the information in the STEP could be improved upon. Maybe it simply lacks a practical step-by-step example of how to build a Bashed Patch and handling the new output appropriately. I think building the BP is the most typical case that most players run into sooner or later when modding their games.

 

Let me post a summary with the hope that it will provide additional insight. I am using 3 tools only: WB, TES5Edit and BOSS. I can't speak for FNIS or SkyRe proc, simply do not use any mods that require me to use these tools.

 

BOSS

 

BOSS is the easiest in relation to overwrite folder because it never writes anything there ever, but (by design) just changes the date/time stamps on all the mods in the right hand pane.

 

Wrye Bash (WB)

 

WB and Bashed Patch is also quite easy to understand with a bit of practice. After building the (new) BP, it is dumped into overwrite where it "rightfully" belongs because the whole purpose of the new BP is to overwrite/replace whatever old or pre-existing BP there was previously.

 

Here comes one of the few quirks I find with MO: The content of the left hand pane is not updated automatically upon exiting WB (or any other tool), but the user has to press the little silver-colored directory refresh button manually (located where the profile selection list is).

 

Why does the program not refresh the structure automatically?

 

This would avoid any confusion of the "Why is the overwrite folder not showing red color despite something new written to it?" kind. Small detail, but I was confused a few times initially. Just saying, I know and appreciate that there is also the warning triangle in the right hand upper corner that shows red then, alerting you to something has "happened". But simple auto-refreshing of the structure would still make sense, IMO.

 

I agree that building a differently named BP for each profile and making a different "BP Mod" containing nothing but the newest "Bashed-Patch-named-specifically-for-this-profile.esp" makes sense, IMO. I understand that this is technically not required (neither is one BP each for each profile as we have seen, and some users handle it that way), but I also like a clean and organized mod structure.

 

TES5Edit

 

Let me write about the simple scenario when using T5E for "cleaning" mods. (DoubleYou writes about merging mods)

 

The "cleaning case" is different from the WB/BP case. Whereas WB/BP dumps the newly created file into overwrite folder, TES5Edit dumps it's new output into the mod's already existing folder that is physically located in the .../Mod Organizer/mods/ folder.

 

And - if you choose the Backup option when exiting TES5Edit - writes a renamed copy of the pre-existing, "old" .esp/.esm into the overwrite folder.

 

So in this case, the content of the overwrite folder is not what you want to use in the game. So what I'm doing is create a new mod folder "TES5Edit Backups" and put all T5E backups into it (the recommended way). And of course do not check this folder (because you don't want to use its content in-game).

 

Interestingly, when TES5Edit dumps its backup into an otherwise empty overwrite folder, the color will not switch to red even after manual refreshing the structure. Which makes sense I guess, because the new file already resides in the correct, existing mod folder.

 

There is one scenario about which I am not certain. Suppose you leave the T5E backup in the overwrite folder, and start the game: Will it pick up the new, correct file from the mod's existing folder, or will it pick up the backup from overwrite folder? I think it only picks up the new file. But just not sure. In any case, drag & drop cleaning out the overwrite folder is the safe way of avoiding ambiguity and issues.

 

Ok, these are my practical insights to this date.

 

Mods and experts, please correct me on any of my scribblings. I hope this thread can serve as an additional reference on overwrite folder. Thank you!

[GSDFan]

TommyH you wrote

Interestingly, when TES5Edit dumps its backup into an otherwise empty overwrite folder, the color will not switch to red even after manual refreshing the structure.

 

There is one scenario about which I am not certain. Suppose you leave the T5E backup in the overwrite folder, and start the game: Will it pick up the new, correct file from the mod's existing folder, or will it pick up the backup from overwrite folder?

In the first case I am not entirely sure and in the second case it most likely that the files are not proper game data. I can't say the non game data is Virtualized or not, only Tannin knows for sure.

[TommyH]

Hm... yeah... on the first case in the quote, I had only one instance where I could observe this, as there was only one mod I "cleaned". So the sample is very small, and I do not insist that my observation was indeed so.

 

In the second case I agree with your "most likely...not proper game data" which would imply that MO only takes up the new, correct file from the existing mod folder and the game will play correctly. In any case, this I think holds true (requoting myself): drag & drop cleaning out the overwrite folder is the safe way of avoiding ambiguity and issues.

 

But yeah, would be nice if Tannin can settle this. But then again, for the moment I understand it sufficiently well. I came a long way since my opening post. :) Thanks again to All for your kind help!