Jump to content
  • 0

Mod Organizer 1.2.7 is out.


TheDane

Recommended Posts

  • 0

Does anyone know if any of the changes that occurred from 1.2.5 - 1.2.8 will affect saves made with those versions?  I apologize if this should be obvious; I've been busy updating/testing my mods and haven't had time to fully read up on what the issues were between the various recent updates to MO.  I have a couple of saves made when using 1.2.5 and at least one after updating to 1.2.7.  Can I update to 1.2.9 and continue using these saves, or do I need to go back to something earlier?

 

My practice has been to disregard saves made with 1.2.5, and 1.2.7 or 1.2.8.  1.2.6 should be OK, and I am keeping the saves I made with that version.

 

That's not to say that saves made with 1.2.5, 1.2.7 or 1.2.8 are definitely broken.  However the asset ordering was somewhat screwy in those versions.  My fear was that I might have ended up loading the wrong version of certain scripts, and those might now be baked into my saves.

 

I just realised that Tannin provided an explanation on the issue tracker, regarding the issue in .7 and .8:

 

Turns out skyui.bsa conflicts with update.bsa and THAT bsa I had always excluded from bsa loading because loading update.bsa is hard-coded into the engine (contrary to all other bsas including official vanilla ones). Current solution (1.2.9) seems to work though.

 

So this speaks of the issue in 1.2.7/1.2.8 being rather specific to SkyUI and/or interface files.

 

I did a fair bit of testing with .7 and .8, and could not pinpoint any obvious case of mod-added, BSA-contained assets failing to override vanilla assets, with the sole exception of /interface/*.swf files (SkyUI, and also a map-changing mod I use.)

 

I tested a new game start using all the unofficial patches, and LAL, all in BSAs, playing the start from the "camping in the woods" option as far as going to Riverwood and then Whiterun to trigger the Bleak Falls Barrow quest.  I then repeated all that with extracted BSAs for those mods.  Everything worked completely as expected with the LAL start, which definitely involved modifications to vanilla scripts.  I also saw no script errors in my Papyrus logs from either USKP or LAL.

 

This strongly suggested to me that the BSA-added scripts were overriding vanilla fine.  Now combined with Tannin's explanation, I am now fairly sure that .7/.8 are generally safe for saves.

 

1.2.5 was a bit of a more serious issue.  In that version, BSAs could never overwrite any loose files.  That seems to indicate a quite high likelihood of scripts from the wrong mods suddenly being activated in your saves, and potentially recorded in the saves.

 

I didn't do enough testing with 1.2.5 myself to be sure of implications, but if you have many script-adding mods that use BSA files (or to be more precise, where the scripts themselves are in the BSAs), then I would avoid 1.2.5-made saves if that's at all practical, and test them thoroughly if it's not.

Edited by TheBloke
Link to comment
Share on other sites

  • 0

1.2.5 shouldn't have been able to corrupt saves. 1.2.7 and 1.2.8 could potentially have, so I wouldn't recommend using one from either of those. 1.2.9 works without issues as far as I've tested.

1.2.5 was a bit of a more serious issue.  In that version, BSAs could never overwrite any loose files.  That seems to indicate a quite high likelihood of scripts from the wrong mods suddenly being activated in your saves, and potentially recorded in the saves.

That should not have been an issue if you had the Potential Mod Order Problem solved.

Link to comment
Share on other sites

  • 0

1.2.5 shouldn't have been able to corrupt saves. 1.2.7 and 1.2.8 could potentially have, so I wouldn't recommend using one from either of those. 1.2.9 works without issues as far as I've tested.

That should not have been an issue if you had the Potential Mod Order Problem solved.

 

But Tannin described the issue as: "MO 1.2.5 doesn't allow bsas to overwrite loose files at all." -  which seems like that scripts added by BSA files would suddenly not be loaded, if there were loose file versions of those scripts elsewhere in the load order?

 

I do agree it might be quite unlikely, as all vanilla assets would be BSA-contained, so it would only be an issue where you have one version of the script early in priority as loose, and then another later in a BSA.  But still possible.  That said though, there were also reports of other issues that could be more serious, and didn't exactly match Tannin's description (nor, I believe, would fire PMOP.)

 

PMOP would pop-up if you had the mods in a different ordering to their plugins, but PMOP wouldn't fire if you had ModA (loose) at priority 1, and ModB (BSA) at priority 2, and the ESPs in the same order.  But according to Tannin's bug description, that ModB.bsa would not be able to overwrite the ModA loose files, and it would ignore the ordering - without firing PMOP?

 

What I do know for sure is that with 1.2.5 people reported potentially serious issues - example, the guy who reported that the USKP version of MineOreScript had suddenly taken priority over CCOR.  That guy said that CCOR was definitely after USKP in his mod list order, and of course we know that ccor.esp will always be after USKP.esp.  So that sounds like he had a script problem, without PMOP.  (In that particular instance, MineOreScript wouldn't break saves; but a similar situation with another script definitely could.)

 

So with that, and based on the description from Tannin, it doesn't sound like PMOP would always prevent against situations where MO was not letting BSAs overwrite loose? Or do you have further info from Tannin since he posted that?

 

I still don't quite understand all the implications of the issues, because for example that CCOR guy's problem (USKP script overwriting CCOR) does not match the description Tannin gave of "MO 1.2.5 doesn't allow bsas to overwrite loose files at all."  But then we weren't quite sure if there was also another problem in 1.2.5; only that 1.2.6 fixed such issues (or replaced them with some different ones :) )

 

So I don't know about 1.2.5.  I would definitely be concerned about script issues, based partly on Tannin's description of the issue and also on some of the experiences posted on the MO Nexus, particular that guy with the CCOR problems.

 

Conversely with .7/.8, I could find no clear cases of script problems in the several hours of testing I did.  Not to say there aren't any, but personally I'm more comfortable with .7/.8 than with .5.  Though I'm not keeping saves made with any of those versions, to be safe :)

Edited by TheBloke
Link to comment
Share on other sites

  • 0

Thank you for the responses.  I guess I'll probably revert to a pre-.5 save just to be safe, but from what you're saying I don't know that I'd have any problems.  I unpack most of my mods (since I mod more than I play, having things unpacked is a lot more convenient for me), so if the critical issues involve scripts in BSAs vs loose scripts it sounds like I would probably be okay.

Link to comment
Share on other sites

  • 0

Thank you for the responses.  I guess I'll probably revert to a pre-.5 save just to be safe, but from what you're saying I don't know that I'd have any problems.  I unpack most of my mods (since I mod more than I play, having things unpacked is a lot more convenient for me), so if the critical issues involve scripts in BSAs vs loose scripts it sounds like I would probably be okay.

 

Yeah in a 100% extracted setup, or near enough to it, I don't think any of the serious 1.2.5->1.2.8 issues would apply.  

 

Or rather, the issues that did still apply relate only to the newly-handled "Non-MO" mods (i.e. the DLCs etc), and the worst effect was that you might have had the Non-MO mods like Dawnguard, Dragonborn, etc at a certain priority position greater than 0, but in fact they were being loaded as if priority -1 (before everything else, so that everything else overwrote them.)  But that was identical to how MO 1.2.1 and before always did it anyway, so there's no great issue there besides it being misleading.

Link to comment
Share on other sites

  • 0

Regarding bug in 1.2.7 and 1.2.8: I have checked Update.bsa in more detail, and I'm now confident that the bug in 1.2.7 and 1.2.8 would cause no long term issues.

 

Tannin described the issue on the changelog as:  

- bugfix: update.bsa is again treated like a regular bsa because hiding it from the archive-list made it impossible (in managed bsa mode) to overwrite files from update.bsa 

 

So the only problems were with files that were in Update.bsa, and any mod wanting to overwrite those.   This is why SkyUI, and other interface changers broke, because most/all of /Interface/*.swf is in Update.bsa.

 

However there are no other troublesome files in Update.bsa.  

 

To be exact, Update.bsa contains:

  • interface/*.swf
    • Nearly the entire UI, I think; hence breaking SkyUI and map.swf mods
    • This was the real problem
  • meshes/actors, armor/, cameras/, clutter/, effects/, interface/, responses/
    • Just some meshes, maybe overwritten by some mods (e.g. in my load order, SMIM and USKP overwrite some of these files)
    • But never game/save-breaking
  • seq/skyrim.seq, update.seq
    • Never overwritten by any mods, I am almost certain; certainly none in my load order.
    • Even if they were, I don't believe these could break saves (though perhaps could give undesired behaviour while actually playing using MO .7/.8)
  • shadersfx/lighting, and a couple of loose shadersfx/* files
    • Maybe overwritten by some mods (not for me), but not save-breaking.

 

Therefore I am very confident that saves made with .7 and .8 are fine to continue using.

Edited by TheBloke
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.