TheBloke

FYI there can be a difference in load order in the latest LOOT, but only if you've configured custom metadata. You can't configure custom meta data in the internal LOOT, so this change will never affect MO internal-LOOT users. But any users who have downloaded an external LOOT - to use via Executables - should upgrade to 0.6, if they use metadata. This is the change in the LOOT 0.6 changelog that would affect ordering (in certain cases): Fixed: Plugin priorities are now temporarily "inherited" during sorting so that a plugin with a low priority that is made via metadata to load after a plugin with a high priority doesn't cause other plugins with lower priorities to be positioned incorrectly. So if you only use MO internal LOOT (via Sort button), this can't affect you because you're not able to set any metadata (priorities etc.) If you download a separate LOOT, which you run via Executables, then you can set metadata and, if you have external LOOT 0.5, it's worth upgrading to external LOOT 0.6. But yeah this doesn't sound like it applies to the OP - if he's using the internal Sort button then he's not applying metadata. Note for OP: If you're going to use the internal Sort button there's no need or point in downloading a separate LOOT and using it via Executables. The internal Sort button is not referencing that externally-downloaded LOOT at all. Use one or the other: If you want to set LOOT metadata (priorities etc), then download and install LOOT separately, and use it via Executables; and don't use the Sort button (it won't read your custom metadata/priorities.) If you don't want/need metadata, then don't bother downloading a separate LOOT via Executables, and just use the internal Sort button only.

I just saw the edit. OK so yeah these specific PMOPs can be ignored, fair enough.I do still wonder though whether there's a way to re-order SRLE that both provides the required ordering, and removes the PMOPs.In the case of guides I'd worry that if a guide results in PMOP errors - even when no actual game problems result - it might convey the impression to users that PMOP can be ignored, which it definitely should not be as a general rule.And also, having no such errors gives users a clean state to start from such that if they then add further, unsupported mods, they know when those new mods have added new ordering issues and are able to fix those in isolation. If they're already used to a big list of PMOP errors, they might not even notice when a newly-added mod has introduced further PMOPs, which might be ones that they must not ignore. Even if they do notice, it will be much less clear how to resolve the new errors, as the errors will likely be intertwined with the pre-existing errors from the guide.Perhaps that's the biggest issue - even when they understand that it's only this specific set of errors that has been tested as being OK, they're still left in a position where they have a large set of errors to disregard, and as soon as they start adding different mods, it becomes very hard to track which ones are tested as OK, and which ones are new and definitely not OK.As I say, I've not studied SRLE and I have no doubt there's good reasons for all the mod order positions. But I do wonder if it's possible to preserve the desired asset ordering while removing the PMOP errors. Perhaps using Hide File (I see from that SRLE thread that Lauren linked that it advises extracting all BSAs) to allow certain files to take priority over others, contrary to their mod list positioning.As a user, I'd certainly rather do a little extra work manually hiding files if it meant I could start with 0 PMOP errors, therefore having a clean base to add further mods without risk of confusion.

Ah, ok. Well I guess if Neovalen has tested it ultra thoroughly, then there may be cases where PMOP fires in situations which won't actually affect the game. The general advice though is to never ignore it, because it can definitely cause major problems. Tannin has said that specifically a number of times - in particular in response to some people who were posting on Nexus, for example, that "it's OK to ignore that warning." I never ignore it. But I have often thought that some of the listed problems don't seem to me to be that likely to cause problems, so I could believe that there might be specific errors that are OK to ignore, if one tests it very carefully; as I'm sure Neovalen has done. But are there important reasons why those mods need to be in the order defined, contravening PMOP? In other words, if they were re-ordered to remove PMOP errors, would that break the asset priorities that SRLE requires? If so, then fair enough. But if not then I would definitely obey the PMOP instructions if at all possible. In other words, I'd want there to be a major known problem caused by disobeying PMOP before I'd think it worth the risk. If there are asset conflicts, I might think about using the Hide File feature so that I could re-arrange the mods the way PMOP wants, while maintaining the asset load ordering required for best effects. Note that I've never studied SRLE in detail, and I'm sure it has been fully tested and works fine in the way it's described. Just as a general point, it's important to mention not to ignore PMOP unless there's no alternative, and one is absolutely sure there's no problems and has tested that very thoroughly. It's both. The PMOP order compares the load order of plugins provided by mods, to the order of those same mods in the mod list. So let's say you have two mods, When Vampires Attack and Complete Crafting Overhaul Remade. Your plugin order is: Complete Crafting Overhaul Remade.esp When Vampires Attack.espBut your mod list is: When Vampires Attack Complete Crafting Overhaul RemadeIn that scenario, you will probably get the PMOP warning: "move When Vampires Attack after Complete Crafting Overhaul Remade" There's then two ways to fix that. Either do what it says, and move When Vampires Attack in the modlist, to be after CCOR. Or you could re-order the plugins, so that the CCOR.esp is before Vampires.esp in the load order. You're right that usually the fix for PMOP is to move the mod in the modlist. That's because usually Plugin load order has been set carefully by BOSS, LOOT, and/or by studying mod author recommendations. So usually you know the Plugin order is fine, and it's the mod list ordering that's wrong; so you change the latter. But to be precise, it's the mismatch between the two that's the problem, not (necssarily) one or other specifically. In the case of this thread, I didn't expect that SRLE would have those errors, and given the OP said he had his mods in the correct order in the modlist, I thought he might not have completed the step of putting plugins in the right order. This is a situation unique to MO. Skyrim vanilla, and therefore every other mod manager, does not allow control of how BSA and loose files are loaded. Outside of MO, SomeMod.bsa is loaded in the same position as SomeMod.esp. Therefore by definition, for mods containing BSAs, Plugin Order = Asset load order. Then any loose files, regardless of which mods they come from, all load at the end after all BSAs. MO replaces that with proper changeable mod ordering, which is far superior. But a downside can be that it allows users to place their mod assets (loose or BSA) in a different order than than their Plugins. When scripts are used, that's considered to be a major risk factor, hence PMOP warnings.

You must always re-order your mods such that the Potential Mod Order Problem (PMOP) disappears. But I'm surprised that you're getting a whole bunch of PMOP warnings if you've followed the SRLE guide and ordered the mods in the order that SRLE describes. If you do have your mods ordered in the same order as SRLE, then I think Neovalen should comment as to why you're still getting these PMOP warnings. I'm certain his ordering will be designed to ensure no such warnings, so I'm wondering if something's gone wrong somewhere. Your empty "category mod" headings should't make any difference - if they're empty mods, they should have no effect on anything else. PMOP warnings happen when you've put your plugins in an order that's incompatible with the order of your mod list. So are your plugins ordered correctly? Have you followed all of SRLE's advice regarding ordering your plugins? I don't know whether SRLE uses BOSS or LOOT (it will definitely use one of those.) If it uses BOSS, it might be suggesting that you apply Boss User Manager rules, such as "PluginX AFTER PluginY". In that case, you can either use BUM and BOSS, or you can convert those rules into LOOT metadata using an external installation of LOOT (MO's internal LOOT - the Sort button - doesn't allow you to add metadata.) But either way, you need to ensure that your plugins are ordered exactly as SRLE suggests. If you've done that, and your mods are ordered as SRLE suggests, then I really think you shouldn't be getting these warnings, so maybe you've not done one or the other?

Yeah I will :)

Yeah OK fair enough. Yeah that's exactly the sort of hardware config where I could definitely see BSA providing noticeable, or even very major performance gains. With a mod like Interesting NPCs, we'd be comparing 10k or 20k small reads, a few blocks at a time, potentially scatted all across a slow HDD, versus one single 200MB file, which is quite possibly written contiguously and so can be read sequentially with only a handful of expensive disk seeks. The difference in that case can be literally 100x or 200x greater. I'll see what I can do on some benchmarks, I think it would be useful if STEP could say "If you have this sort of HW, then extracting BSAs isn't going to hurt your performance much; feel free to do so if you find it more convenient. But if you have this sort of HW, your performance will be decreased by a factor of X and you are not recommended to extract unless you really need to, on a case-by-case basis." Knowing what X is can be helpful for (advanced) users to make an informed choice. (I realise the default recommendation of STEP is going to change to be not to extract by default, and I fully agree with that. But I'd think that it would be useful, and appreciated by users, to provide some additional info to accompany that recommendation. Especially as the default advice in 2.2.9 will be the exact opposite of before: going from 'always extract' to 'never extract'. People will likely appreciate knowing more about why that is, and what factors are involved.)

Ooh, thanks for the heads up! I have voted. And I see it's gained 1k endorsements - an increase of 10% - since 1.2.5 came out. Outstanding! Yeah there's definitely going to be some improvement difference, I guess the question is in what configurations and setups it's significant. Can I ask, how long ago was it when you had HRDLC textures as loose? When did you BSA them? The reason I ask is because of the huge performance boost introduced by 1.2.1 beta relative to 1.1.2 and before (a major optimisation of findfirstfile Tannin said.) At the time I moved to 1.2.1, I had 100% loose and I was on slow HDDs, and I noticed a vast improvement - something like 400% in fact (with all loose and on HDD, upgrading to 1.2.1 from 1.1.2 caused my cold/uncached MO refresh time to drop from 60+ seconds to 15 seconds. Later on SSD, still with all loose files, it dropped to 1-2 seconds max. My refresh time now, with lots of mods now in BSAs, is <1 second.)So I'm just wondering whether it might have been a little while ago that you had HRDLC as loose, and whether there's any chance you're comparing HRDLC-as-loose-in-1.1.2 versus HRDLC-as-BSA-in-1.2.1+? In which case the massive performance boost introducd by 1.2.1 would be a big factor.If not, then yeah that's definitely worth factoring in. I can't say I've noticed any freeze type situations even with 100% loose (including mods like Interesting NPCs which have 10s of thousands of files in their BSA.) But I'm now on SSD; there were definitely noticeable loading lags when I was on HDD. One user - noobzor - did report on these forums he got a noticeable performance benefit, both in startup times and in-game FPS/cell-loads. So I certainly wouldn't discount it. But I still believe it's primarily going to be a factor of disk speed. On slow HDDs, which have appalling random read speeds, you gain enormously from having large, contiguous files that can be read sequentially. On SSDs, 4kb random reads are nearly as fast as sequential reads, and more than 100x as fast as random on HDD. So on SSDs it doesn't matter nearly as much how your data is configured.Of course on any storage there's always going to be a small benefit to reading one file versus 10k or 100k, just in terms of the number of syscalls done. But I would guess that if the storage is fast enough, that's usually in the negligible category when it's a one time load. In my case for example, on SSD moving from all-loose to having lots of BSAs (all large mods as BSA), I saw my shortcut-to-Skyrim-menu time drop from about 30-31 seconds to 26-27. So it's not nothing, even on SSD. It's just not all that important overall, at least in my experience and in my opinion. What would be far more valuable is measurable in-game performance changes, but I didn't experience that. I'm thinking of doing some benchmarks - BSA vs loose on both HDD and SSD - so that we can have some hard data to work with. That might give us a clearer picture from which to base recommendations.

I agree a lot with Aiyen. I'm on my phone and can't write much right now. But I had been thinking myself to re-establish this discussion. There seems to be a general feeling that the changes in the latest MO were somehow meant to make BSA extraction irrelevant. In fact the changes made it safer with regard to the unofficial patches. Regarding performance, on an SSD I can confirm performance differences are negligible or non existent. On HDD it may be noticeable, and one user, noobzor did report useful improvements. All that said, it's worth remembering that no one outside MO users ever extracts. For avoidance of confusion alone, it's worth being mainstream where there is no downside. Similarlywdwe know that Tannin dislikes he feature, hence him moving it to a default disabled plug in. But I absolutely agree that there is no need at all to suggest that extraction is fundamentally bad or broken. Many power users, modders especially, will benefit from it. However as it's been confirmed that, currently at least, no step mods require BSA extraction to achieve the required asset conflict resolution, I agree that default advice to not extract is best. If any mods later require it for conflict management, I would then have BSA extraction recommended case by case.

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/*.swfNearly the entire UI, I think; hence breaking SkyUI and map.swf modsThis was the real problemmeshes/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-breakingseq/skyrim.seq, update.seqNever 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/* filesMaybe 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.

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.

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 :)

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: 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.

Awesome, quick as ever that Tannin :)

1.2.6. follow the changelog of that release regarding the two minor things you need to do regarding the ordering of your non-mo mods. I outlined the requirements in this post: https://forum.step-project.com/topic/5342-reverted-back-to-112-and-now-skse-boss-etc-wont-run-from-mo/?do=findComment&comment=88036. Check the posts following that one for further clarification.

Yeah that should work fine. What I tend to do is run the executable installer and point it at the current installation directory. That works fine too, it recognises when it's an update and doesn't affect your configuration.

Don't install 1.2.7 yet (or 1.2.8); it appears to have a worse bug than 1.2.6.

EDIT: Actually, where I thought I was definitely getting USKP-related script errors, indicating no files were loading properly from the BSA, actually I'm not so sure. The error I saw was from an unrelated, mod override. I'm definitely getting some weird in-game issues, like random messages saying " equipped" and " unequipped" appearing in top left, missing the name of the object. But I can't say for sure that nothing from USKP.BSA is overwriting Skyrim-*.bsa, and in fact I would think I would have far more script error messages if that was the case. Regardless I would recommend reverting to 1.2.6, because if SkyUI.bsa is not able to apply its /interface/*.swf files, then surely there must be other cases as well. But I've not been able to pinpoint exactly which they are, yet.

Yeah - first appearances are that mod-provided BSA files cannot overwrite the vanilla Skyrim-*.bsa files. I'm trying to see if there are more examples. But currently it looks more serious than the bug in 1.2.6 :(Issue tracker link

1.2.7 is now out which should make all of the load order stuff moot! I have just upgraded to 1.2.7 (which I had to do via SourceForge download, because of how awful Nexus servers are), and so I have returned to having Distant Decal and a few other mods above USKP, and therefore above my Non-MO mods.

1.2.7 is now out which should make all of this moot!

You're welcome! And yes, 1.2.6 compared to 1.1.2 is a huge upgrade. I've been using beta 1.2.1 since I came back to Skyrim modding in May, so I can barely even remember what 1.1.2 was like. But I know there was a massive performance improvement in 1.1.2 -> 1.2.1, as well as the addition of the very useful log window, and the fixing of a couple of annoying bugs (like if you re-ordered the Downloads pane, 1.1.2 would screw up.) Then 1.2.1 -> 1.2.6 has the major addition of the Non-MO mods, plus better filtering (choosable and/or, and more filtering options), the addition of the 'number of problems' badge on the 'warning' icon, optional 'automatic fix' button for ordering of mods-with-scripts, and loads more I'm forgetting. So yeah, wild horses would need to drag me back to 1.1.2 now :) Glad it's working out for you! Doesn't matter which you get. That mod will be way after the Non-MO mods in your priority order (i.e., its Priority number is going to be much higher than the last of the Non-MO mods), so whether it's BSA or Loose is irrelevant. The outstanding bug in MO 1.2.6 affects on Non-MO mods, and their ability to overwrite Loose mods which are before them in the priority order. You won't be putting Thundering Shouts with a lower priority number than your Non-MO mods - in fact, it's going to be one of the highest priority mods in your setup, according to the STEP ordering (whereas the Non-MO + Unofficial Patches mods will be the very lowest, or nearly the very lowest.) Although it doesn't matter, for the purposes of 1.2.6, which you choose, you may want to choose the BSA version of Thundering Shouts, simply because from STEP 2.2.9 onwards, using BSAs will be the standard practice. Or at least, STEP 2.2.9 onwards will no longer have the user extract any BSA. I therefore assume that when there's a choice of BSA or Loose download, as with Thundering Shouts, it will also recommend to download the BSA (except in the occasional case where per-asset conflict management is desired, which is not the case for Thundering Shouts.) So if it were me, I'd get the BSA version - if for no other reason than it would prevent me having to potentially re-install it when STEP 2.2.9 changes its practices regarding BSAs.

Yeah good point, I forgot he already said there wasn't a downside. I'll raise an Enhancement request. Actually I am now thinking the second apart might be wrong - you don't need to click Backdate BSAs again if you add more DLCs. It's a bit confusing. However, I've been looking at how the Archive Invalidation method works. It works by adding a new BSA, "Skyrim - Invalidation.bsa", and loading it before any Meshes/Textures BSAs. According to some Oblivion documentation I read, this is called "BSA Redirection" (you can also see this term if you look at the help text in MO for the AI tickbox, in the Profile; that's how I knew to Google it.) The idea of BSA Redirection is that you "trick the game into applying its faulty Archive Invalidation check to the wrong BSA file". I.e. it applies to a BSA file added by MO, which presumably has a very early date set on it. So this strongly suggests that it doesn't matter if all the BSAs have the right date. It only matters about the first BSA that contains a mesh file. If you look inside Invalidation.bsa, you will see that it contains a single file : dummy.dds. So the idea of having "Skyrim - Invalidation.bsa" is that MO is ensuring that the first BSA file that contains a mesh, has an appropriate date. That then apparently works for all future meshes/textures. So I now think: As long as you don't re-install Skyrim, you only need to hit Backdate BSA one time. As long as your Skyrim - Meshes.BSA has an early date, that's all that matters. Other BSAs, including DLC BSAs, are irrelevant. Of course I might be wrong; it's confusing. And I'm not saying we should change the advice to use AI in the profile, rather than bother with Backdate BSA. But for the purposes of discussion and working out how this stuff works, I'm pretty sure the above is correct. Anyway I'll raise that Enhancement with Tannin, and I'll ask a quick question about all this stuff at the same time. Maybe he can clear up some of the doubts.

To give you precise answers: 1. No 2. Yes - in fact, not strictly necessary even to do that; refer to previous post 3. Irrelevant, only Non-MO mods are affected, and they only disobey priority when compared to loose file mods that are before them in the priority order. Hence if you put the Non-MO mods, interspersed with their Unofficial components, right at the top of the priority list, then you can just forget about the issue - you are working around it by putting your priority list in an order where the bug is irrelevant.And regardless of where you put them, mods that are after them in the priority list are not affected, nor are BSA mods that are before them. Just the combination of "mod contains loose files" and "is before a Non-MO mod" is an issue in terms of priority not being as you expect.

The problem exists solely with the mods labelled "Non-MO" - which for nearly all of us, means just Dawnguard, HearthFires, Dragonborn, and HiResTexturePack01,02,03. The BSA files provided by those Non-MO mods, cannot overwrite loose files with a lower priority than them. To be absolutely clear: Non-MO BSAs cannot overwrite loose files in mods which have a lower priority number than the Non-MO mod. Therefore, if you put those Non-MO mods, and their accompanying unofficial packs, at the top of the priority list, the issue cannot occur - so long as your unofficial patches are using BSA files, not loose files that you extracted from BSAs. So, set up your mod list in the following order: Priority | Mod0 | USKP1 | Dawnguard2 | UDGP3 | HearthFires4 | UHFP5 | Dragonborn6 | UDBP7 | HiResTexturePack018 | HiResTexturePack029 | HiResTexturePack0310 | UHRP And ensure that your mods USKP, UDGP, UDBP and UHRP have not been extracted from their BSAs. If those mods contain just an ESP and a BSA, there's no issue. If you previously extracted their BSAs, then re-install them and don't extract the BSA this time. Do that, and everything will be fine, with your mod list priority being observed exactly as you expect. In fact you don't quite have to be that strict. You can, for example, put mods before the Non-MO mods, so long as those other mods only include BSA files. You could also put mods that include loose files before the Non-MO mods, and the only effect will be that those loose files will not obey priority order and will load after the Non-MO mods - this part being identical to previous versions of MO, where Non-MO mods always loaded at (in effect) priority position -1; before everything else. But to keep life simple, just follow the ordering I gave above and showed in my screenshot. What you then do from position 11 onwards is up to you, and will be observed exactly. This complication applies only temporarily; when MO 1.2.7 comes out the issues will be fixed, and it will go back to modlist priority ruling all, as it should do.

Backdate-BSAs sets your /Data/*.bsa files to 01/01/2000 - mod authors would need a pretty major clock error to be before that :) But yeah, AI does appear to guarantee to be safest. There's also the issue that Backdate BSAs needs to be run again if someone re-installs Skyrim or adds more DLCs later, which would easy to forget. I'm certainly not turning off AI now it's on in my profile. So yeah, recommend AI to people. It's one tickbox in your profile settings, then nothing to worry about again. (Of course, then users need to do that again if they ever add a new profile - but arguably, if they're adding new profiles on their own, they know what they're doing.) What I'm now wondering: is there any reason Tannin couldn't just enable AI automatically in all profiles? Ticked by default? Is there any downside? I might raise an Enhancement request and see what he says to that.