Jump to content
  • 0

Overwrite Folder


flyingspatula

Question

Hey, I have watched a few MO videos and tutorial links but none seem to go into any detail regarding the Overwrite folder. When I try to install STEP, I end up with a few mods in the Overwrite folder and never know what to do with them. It will say to drag them on top of a mod, but that never does anything. Then if I reinstall a mod that had something previously in the overwrite folder, it will now no longer be there. Could anyone somewhat explain or link me somewhere that explains this? I am just not sure if something is not installed correctly if it appears in the overwrite folder but then other times reinstalling causes it to no longer be there. Skyproc/DSR seems to always be in the overwrite folder as well.

 

Thanks

 

Posted Image

Link to comment
Share on other sites

14 answers to this question

Recommended Posts

  • 0

The overwrite 'sync to mods' and 'create mods' and 'drag&drop' are not that matured atm. Please create a ticket in the issue tracker of MO, see MO mod page. The definitive overwrite behavior article has been made by UhuruNUru a week or so ago there. Pretty sure it will find its way to the MO wiki guide.

 

Personally I have never cleaned my ovewrite directory and never had problems. If drag&drop does not work for you aside from creating a ticket you can do the following. A mod in MO is just a directory in the /mods directory. The overwrite directory is in the directory. Just move the files from overwrite to a certain mod using the windows explorer.

Link to comment
Share on other sites

  • 0

This is what I do:

1. Right-click Overwrite in the left pane.

2. Select "Create Mod..."

3. Entitle it "Dual Sheath Redux Patch Files" or something similar.

4. Go to your mods folder inside the ModOrganizer directory.

5. Go into the "Dual Sheath Redux..." mod folder you just created.

6. Right-click -> Cut all files that do not have to do with Dual Sheath Redux (Dual Sheath Redux will include the Dual Sheath Redux.esp and the SkyProc Patchers directory, probably)

7. Paste the non-DSR files to the overwrite folder inside the ModOrganizer directory.

8. Go back to Mod Organizer (MO) and repeat until all generated files are inside their own mod folders.

 

Every time you run a SkyProc Patcher, Wrye Bash, Creation Kit, simply move the files back to these mods you created, or create a new mod if need be.

Link to comment
Share on other sites

  • 0

The overwrite 'sync to mods' and 'create mods' and 'drag&drop' are not that matured atm. Please create a ticket in the issue tracker of MO' date=' see MO mod page. [b']The definitive overwrite behavior article has been made by UhuruNUru a week or so ago there. Pretty sure it will find its way to the MO wiki guide.[/b]

Well I Definately wrote it and I try to be Accurate but I won't claim it's the Definative Article as it can be improved. Anyway the Information will be put on Wiki but until then here's the same article with some improvements and modifications to quotes to make Links work on STEP Forum

 

In Reply to All Overwrite Problem Posts (Too many to list)

 

Working Correctly

Every change to a mod requires using Overwrite folder it is Mod Organizer's temporary working folder and when the current changes are complete

Overwrite is Empty !!!

Mod Folder is Updated !!!

User Sees Nothing it's All Automated !!!

 

How this is Done

It uses Windows Move Folder function which gives

“Move From†and “Move To†data for Mod Organizer to know where the Overwrie Data is from

 

Not Working Correctly

All examples I know of are Mod Organizer working correctly as it's designed to do !!!

 

The main reason for data being left in the Overwrite folder is Third Party Programs using Copy and Delete Folder rather than Move Folder.

Generally considered good practice so copy can be verified before deletion but for Mod Organizer this is a problem because

No “Move From†Folder data is available using Copy and Delete. The Third Party Program deletes the “From†Folder and Mod Organizer has no idea where it comes from

 

So it Warns User that the Data is still in Overwrite folder to enable manual moving of Mod Files leaving them in the Overwrite folder is Not Recommended because anything in Overwrite Has Precedance

 

The Meaning of Overwrite Has Precedance

This is a term Tannin used for a feature that only Mod Organizer has, all other Mod Managers have two main Orders that define Mod Priorities

Load Order which is what BOSS or Bethesda Order Sorting Software (In my opinion a much better name than Better Oblivion Sorting Software) Sorts. This is the same for all including Mod Organizer,

Install Order this Does Not Apply to Mod Organizer

Mod Organizer uniquely has the ability to change this Precedence or Priority override this is what is commonly called a Mod Conflict where whatever is installed Last wins the conflict (you can change this with other managers but only when installing the Mod)

with Mod Organizer this is easily changed by Drag and Drop in your Profile and is indicated by the Priority Column number with highest number winning the conflict and the Overwrite Folder is automatically always the highest priority

EDIT (z929669): Wrye Bash does the same thing. Order can be modified post installation by moving installers around within the hierarchy and applying the 'anneal' function to update the asset priorities.

 

Various Tannin's Posts Saying Same things (My Emhasis of Point)

 

Tannin42' date=' on 20 Nov 2012 - 11:45 AM,said:[/b']

@Apprentice Harper: The files aren't moved, that's pretty much the problem why MO behaves oddly.

    TES5Edit and the CK {a} create a new temporary file then {b} delete the original and then {c} rename the temporary to the original name.

    An external application like MO or Directory Monitor would have to have a memory so that it can recognize in step {c} that the new filename is the same as the file deleted in {b} and then guess that the intend was for the file from {a} to replace the one from {b}.

    The guessing part in particular is why I shy away from such a solution.

 

 

Tannin42, on 21 Dec 2012 - 08:12 AM, said:

    @ess_tachyon: Yes, the overwrite issue should be fixed.

    Regarding files being moved to overwrite: 0.12.x includes a small workaround that I hope will fix this inconvenience. Basically if a file gets deleted and within a few seconds a new file with exactly the same name is created it will be placed in the mod where the file got deleted.

    This way, if you edit an esp in the creation kit or tesvedit, the esp should no longer be moved.

    Of course this doesn't affect files that you already have in your overwrite, those have to be moved to the correct location manually.

 

 

Tannin42, on 10 Jan 2013 - 07:11 AM, said:

    @zodden: Yes, bashed batches are supposed to go to the overwrite-folder. There may be a bug in the current version where they go to the actual data directory, I'll investigate that.

    Regarding skse: If you place the skse scripts in the overwrite folder you have to make sure to update them when you update skse, otherwise "interesting" things might happen.

    Also, doing this will prevent any mods from overwriting skse scripts. I assume this is your intend but just keep that in mind if a mod related to skse doesn't work as intended.

 

 

Tannin42, on 03 Feb 2013 - 10:37 AM, said:

    @mikegray: My suggestion would be to create a separete mod for each profile and move all the stuff that differs between profiles (bashed patch, the generated fnis files, skyproc stuff) to those. The Overwrite-mod was never intended to be permanent place for files, stuff that ends in overwrite should be moved back to a mod, unfortunately I haven't come up with a good UI for that yet.

 

 

Tannin42, on 04 Feb 2013 - 08:42 AM, said:

    @X-buZZ: MO doesn't delete files, "Optimizer Textures" does! What the tool does is create a new compressed texture with a temporary filename, then delete the original texture, then rename the temporary file to the old name. MO has to reroute the temporary file to overwrite because it can't determine which mod it belongs to. When the temporary is renamed in the last step it remains in overwrite.

    MO can only manipulate individual file operations. A lot of things that appear to be one action to the user (like overwrite a file with another) actually end up being multiple ops and MO doesn't know the context in which they happen. Here its (1) create -> (2) delete -> (3) rename. MO acts on each individually. If MO could foresee the future it could now in step (2) that another file will take the place of the original in (3) and thus suppress the deletion to achieve what you suggest. But it can't, so it doesn't.

 

 

and Lastly on Mod Organizer Bug Genie Commenting on Closed Feature request #383  -  Local Overwrite Folder

 

Tannin42, on 16 Sep 2013 - 09:03 PM, said:

    This has been proposed before in Enhancement 202 - Profile-specific overwrite and I have to reject this, but there is a suggested way to handle this: The overwrite folder should always be empty (hence the warning icon if it isn't). Starting from an empty overwrite, generate your files for the current profile, then move everything from overwrite to a new mod like "generatedstuff_profile_default". Enable it only in that profile -> tadaa, your profile-local overwrite folder.

 

 

 

The Bashed Patch is In Overwrite to enable user to Save separate ones for each Profile even though You can't use like other Mods Its easier than making new ones, this applies for FNIS and SkyProc Mods.

The User must Manually organize Profile Specific Versions

Until such time as a better method is found these advanced features will cause the same problems for all multi-profile Mod Managers

 

Just to repeat

 

When Overwrite warning is received move the files immediately back to original location that's why the warning is given

 

Overwrite will stay empty for next use and Mods will have the correct Precedence not be last because they were left in Overwrite

 

 

Link to Original Post on Mod Organizer's Nexus Forum

 

Link to My Post of First Tannin Quote on Mod Organizer's Nexus Forum

which was quote I was looking for when I found the others I found and posted it later in response to this question by wolverine2710

 

@UhuruNUru. I must find a new hobby it seems, every single line/quote above I have read before since I started using MO midway 2012, not good. It all seems very logical. I´m very interested how you (Mr Holmes) came to your deduction about the ´move to´ and ´move from´ functions.

 

Tannin then posted some new information about the same post

Tannin42, on 30 Sept 2013 - 5:22 PM, said:

    In response to post My Post of First Tannin Quote on Mod Organizer's Nexus Forum

 

   The mechanism (memory + guess) I mentioned in that post has been implemented in the meantime so if you edit an ESP in TES5Edit and save it gets saved to its original location and not to overwrite (as of 1.0.2 or something).

    This works for TES5Edit and probably for the CK, but not for FNIS for example because there step {a} and {c} are done by one process and {b} is done by another so the memory of the deletion {b} is not available during rename {c}.

 

    I know this doesn't provide a very consistent behaviour, I'd love to make it all perfectly intuitive but - well - reality is a *censored*.

In addition as wolverine2710 said in post I'm replying to there is new functionality but the facts above are not altered by this

Drag and Drop is what it says

Create Mods from Overwrite Folder this is I assume for Bashed Patch mainly.

If the files are already from a existing mod they should be moved back to that mod (FNIS for example) which is the Sync to Mods function I think

 

My understanding is these functions just make it easier for users by automating these processes but being new features they have not been fully documented yet and I have no experience with them so there may be more to it!

 

Hope this makes Overwrite folder less of a mystery, it is only used when required and most of the time you will not even see anything left in Overwrite folder, but when you do it is a because Mod Organizer either does not know where it's from or you need to choose where to put it.

Link to comment
Share on other sites

  • 0

Wow, thank you for that informative post. I understand what it's all about now. I sort of figured it out shortly after posting too, so I'm not sure why I could not previously drag over to the originating mods. It all makes sense now. Every time I run any kind of non BASHED patcher, I just merge it back into the original mod folder again. I leave the bashed in the overwrite so it always at the end I assume. Appreciate all the help.

 

Thanks!

Link to comment
Share on other sites

  • 0

No leave nothing in Overwrite You make a Bashed patch Mod for each Profile then you can copy the current profiles bashed patch to real data folder is best practice as it won't work as a mod that way you dont have to redo on every profile switch and overwite is empty for next one you make

Link to comment
Share on other sites

  • 0

I've never had files disappear from the Overwrite directory, although I'm sure it's possible.

 

I have asked Tannin. Has slightly edited response was:

no, files don't disappear without reason from the overwrite directory. If a hooked application deletes a file, sure.

Other than that, the only reason I can think of that files could spontaneously disappear is a virus scanner going awry.

Link to comment
Share on other sites

  • 0

Well I've noticed they they will sometimes not show up in the plugins list until I go to the overwrite folder and rename them or something whenever I do something with say the Merge Plugins script. It doesn't happen every time I use it and I haven't been able to make out a clear pattern but I've never had them just vanish from the folder in explorer, that's just weird. In fact I can't seem to get FNIS to stop being in the overwrite folder but that's for another day I guess.

Link to comment
Share on other sites

  • 0

Mod Organizer has an Overwrite folder in it automatically. If you launch MO then the Overwrite folder can be accessed in the left pane (installed mods) and will be greyed out if empty and highlighted red if there is something in it (such as where the bashed patch usually lands when using WB)

 

It cannot be renamed. Doing so will cause anything in it to not be accessible by MO anymore, it will just be a floating folder with data in it (if anything was in the folder when it was renamed). A new Overwrite folder will be made on next launch of MO.

 

If you accidentally change the overwrite folder and a new one is generated, you can delete the new overwrite folder and name the old one as "overwrite" and it will be recognized again as the overwrite directory. All content in the folder will still work as it originally did.

Link to comment
Share on other sites

  • 0

In Mod Organizer, in the Left Pane, if you sort by Priority ascending, at the very bottom of your mods, you will see Overwrite in italics. Double-clicking will show you the contents. This is the Overwrite directory, AKA Overwrite mod. It is always the last thing priority-wise, so anything conflicting inside it will overwrite any of your mods, hence the name. In the normal Windows file system, the Overwrite directory exists in /Overwrite. It should not be confused with the real game data directory or the virtualized game data directory. The real game Data directory existing in /Data. The virtual game data directory for the game doesn't exist anywhere in the Windows file system; it is virtual. It can be seen virtualized in Mod Organizer's Data tab in the Right Pane.

 

Added to wiki under Overwrite tab.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.