TheBloke

The explanations for that are in the preceding posts and in the link DoubleYou provided. Short answer: it ensures all your mod textures always overwrite vanilla textures without problems.

Yes, everyone should bother - and DoubleYou is/has already updated the Wiki to tell all users to do so. It's very simple: Go to the Settings screen Click Workarounds tab Click the long button labelled "Back-date BSAs" If you get a Windows popup, asking you to give permission for "helper.exe", then click Yes / OK / whatever Done, forever more unless you add new DLCs in the future, in which case you need to repeat this procedure. If you already own all the DLCs, then done forever.

Awesome, thank you for testing and confirming! So now I need to work out what was missing in my game Also, having read that link you provided, I am satisfied that the "Back-date BSAs" button is a one-time task. As long as a user has hit that button once (which physically changes the dates of all his /Data/*.bsa files to 01/01/2000) he never has to hit it again - at least not unless he later adds new vanilla content. So if a user already has all DLCs, he just presses "Back-date BSAs" once and he's done forever. The only users who need to take care are any who do not have all DLCs, and then later add some. They would need to hit the button again, after adding new DLCs to /Data. Is that your understanding as well? What I still don't understand is why it's only required to set the date for vanilla BSAs, and not for mod-added BSAs. Based on what I've recently read regarding AI, it seems that the Skyrim engine won't load a loose file that overwrites an entry in a BSA, unless that loose file is dated newer than the BSA. So, for example, if I have ModOne.bsa dated 01/01/2014, but I want one file from that BSA to be overwritten by LooseFileFromAMod.dds, which is dated 01/01/2013 - won't that experience the same problem? However this is mostly just an academic question - I am happy to believe that if it were necessary to re-date all BSAs, including mod-added ones, then Tannin would have implemented that. So there must be something different about how the game handles vanilla BSAs versus mod-added ones. Thanks again for testing this!

Not worrying at all :) I now have every possible method of AI enabled so I'm sure covered :) I do however like to try and understand how everything works and what is and isn't necessary. If for no other reason than to give advice to others.

So have you neither enabled "Archive Invalidation" in your profile, or clicked Backdate BSAs in the Workarounds menu? If so, that was the same position as I was in until today. But then when I looked into it a bit more, and read an (old) quote from Tannin, it seemed like we did need to do at least one of those things? Note that, like you, I never noticed any problems either, even though I'd seemingly not enabled any method of AI in my current profile. Certainly I know for sure that many textures from the base game are being replaced fine by mods, both in loose files and BSAs, and I don't have any missing/purple textures. But, better safe than sorry I guess, so I now have both AI in my profile, and I clicked Back-date BSAs. The tooltip for the "Back-date BSAs" button (on Workarounds settings screen) says: For Skyrim, this can be used instead of Archive Invalidation . It should make AI redundant for all profiles. For the other games this is not a sufficient replacement for AI. So it seems that even in Skyrim we have to do at least one thing to fix Invalidation - either enable AI per-profile, or click that button. Maybe you clicked that button on Workarounds once, long ago? My latest thinking is that we only have to click Back-date BSAs one time, then it works forever (as long as the /Data/*.bsa files don't change.) Though I am now wondering if MO 1.2.5 made even that unnecessary. Incidentally, @blattgeist - regarding bInvalidateOlderFiles=1 - we don't need to set that in our Skyrim.ini. I just checked the file profiles/<myprofile>/initweaks.ini, and I see that MO is setting that automatically on a per-profile basis; I assume once you have clicked Archive Invalidation in the profile. So it seems that that ini setting is important, but MO handles it for us.

I just noticed that I already have this set in my ini. I don't know when I added that, but quite possibly I did so on the assumption that it resolved invalidation issues, as you said.But surely it can't just fix the issue, can it? If it could, Tannin would just use that and wouldn't have spent time implementing Invalidation.bsa and the Backdate BSAs button on the Workaround profile. So there must be more to it than that. Google doesn't show up much of interest on that keyword, only a few posts from newbie-sounding people.Incidentally, regarding the Backdate BSA button, I am starting to think that maybe that is a one-time thing. I just had a look in Skyrim/Data, and I see that the result of me hitting that button was to set the date on all my vanilla/DLC BSAs with the date 01/01/2000. But it hasn't changed the date of any mod-added BSA (I checked both in their mod directories, and through the virtual filesystem - using BSAOpt as an executable started through MO, which could therefore show me the contents of the VFS.)So I'm now thinking that the only time you have to hit Backdate BSAs is if you change/add BSAs in the /Data directory itself. Which shouldn't ever happen again, really, because they're not going to release new DLCs.Another thing I'm wondering is whether, now that MO handles "Non-MO" mods in /Data, whether that means that Invalidation isn't even needed any more? Because the Backdate BSAs button only changes the dates on /Data/*.bsa, not on any mod-added BSA. That seems to make sense to me, because as I mentioned earlier, MO appears to dynamically map BSAs into Skyrim, using a system where Skyrim sees "aaa.bsa", "aab.bsa", "aac.bsa" and so on. Before MO 1.2.5, MO was only doing that (presumably) for mod-added BSA files. Now, in MO 1.2.5 and later, it does manage those files in /Data as well. So if Skyrim wasn't managing /Data/*.bsa, that might explain why the Backdate BSA button would be needed, as a one time thing to back-date any vanilla/official BSAs you have in /Data. But now MO manages the /Data BSAs as well, I'm wondering if BSA invalidation actually just became a complete non-issue, for all users? Maybe neither Backdate BSAs, nor Skyrim-Invalidation.bsais ever necessary any more, because now MO is mapping every BSA file the games sees - both mod and in /Data - and can therefore set the appropriate dates on every mapped BSA?Maybe if Tannin see this, or DoubleYou or anyone else who knows the inner workings, they could give a definitive answer sometime - am I misunderstanding how the BSA mapping works? If so, could you explain a little more about how Invalidation works; in particular, why Backdate BSAs needs to update the physical file date on the /Data/*.bsa, but not do the same for mod-added BSAs?Though at least I am now reassured that if invalidation is still a Thing, I now have every possible method of Invalidation enabled: backdated BSAs, profile Archive Invalidation, and even that (probably useless) ini setting :)

If you're having problems, definitely go back to 1.2.6. To be clear about the current issues with 1.2.6: the only functionality that has problems is the new functionality added with regard to the handling of "Non-MO" mods (i.e. stuff installed physically in /Data, including the vanilla/DLC content) To put it simply, 1.2.6 is basically ignoring the custom modlist priority you assign to Non-MO mods, such as Dawnguard, Dragonborn, HearthFires. The issue is that it's often loading those files before all other mods. So you might have DG, HF, DB down at mod priority position 10 or something, but in fact it's treating them like they're before priority 0. But remember that that is exactly how MO always used to handle them, in every previous version! So you've lost nothing by using 1.2.6 versus 1.2.1 or 1.1.2. All that's wrong is that MO lets you put those Non-MO mods higher in the priority, then ignores that. (In fact, to be precise, it only ignores it with regard to loose file mods. So if you put DG at priority 5, and priorities 0-4 all contain BSAs, then it's working OK. But if there's a mod that has loose files that's lower priority than a Non-MO mod, the loose file will still overwrite the Non-MO mod, ignoring the priority ordering. That's misleading and unintended, but is no different to what happened in all previous versions of MO, where the 'Non MO' mods, i.e. Dawnguard, Dragonborn, etc, were always loaded first, before any MO mod. ) TLDR: Just use version 1.2.6. Ideally you should also follow the changelog advice which is to: [*]not extract the BSAs for the Unofficial Patches [*]have your Non-MO mods (and their associated Unofficial Patches) starting from Priority 0 in your modlist; as per priorities 0 - 10 on this screenshot. (Disregard the rest of the mod ordering in that screenshot - priority 11+ - as it's not necessarily aligned with STEP.) But even if you do have other mods before USKP and DG and so on, that's still no different to the setup you had when you used MO 1.1.2 or MO 1.2.1. So it's not a big deal at all. The advice on STEP was meant to simplify things for users who wouldn't read the changelog, and ideally to prevent users from upgrading from 1.1.2 (or 1.2.1) at all until the current (minor) issues in 1.2.6 are resolved. But if you're having problems with 1.1.2, you absolutely can and should just use 1.2.6 because you're really not losing anything compared to 1.1.2 (quite the opposite.)

Oh, yeah that is weird. I thought it was ticking that that added Invalidation.bsa!Ah, I just tested it - I ticked the Automatic Invalidation tickbox, and this immediately added Skyrim - Invalidation.bsa to my Archives tab. Then I unticked it, and Invalidation.bsa was not removed. However the BSA changed from being automatically enabled (cannot disable it), to being an archive I could disable.So I'm thinking that you previously enabled that option in your Profile, giving you the BSA, then you disabled it sometime later. Now you have the optional BSA. I'm guessing that as long as you still have the BSA and have it enabled, that's probably the same effect.To be honest, I think I'll just keep this enabled now. I thought it was going to add a whole new mod list entry as well, that was the clutter I didn't want (though it's hardly a major clutter.) But it didn't add a mod list entry, it just added a new BSA in my Archives tab, alongside all the other "Skyrim - *.bsa" files. That's no bother at all. And I don't have to worry about the ordering of Invalidation.bsa, which was another thing I thought might be hassle, because MO just handles that automatically as part of the Skyrim-*.bsa group of BSAs.So yeah I'll keep this enabled so I don't have to worry about the button.

Yeah, it's definitely either/or. And yeah if you'd rather not hit the button, then just tick Automatic Invalidation in your profile, and have the Skyrim - Invalidation.bsa enabled in the mod list and the archives. I don't know where it goes exactly, in terms of order, but I guess where you had it before (early, around the vanilla content) is fine. If you don't know whether you have Automatic Invalidation enabled, just click on Profiles and check settings for the profile(s) you use - the tickbox is there, per-profile.

Right I just did some more research, and can quote Tannin himself (from 2012!) I had pressed Backdate BSA files in the past, and thought I was then good to go. But now I'm wondering if it's something I have to do each time BSAs change? Because it seems to perform some action, likely physically on the filesystem. Suggesting it needs to be repeated as mods change?So yeah, maybe we should either be clicking that button regularly (whenever BSAs from mods change), or we should be be enabling Automatic Invalidation in the profiles and putting Invalidation.BSA in the load order. Definitely not neither of those, though both is not necessary.Personally I now plan to do the former, and just press that button every time I change mods. I'd rather do that than have an extra mod list entry.So clearly I must have been doing something wrong up until now, because it's been a while since I hit the Backdate BSAs button. Not that I can say I've ever noticed any problems, though I've only recently started having a lot of BSAs, before that I extracted everything except vanilla. If the main symptom of problems is just some missing textures, I may have had that and just not noticed.

But the point is, this is only an issue for users who extract BSAs. And no users in general extract BSAs, besides a few who use MO.What I described above is only an issue when the mod author supplies a BSA in his original mod, then applies an incremental update with a new BSA. If that new BSA has removed some files inside it, then a BSA-extracting user will not have those removed when he applies the update via a Merge. Every other user has no issue, because he didn't extract the BSA, and therefore the incremental update just replaced the old BSA with the new one. Regarding invalidation - I'm not really sure. I don't have Skyrim - Invalidation.bsa, and I haven't hit the profile option "Automatically Invalidate Archives".Maybe I'm doing something wrong? But I thought I read that archive invalidation was no longer an issue really in Skyrim? That's what I think I read when I googled it, after first seeing that option in MO.I only play Skyrim, not any other games supported by MO. And I think I also read that, whatever issues exist in general, MO handles automatically? I haven't ticked the "Automatic Invalidation" option in my profile, because I thought that didn't apply to Skyrim.I didn't even realise until recently that there was a "Skyrim - Invalidation.bsa". So I don't really know. A user mentioned that file recently, I think in this post or another one on this forum, and then came back "Ah MO handles that automatically, no problem." Which was my understanding too.I've never really understood the invalidation issue, so someone else will need to comment in more detail - but my understanding that, at least when using MO, there was nothing to worry about? (Bearing in mind that MO seems to create dummy BSAs every time you launch Skyrim or any executable - it maps all your archives to archives called aaa, aab, aac, etc; at least that's what the logs indicate. So I would have assumed that the dates could be set appropriately automatically at the same time. But I'm not completely sure.)

1, yeah definitely. 2, that solves the general issue that we currently have, where we can't ever merge in a BSA mod if we extracted the original BSA. That issue exists because as of MO 1.2.1, MO won't extract from a BSA if the local file already exists. So if you extracted the original BSA, then nearly all of the files in the updated BSA will already exist, and MO won't extract them. Hence any files that were changed in the update will not be updated. The solution you described fixes that manually, and I proposed an automated version of that solution to Tannin (bug tracker link.) But I've now realised that there's little point him implementing that, because merge updates can never be completely safe. The reason is the new issue I described in my last post - where the new update BSA has removed files, compared to the previous copy of that BSA. The solution you described doesn't help with that. If the original mod had FileA in its BSA, but the new BSA had removed that file, then however you apply the update BSA, you will still have a copy of FileA remaining from the original install and extract. You would have to manually compare the contents of the original BSA and the new one, to work out which files you must now delete. So the only solution is as you said in 1: if you extract, only use merge update when no BSA is involved.

To be clear, MO 1.2.5 and 1.2.7 changes nothing regarding the need (or lack of) to extract BSAs for simple conflict resolution. The decision as to whether to extract or not is exactly the same as it was in 1.2.1 and before. In fact, the changes in MO 1.2.5 made it safer to extract BSAs - at least with regard to the Unofficial Patches. So if anything, one could argue that the core changes in MO 1.2.5 and later encourage BSA extraction :) However BSA extraction is not in fact encouraged, certainly not by Tannin and not by STEP now either. And we all learnt a lot about it during the lengthy Ramifications thread. The main outstanding issue with it, as we've discussed before, is that it breaks the ability to Merge update mods. Incidentally, I thought of another broken case with merging updates when extracting all BSAs: a situation where a new update includes the BSA file, but some files have been removed from the BSA compared to the original release. Users who extract all BSAs will not get those files removed, ending in a situation where, after merging in an update, they still have files that the mod author intended to be deleted in the latest release. At best, that means they have unnecessary clutter; at worst, the mod will malfunction because of the extra files - that could particularly be an issue in the case of scripts. This is another issue that can never be solved, and I think basically means that users who extract BSAs must never ever apply any incremental update, via the Merge installation feature, for any mod that uses BSAs. I'm no longer worried that Tannin plans to remove it completely. It's known that he doesn't like the feature much, but despite that he still implemented in 1.2.5 the Non-MO mod handling which improves compatibility when extracting BSAs - at least in the case of the Unofficials - and wasn't really that important for users who don't extract. He did also move BSA extraction to an external, default-disabled plugin, to discourage its use. But I think that's as far as he plans to go. Default disabled, discouraged in documentation and discussion, but remaining available. In fact, now that it's a plugin, we can't ever really lose the feature - even if he removed the plugin from future releases, we could always copy it back in from the current release (so long as the plugin API doesn't change hugely in the future.) But I don't think he'll ever remove it completely. Plus of course there's the Archives tab right-click -> Extract BSA feature as well. Not quite as convenient, because you need to browse to the mod directory and it doesn't delete the BSA afterwards, but does provide another way to extract BSAs, and one that works for installed mods rather than requiring a re-install.

Ahh, fair enough. That's easy to deal with then. What will be your upgrade advice, for users who have existing STEP installations and thus followed the previous suggestion to extract all BSAs? Are you going to suggest that they re-install all STEP mods that have BSAs to get everything unextracted? Or even require it? I think there's no pressing need for them to do that, but I could understand if it was felt important from a simplicity-of-support perspective (to have everyone on a known config.) If that's not considered a huge issue, then personally I'd recommend requiring the re-installation of the Unofficial Patches, but not make it a requirement to re-install all others just to re-BSA them. With BSA Extraction disabled, any future update of existing mods will re-BSA them anyway.

Yup, that'll be simplest. There's no reason to stop extracting BSAs as of 1.2.7, however STEP's advice is apparently changing to be not to do so - presumably so as to bring STEP more in line with what the majority of the modding community do. There can also be performance benefits in not extracting BSAs, although my experience is that these are likely only noticeable on slow HDDs and not on fast SSDs (though to be fair, with a full STEP installation being in the 10s-of-gigabytes at least, it's quite likely that a large proportion of the userbase are installed on HDD not SSD.) The major downside of not extracting BSAs is that you can't do per-asset conflict resolution. So you place ModB below ModA in the priority list, therefore for any conflicts, all ModB's assets win. With a loose-files mod, or an extracted-BSA mod, you would still have the option of choosing some files from ModA to overwrite ModB (by hiding those assets in ModB). By never extracting BSAs, you lose that ability; so in the case of a situation where you want most of the files from ModB to be priority, but still want some from ModA, then you have no solution any more. Of course, that's the expected result all the time for 95% of Skyrim mod users, so it can be argued it's far from the end of the world. (And, unlike with other mod managers, at least with MO you still have the ability to prioritise the mod's files differently to its Plugin(s).) I am putting in a feature request to Tannin which would enable per-file conflict resolution even with unextracted BSAs. I'm hoping he'll consider worthy of implementing, because that would then remove the final objection to not extracting BSAs. And STEP could then go back to specifying per-file conflict resolution rules for mods, and still tell people never to extract any BSAs. (As it now, the STEP guys will have to go through the 2.2.9 list and find any mods which have per-asset resolution rules, and remove those rules if the mods use BSAs. Unless they decide to suggest extracting the BSAs for those particular mods alone, which is what I would recommend. Fortunately most such rules usually apply to texture mods, which are often not provided as BSAs. But I think there will be some cases where per-asset rules will have to be removed, at least if/until Tannin implements per-asset resolution with BSAs.)

Great!

OK regarding the "Priority 0" bug, i.e. where Priority 0 mod seemed to be overwriting all.. I just did a couple of tests in 1.2.6, and could not re-create it. I don't quite understand the experience of DoubleYou, nor of the guy on the Nexus who had USKP in prio 0 overwriting CCOR (much later). But I can't re-create this in 1.2.6. Specifically, I: Moved the mod "Colored Map Icons", containing the single (loose) file Interface/map.swf, into Priority 0. This file conflicts with SkyUI, which is at Priority 50 or so.Loaded the game, and confirmed I had the default SkyUI map - the file provided by Priority 0 mod had not overwritten the later mod.I then made a BSA file of the Colored Map Icons file Interface/map.swf, and put this BSA file into a new mod, which I moved into Priority 0. (And disabled the Colored Map Icons mod).Again I tested with a loaded game, and confirmed I got the default map. The BSA file in Priority 0 had not overwritten a later mod.Therefore in 1.2.6 I can't re-create the symptom of either a BSA mod or a loose file mod in Priority 0 overwriting a later mod. It might be more complex than I tested, so we'll need to keep an eye on it. But hopefully Tannin is right and there was no issue, or if there was it's been fixed somehow in 1.2.6 anyway.

Once 1.2.7 is released, everything will be simple again: As long as you have ticked "MO manages archives" in the Archive tab (which is on by default, so you should have), then:The list of mods in your mod list (left pane) decides what order any mod assets are loaded in. Doesn't matter whether they are supplied as loose files, or BSAs. Every single asset required by the game - any script, any texture, any Interface/ file, whatever - is loaded according to the priority of the mod list, and you can see that order using the mod list Conflicts tab, and by looking at the Data pane.This is one of the (many) beauties of MO - loose, BSA, any combination of loose + BSA.. doesn't matter; mod list priority decides all.But yeah 1.2.6 is a bit different - for now, just follow the advice Tannin gave in the changelog, and put USKP at Priority 0 and then Dawnguard and then UDGP and so on, and all will be fine. (Actually that's not strictly required, as Tannin explained earlier.. but it's the simplest advice to give/follow)

In MO, conflicts are resolved according to the order of mods in the left-pane (modlist). Or, they are meant to. In 1.2.6 there is a bug relating to the newly-handled "Non-MO" mods and their BSA files. Therefore, in 1.2.6, if you have, say, Dawnguard in mod list priority 5, and before Dawnguard (e.g. priority 3) you have the Unofficial Skyrim Patch, and you have extracted the BSA in USKP, then Dawnguard will be unable to overwrite any USKP-provided files - even though it should overwrite it, because Dawnguard is higher priority than USKP (5 vs 3). Ditto if you put any other mod with loose files (whether from extracting a BSA, or just because they are provided loose; e.g. scripts) before Dawnguard, Dragonborn, HearthFire or any other Non-MO mod that provides BSAs. In other words, with regard to the "Non-MO" mods, mod list priority is not currently working completely as displayed and as expected. This will be fixed in 1.2.7

That's how it will be in MO 1.2.6, yeah.But the way I understood hypercleat's question was "Is it right that, in general, this file in Argonian Decapitation is going to be overriden by Dawnguard?I noticed that earlier today as well - and I think the answer is no, it's not right. This is a new issue that was introduced because of MO 1.2.5's new handling of Non-MO mods. Before, we put Argonian Decapitation before the Unofficial Patches, but MO would still load it after the vanilla DLCs. Now if we put it at the top of the load order, MO is loading it before the DLCs. And every other mod manager would load it after the DLCs as well, because it's loose files.So I think that once 1.2.7 comes out, Argonian Decapitation Fixes needs to be given a new mod position order in STEP - after the Non-MO and Unofficial mods. That should then load all its files in the order the mod author intended.

Tannin said on the bug tracker that he believes this bug never existed. Instead, the symptoms described by people as "Priority 0" bug actually turned out to be a combination of two issues:[*]MO 1.2.5 doesn't allow bsas to overwrite loose files at all. [*]even after fixing this, bsas from dlcs can't overwrite loose files. The first of those was fixed in 1.2.6. The second has not yet been fixed, which is why we have the Changelog instructions to not put any conflicting items before the DLCs. So it appears that thinking that Priority 0 "overwrote everything" as inaccurate; what was happening was people often were putting a loose file mod in priority 0 and then the DLCs and Unofficial Patches, which used BSAs, could not overwrite them. However it's not yet been 100% confirmed that there isn't a third issue, specific to Priority 0 - just at the moment, Tannin doesn't believe so. EDIT: Yeah and I remember on Nexus, someone was having an issue with USKP overwriting CCOR, even though CCOR was later. And CCOR doesn't use a BSA. So I am still worried there might be another issue. I asked Tannin about the potential Priority=0 issue still existing, on the issue tracker, but he could find no sign of it. I'm doing some checking now I finally have 1.2.6.

I think that the STEP advice should be that none of the unofficial patches should have their BSAs extracted right now. USKP, UDGP, UDBP, UHRP. They should be installed with their ESP and BSA file, and the BSA should not be extracted for use in MO 1.2.6. That's simplest, and it's least confusing because it exactly matches the changelog advice. However, technically speaking I can't see why there's any problem extracting the BSA in UHRP. UHRP is the last mod in the official/unofficial sequence. The bug that remains in 1.2.6 is just that "BSAs provided by Non-MO mods cannot overwrite loose files" This matters for extracting USKP, UDGP, and UDBP, because these appear before at least one Non-MO (official/DLC) mod. It does not matter for UHRP, because this appears after the last of the Non-Mo mods (it appears after HighResTextures*) and so the issue does not apply. But on STEP I would keep things simple, and say don't extract any of them. It's not like it takes long to re-install UHRP with or without BSA extraction, so no big deal if someone re-installs it to get a version without extracted BSA, then reverses that after 1.2.7 is out.

Good point re Distant - I am going to disable my copy completely until 1.2.7 is out.You're quite likely right that it's not a hard requirement having USKP at Prio 0, and that we can have no-conflicting mods above it.But as I can see no benefit, at least in my own load order, to having any non-conflict files before it, I am not going to. (I did have some conflicting mods before it, like Distant, so therefore I am just going to disable them for now.)Also bear in mind that we were talking about instructions to put on the STEP guide - which, like the changelog, needs to simple, generic, and very safe. So I think it should stick to the letter of what Tannin put in the changelog. It's probably fine for you personally to deviate from it (though I'd suggest doing some testing to be totally sure.) In the Plugin load order, yes. Any advice like that on the Nexus mod page will assume users use NMM, which doesn't even have a "mod order". Only a plugin order. And yeah the SkyUI.esp does go quite high in the Plugin order (LOOT puts mine at position #63, out of 250 total)But that doesn't mean it needs to be anywhere in particular in your mod load order. The only time that matters is when you have file conflicts. With SkyUI, you quite possibly have zero conflicts. I have one conflict in SkyUI, because I have the file Interface/Map.swf provided by "Colored Map Icons". So I just need to ensure that SkyUI is before Colored Map Icons; they could be Priority 0 and 1, or 500 and 501, doesn't matter where exactly because neither of them conflict with anything else.

That's specifically not what the changelog said, though: a) please ensure your DLCs (and other mods not managed by MO, that's the ones without a checkbox) are at the very top of your modlist, only unofficial patches should be up there with them. Based on the info we have, I can't see how else to read it - it seemed pretty clear, "ensure your non-MO mods are at the very top of the modlist" and "only unofficial patches should be up there with them." To me that means USKP has to be Prio 0, and then it follows in the standard order of DG, HF, DB, HiRes, with the patches interleaved between them. I agree some clarification would be good. And you might well be right - based on how Tannin described the bug, it could well be that mods that have no conflicts at all are OK to be higher. His statement above might have been designed to be catch-all advice, guaranteed to work for everyone. Also, I still have a question mark around the original "Priority 0" bug, because my understanding of that bug was that "Prio 0 overwrites everything". Tannin did not say specifically that that was fixed. Which made me a bit worried about having USKP at Prio 0. But his changelog comment seemed pretty clear and specific, so until clarification is provided, I think all we can do is read it literally and go with USKP at 0 and the vanilla/unofficials following from there, up to Prio 9. Also, in your example (putting SkyUI first) - is there any reason to take a risk? It generally doesn't matter where SkyUI goes (unless you have a Favourites.swf or Map.swf mod, but even then that just means SkyUI needs to be before them; it doesn't have to be before USKP or most other mods.) So personally I don't see any advantage in taking any chance in ignoring his changelog statement.

The load order is in flux. My post just before yours, with a screenshot, shows what I believe to be the required load order (at least for the first 10 entries) as of the newly released MO 1.2.6.On top of that, there needs to be a message saying that the Unofficial Patches must not have their BSAs extracted. If a user has extracted BSAs, he/she must re-install those mods and choose not to extract.But then this will change again when 1.2.7 comes out. The don't-extract-Unofficial-BSA advice can then be removed. And the load order should go back to being flexible, such that we should not need to have the official/DLC content + unofficial content right at the top of the load order. So that STEP can again recommend certain mods go before USKP and the DLCs (like Distant Decal and whatever.)My recommendation for a message on the STEP page would, at this time, be not to upgrade past MO 1.2.1. That could then be removed when 1.2.7 is out and the major issues are fixed, which I would hope won't be more than a few more days.I suppose you also need to cater for users who have already upgraded to MO 1.2.5 or 1.2.6. You could simply advise them to downgrade to 1.2.1. Or, if that won't be popular, then advice for 1.2.5 users is to immediately upgrade to 1.2.6, and advice for 1.2.6 users is as I stated at the start of this post.