Jump to content
  • 0
TheBloke

Files updated during process execution: what decides if they go to overwrite, or into a mod?

Question

I run a few different executables through MO which can create files.  Generally, any such file created will always go to Overwrite.  I often wish that there was a way to tell MO to always put certain files back into specific mods, so I don't need to keep manually deleting them from Overwrite, or run Overwrite->Sync all the time.

 

But I'm confused about what the exact rule is, because I know of at least one instance where a file that is created/updated by a process run from MO does not go to Overwrite, and instead goes into its original mod directory.

 

Specifically, I use the ReProccer, provided by T3nd0 for Skyrim Redone (SkyRe).  This is a Java SkyProccer, which writes to the file ReProccer.esp.

 

ReProccer.esp itself was provided as part of the SkyRe mod.  Every time I run ReProccer, it updates ReProccer.esp and the resulting, new/changed file does not go in Overwrite (although a bunch of other files created by ReProccer do - such as log files and backup files.)  After running ReProccer, I can go check my "T3nd0s Skyrim Redone" folder, and see the ReProccer.esp with an updated Modified timestamp.

 

So what's different about ReProccer.esp?  Why does this get written back to its originating mod when, for example, the Bashed Patch does not?

 

I thought that maybe the difference was that ReProccer.esp was provided originally by an installed mod - whereas the Bashed Patch I created new the first time I ran Bash.  So I took my "Bashed Patch, 0.esp" file, and made a new mod out of it - putting it in an archive, and installing that archive into MO like a mod.  I then ran Wrye Bash to update the patch, but it made no difference: the new "Bashed Patch, 0.esp" ended up in Overwrite again, and my own "Bash Mod" got the little lightning symbol against it to indicate its version of the file was redundant.

 

So every time I run Bash to make a new Bashed Patch, I need to go to Overwrite and choose "Sync to Mods.." and choose to sync it to my own "Bash Patch" mod.  Until I've done that, I get the MO warning triangle.

 

Oh, and regarding those other files created by ReProccer - log and backup files.  I once tried moving all those from Overwrite into the ReProccer mod, hoping that once they were in there, future updates to them would sync back there and not keep going to Overwrite; i.e., that they would behave the same was as ReProccer.esp does.  But no luck; like most other files, besides ReProccer.esp, all those files always go to Overwrite.

 

This is certainly not the end of the world.  But I'm really confused as to why I never have to do this with ReProccer.esp, when I do with seemingly all other files - even other files created by the same ReProccer process, at the same time.

 

Is there some change I can make that could result in other files - in particular the Bashed Patch ESP file - also auto-syncing to a mod, like ReProccer.esp does?   Or is there some fundamental difference in how ReProccer is creating ReProccer.esp that results in this difference, and is outside of my control for other files?

 

For the future, as a feature enhancement, it would be great it if it were possible to set up  "Overwrite auto-sync rules", to handle files like the Bashed Patch which are regularly written to Overwrite but which the user wants to reside in a specific mod.  I'll raise a Feature Enhancement for that soon.  Of course t's not that important or urgent, just a nice to have.  

Edited by TheBloke

Share this post


Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

Ah thanks for the link!  Sorry, I had not thought to check the MO wiki again; it's been a little while since I read it and while I must once have read that detailed Overwrite info, it was probably when I first started using MO and it was mostly over my head!  Should have known better than to not check it again before posting :)  

 

So OK, now I've read it - this is quite interesting.  So that explains why Bashed Patch always goes to Overwrite - Bash must delete the existing file, then create a new one.  It takes 20 seconds to create the Bashed patch, which is longer than the 5 second rule, hence always in Overwrite.

 

And reading the list of examples reminded me of another example from my own experience that I forgot all about - Tes5edit.  That's another example of where I don't get files in Overwrite, at least when I make changes to existing plugins.  

 

As you say, ReProccer takes much longer than 5 seconds - a couple of minutes in fact, way longer than Bash.  So if it's deleting & creating, it should go to overwrite.  Therefore, it must be one of two possibilities: either ReProccer is not in fact deleting and then re-creating the file, and instead it zeroes the current file and overwrites its contents.  Or - perhaps more likely - it's writing its results to a new, temporary file, and then moving it over the original file in one single very-fast operation.    That's probably also what Tes5edit does; writes to a temporary file then moves it over the original if you confirm you want to save changes.

 

Whereas Bashed Patch most likely deletes the existing file at the start of the operation, and then doesn't re-create it until the end - 20 seconds later.

 

 

Yes I do use Sync to Mods - every time I run my Bash Patch, I right click on Overwrite and choose to sync "Bashed Patch, 0.esp" into my "Bashed Patch" mod.  That's pretty easy to do.  I just thought that as there was one example where I didn't have to (ReProccer), maybe there was some way I could get that to happen for Bash too.  It's no big deal if there isn't.

 

Though it would be nice if that "5 second rule" was exposed via an (advanced) configuration parameter.   As I said it takes only 20 seconds to make my Bashed Patch, so I'd like to try changing that 5 seconds to 21 seconds.  I can't think of any reason why that would be bad for other mods, but I'd need to test it of course.

 

Thanks a lot for the quick response!  I now understand the inner workings much better.  

 

I think I will raise a feature enhancement requesting that 5 second parameter is exposed for config, as it would be nice to be able to tweak it and play about with the result.  But it's very low priority.

Share this post


Link to post
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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.