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.