keithinhanoi

Oh, darnit. I've spent the last week tweaking the last version (1.09, I think), even to the point of adjusting the enbpalette file (I couldn't handle seeing full black in shadows that isn't actually 0,0,0 RGB). *sigh* Well, I'm keeping my altered palette, but will give 2.0 a whirl. I will say that despite seeing 20+ FPS drops initially with no settings changed, I've managed to turn off enough features so that while it's still visually very pretty, I now only very occasionally see drops below 25, and almost feel I can put up with that versus the wretched vanilla shadowing with significantly higher frames. Anyhow, yes, this is still seems to be the leader in the performance ENB segment.

I've replied to this off-topic SkyBirds banter in the "correct" place!

Hi folks! This necroposting bump is brought to you by the Masters of Offtopic LOOT Thread Posts! I've been using SkyBirds (along with Birds of Skyrim) for nearly a year now, and really haven't experienced any issues that can be traced back to it. That said, prior to the Sheson's memory fix, the sheer number of bird spawns was far more suspect in possibly causing CTDs than the mod's scripts. I'd also like to say that a number of months ago I had a few PM exchanges with steve40, and it's pretty clear to me that he really knows his stuff when it comes to scripting. He's also responsible for some vanilla script fixes (the "critter" scripts in particular,) of which some of that work eventually made it's way into the USKP, if I understand things correctly. In my Papryrus logs, when I do have them turned on, I don't see loads of errors from SkyBirds once the game has started - just a long list of missing objects references before that, which is normal and will get cleaned up. Save game bloat? Haven't seen it. Keep in mind that added/moved objects and NPCs do add additional bytes to your save game, but these things get cleaned/flushed out by the gamen on a regular basis. steve40 has become a father, and has said he's lost all interest in playing and modding, so I suppose you could say the mod is unsupported, but with the advent of tools like the SaveTool savegame script "cleaner", I think there's less to worry about. Anyhow, I have no plans to stop using it with as little trouble as it's caused me. It would be nice if someone could "pick up the torch" with the mod and continue to develop it - if steve40 has no plans to do so and would agree.

I think changing to this recommendation is a very good idea. Tannin has already mentioned having a significantly large number loose files is more resource intensive, and potentially leads to a significant increase in drive space used (a consideration for SSD users if the firmware doesn't already automatically compress written data.) Also, MO already has a post-installation BSA extraction feature - right click on the BSA in question in the Assets tab of the right-hand pane to do this - which means you don't necessarily have to unpack every BSA at mod installation / update just because you think it gives you more control over the assets. You have that control at any time - so I think it's better to do that when you realize there's a conflict situation that requires unpacking the BSA. In addition - unpacking BSAs for mod updates has a potential "catch-22" (see my explanation under TheBloke's quote below.) Tech - I'm sure you are well aware, but I think it still needs to be pointed out that just like a .esp plugin patch can carry foward records from mods earlier in the load order priority, required conflicting BSA assets from lower priority mods can be extracted and moved into a special "assets patch" mod that can be set with a higher priority than mods with BSA containing the unwanted conflicting assets. I don't know how many cases there are in the current STEP lineup which would require BSA extraction, but this alternative approach is something to keep in mind. The bottom line here is that MO allows for this kind of flexibility in a solution for conflict management. I don't really see the problem here. In Tannin's suggested change - he specifically says that sorting of mod priority/"install" order based on plugin-load order could be disabled to allow the user to manually set mod priority - just like we have now. But instead of the mess that is currently caused by mixing "MO managed" and plugin-load order managed BSA assets, MO's "dark magic" method to build the Virtual File System /Data directory would be used for both priority sorting methods ("auto" and manual) - which the current version of MO doesn't do now (currently it releases plugin-load order managed BSAs to be handled by Skyrim's plugin+BSA loading mechanism.) As a result of the proposed change, this would allow STEP to recommend turning off mod priority auto-sorting (as you've called it) for all mods except the UPs, and then start ordering them according to the STEP Guide - pretty much as you have it now. So there are actually no workarounds needed for what Tannin's proposing. I think the only thing I would suggest here is the ability to globally toggle mod priority auto-sorting & manual sorting for all mods simultaneously, and more importantly, a preference setting to change the default from mod priority auto-sorting to manual. From the STEP Guide perspective, this would simplify things so the steps to add would be: [*]Before installing any mods, open the Settings menu, click the Advanced tick-box to enable it, and the un-tick the option "By default, sort priority of mods with BSA assets according to plugin load order", so by default the priority of all mods installed can be manually set. [*]After installing the Unofficial Patches, in the left-pane Mod Priority list, enable the tick-box in the Mod Priority Auto-Sort column for all four Unofficial Patches. And that would be it. So the UPs' BSA load order would be set by plugin-load order as set by LOOT, meaning they would be in the correct load order slots (just after the respective DLCs,) and the priority order for all other mods would be manually set. The importance here, as Tannin stated is for non-STEP users (and there are a few out there last time I checked,) the default would be that all the priority/"install" order of all mods with BSAs would be set according to accompanying plugin load order. The SMIM example that you've mentioned wouldn't actually apply here, because in Tannin's new "compromise" version of his suggestion, all mods with loose files would have manual mod priority sorting by default - and SMIM has no BSA, so we don't have to worry about any of its .esp plugins setting its place in the mod priority order. This is why in my invented example for the global mod priority auto-sort setting, I called it "By derfault, sort priority of mods with BSA assets according to plugin load order." You turn that off, and suddenly MO would work just the same as it does now - except you can still toggle auto-sorting on a per-mod basis without the "mess" as Tannin described. This unfortunately creates a major "catch-22" problem when installing updates of BSA + loose file mods which are meant to be installed using the merge option instead of replace (because the update doesn't include the full set of assets.) So, say the author has a "main" BSA with the default assets, and their FOMOD installer includes options with loose files that are intended to override some contained in the BSA. It's normal of the author to expect this to work because without any mod manager or with NMM, the loose files load after all BSA. So I wouldn't blame the author for doing anything wrong by setting things up this way. Now, the latest update of MO deals with this correctly if you want to unpack/extract the mod's BSA to loose files. So, when installing, essentially MO unpacks the BSA first, and then adds the loose files that were installed, overwriting anything unpacked from the BSA with the same name. So that works just as expected. However, if you install an update for the mod, which just includes a replacement BSA, you're going to run into trouble. Because we've previously unpacked the mod's BSA, now everything is mixed together as loose files. How does MO know which ones were originally supplied by the installer as loose files? It doesn't. So when you install this update using the merge option, and allow MO to unpack/extract the BSA, it's actually going to overwrite some of the files that were originally supplied by the previous install as optional loose files. Thinking through this, I can't think of any way of MO knowing what to do automatically, without somehow keeping track of which files were previously supplied as loose files and not in the unpacked BSA. However, there is a bit of a workaround you could use in this case, and it means you need to keep a backup of the previous install archive, or download it again. So when a mod has an update which just contains a replacement for a main BSA that you had previously unpacked, and not any of the optional loose files, you do this: [*]Re-install the previous version of the mod again, selecting overwrite, but this time don't unpack the BSA. [*]Install the update, selecting merge, but also don't unpack the BSA. [*]Go to the Assets tab in the right-hand pane, and find the BSA for the mod in question [*]Right-click on the BSA, and select Extract... VERY IMPORTANT: This workaround is based on the assumption that Tannin also applied the unpack-BSAs-not-to-overwrite-loose-files fix in MO 1.1.2 to this other method of unpacking a BSA. Tannin - Did you also apply that fix to the Assets tab Extract BSA contextual menu feature? Not sure what Tannin regards it as, but I've always thought of the Filter list as a "fly-out", not a real member of the "pane society" who can never be made to disappear from view! Personally, I don't look at the mod priority list as install order either, but started referring to that list/pane as the priority/"install" order list in this thread because other people / STEP refers to it as the "install" order list, and wanted to make sure people were able to following what I'm talking about.

RE: unpacking every BSA as a default: With Interesting NPCs as an example - why bother? There are no duplicates between the BSA & loose files, and in my line up, I'm only seeing one script conflict, and that's an overwrite of a vanilla script. If I unpack it, I've just added unnecessary additional processing time (according to Tannin), and for no good reason. Be smart about what you unpack. Install the mod with the BSA intact. Use MO to show you what conflicts there are - it will display conflicts of files inside BSAs too, folks. If you find there are things that you need to change or you want to hide files contained in a BSA - then extract it. You could use BSAOpt, but even easier is just to go to MO's Assets tab in the right-hand pane, find the BSA, right click and choose Extract... However, just remember what TheBloke has explained about some further bug in 1.1.2 that need to be worked out with regards to BSA assets overwriting loose assets in the same mod. An easy way to handle it for now is to temporarily move them into their own folder in the mod's sub-directory, unpack the BSA, and then move the loose files back, overwriting as you see fit. Done! ----- CJ - on that sewer cover thing - could that be helped in my case by changing any distance detail settings in the .ini? I'm assuming the cover texture doesn't have an LOD (if that's even used), and there's something about it not showing up past a certain distance that I could change to stop it from switching when I'm close enough to see it.

CJ - Thanks so very much for that W&C - Holidays patch - now I can actually try it out! Ditto for the 3.4.1 update. I noticed Skyrim Sewers 4.12 didn't make it into this newest update - I notice it mentions some removed unnecessary navmesh edits and other fixes. Not missing out on much, are we? Speaking of SS4 - I have noticed that the texture for one of the sewer covers in Solitude switches to a different angle when I am a certain distance. If I move very slowly, I can see the other texture being "swiped" in. Any idea what might cause that?

Tannin, your "compromise" version of your suggestion sounds great. So that starts the MO user off with everything working as it would with no mod manager / NMM, and then the user is "free" to start changing things to override that paradigm.The main matters then are technical implementation, interface / GUI implementation, and also compatibility with the other games that MO works with besides Skyrim (which I've need seen any mention of yet.) For BSA mods this is not a problem, because esp <-> bsa is a one-to-one mapping. Each bsa would be in the right place as specified by the plugin-order (which is the same as NMM would have placed them which is the same as what the mod author probably tested) and the mod order is irrelevant. MO would still have to place it somewhere, maybe aligned with the largest esp (in terms of filesize) or the first esp when ordering alphabetically. It's arbitrary but that doesn't matter, because, again, the mod order has no impact.For loose file mods MO would probably apply the same mod ordering (i.e. by largest esp). This is still arbitrary but less so than installation order! Unless you have a guide telling you where to place a mod this solution is still better than having mods simply appended to the end of the list and if you have a guide all you have to do is toggle auto-sort and do as the guide tells you. Apologies because I also asked this question after TechAngel85 - I think I read it wrong at first! So from what your describing, it will be very important for users to pay close attention to what's displayed in the Assets tab - because that's the only place that this one-to-one mapping would be visually represented. If set up this way it would also means that it would be very important to add another column in the right-hand mod priority/"install" list pane with clear visual indication of whether a mod's assets are plugin-order priority managed, or manually user-managed.

These are sweet! Though I'm slightly less in love with the Riften windows, I find the solitude ones are far superior. I'm just going to miss the yellowish glow at night - some are colored a bit too much on cool (bluish white) side.

Sure, but MO has a history of changes being made to accommodate tools / mods / NMM updates that would otherwise not work due to the way MO handles mod management through its virtual file system. Some viable suggestions have already been offered for a workaround with the current version of MO to the particular case of the UPs need to mix between the DLCs in priority order. In a "sandbox" type of environment as STEP provides, a specific guide to a workaround can be created, and consistent results can be expected. However, I don't think Tannin's new suggestion of changing how MO handles priority management is just a knee-jerk response to the UP/DLC priority order quandry. He's looking at the larger potential looming issue of mod authors creating mods with the assumption that the accompanying BSA assets will be loaded in the same order that their plugin is. This assumption is based on the way the game works without using any 3rd party mod manager, and it is also the assumption when using the mod manager that AFAIK the vast majority of people modding Skyrim (and probably other TES games) are using, NMM. Right now, in order to adhere to that assumption in MO, the user needs to manually set BSA priority to match plugin order. Tannin is talking about automating that as a default in MO, but still allowing for manual intervention by the user. Yes, it would help address the special "hack" (or whatever) situation of the UPs that otherwise works correctly when not using MO, but it's more than just addressing that. I could also fall back to the argument that all of these products of hundreds of hours of people's free time are shared with us at no cost, and it is up to us whether to use it or not. And on that note, I feel it is extremely gracious of Tannin to ask for input here. Nothing says that he is required to do so.

When I read this, I had to chuckle. With all due respect to everyone here - we are playing a modified game. A good number - possibly a majority - of mods in STEP are hacks of one sort or another. SKSE? It injects itself into the executable to do things Skyrim wasn't designed to do. A hack. Sheson's memory block fix? A hack. ENB? Also a hack. All of these things "shouldn't even be possible." Now, let's just for argument's sake say that the UPs were made as .esm master plugins, and not false-flagged .esp plugins. There are plenty of very well known mods that use an .esm master plugin. Those get special status up (early loading) in the .esm master section of the load order. And the UPs as esm files could still require to be "sandwiched" between the official DLC .esm/.bsa content. And we'd still have the same thing to work out. There's no need for me to say anything disparaging about the UPs because they do my game a whole heck of a lot more good than bad. Yes, they require somewhat peculiar requirements in terms of their load order (both plugin records & BSA encapsulated assets), but the decision to do so wasn't made easily and without thought - and it is what it is now - so please for the love of the divines can we move on? I'm afraid that the one fairly major drawback to copy the UPs BSAs into <Skyrim>/Data is that MO no longer "sees" those assets when reporting file conflicts. So it seems the solution of making MO see the DLCs as mods in the left-pane priority list would be a better way to go, however the workaround is implemented. Thanks so much for taking the time to answer my questions (or show how your concept resists the "mud" I was flinging at it!) I have a much better picture of what you're proposing, but I'm still unclear how the manual user management of mod/BSA/asset priority would be handled GUI-wise. Are you saying for user-prority managed mods that their BSAs could be manually drag-and-drop sorted in the Assets tab, -or- all of the mod's BSAs / loose files' priority would be set by the mod priority (drag-and-drop sorted as you can do now?) If the answer is the latter, then my question is where does that mod get put priority-wise if I then turn on MOs priority sorting for it (based on plugin order) - if there are a bunch of user-priority sorted mods between the two plugin-order-sorted mods where the mod for which I'm toggling MO-priority-management to on should go? Example - say at first I've got this mod priority order in the left-hand pane: A - priority set by plugin-order B - priority manually set by user C - priority manually set by user D - priority manually set by user E - priority manually set by user F - priority set by plugin-order G - priority manually set by user Then I toggle the priority management for Mod G, which according to the plugin load order as set by LOOT, should go between Mod A and F. So where would MO place Mod G? And one other question. What would happen if a mod in the left-hand pane priority list contains multiple plugin & BSA pairs, which LOOT actually orders in quite "distant" plugin load order priority slots? I can't think of any mods off the top of my head that do this, but certainly MO allows users to pile a bunch of different mod plugin/BSA pairs into one mod slot in MO's priority/"install" order list. Since in your concept the default is sort a mod's priority/"install" order based on its plugin load order (as set by LOOT/BOSS), then it's unclear where the mod would be placed when it contains multiple plugins in quite different load order slots. Anyhow, if these kinds of catch-22 things have already been worked out - I think your idea is quite sound, because it starts off "safe", working in a very similar way to other managers, but adds the flexibility of still "mixing" loose assets to be effectively installed between plugin-order-sorted BSA assets (I'm not sure everyone else is catching that fact,) AND also allowing users to switch to full control over plugin/BSA/loose file load/priority order. It really is a "have my cake and eat it too solution". Finally - a parting note on the efficacy of LOOT: LOOT doesn't really "know" the correct load order. It mainly bases the load order on two things - explicit masters (in a plugin header's master list) and plugin record conflicts. The goal is to make sure plugins load after their masters, and with the least number of plugin record conflicts. This is a very smart algorithm, and can address most conflict issues. But it can't account for implied masters - plugins which are built with the assumption of a certain load order, but didn't require any masters to be added to its head, and especially important - LOOT can't on it's own account for required BSA asset load order. That said, LOOT's own special masterlist is getting updated frequently, which is step-by-step growing with rules that handle these two areas that its algorithm can't handle - but it's going to take a while, and there are lots of mods out there that were built based on a BOSS load order which could have an implied master and/or assumed BSA asset load order situation. What I'm trying to say here is that although having BSA priority order set according to accompanying plugin order is probably in most cases result in a stable game - it is still entirely possible that LOOT will produce a plugin load order that sets the BSA asset priority order with some undesired consequences or things that don't work as expected in-game. So - my vote is still in with keeping user control over BSA asset priority order in some manner in MO However, if it turns out that your concept is not entirely feasible, then I'd like to put in my vote for TheBloke's suggestion for handling the "exceptional" case of the UPs, although it would still leaves setting plugin load order tied to corresponding BSA asset priority order entirely in the hands of the user.

Okay, well, thanks for explaining it. I've got my brain properly wrapped around this, but it still hurts thinking about it. fireundubh, a last option for a personal solution could be to try just making symbolic links for the official DLC BSAs only - and not any of the .esm plugins. But yes, I figure the whole symbolic link thing would be a no starter for the general masses. So basically, what you are describing is MO doing what it does now with BSA management, but adding the default option of allowing BSA asset priority to be set by the plugin order - but those BSA assets are still loaded using MO's "black magic" rather than the game's native plugin-loaded BSA mechanism - right? It's very interesting, but there are quite a few what if situations that I could come up with that I'm not sure how to answer with this concept as you've described. First off, when you toggle BSA asset priority between user managed and plugin order determined, what happens to that mod in the left-hand mod priority list pane? Does it get moved around, or are we now going to manage BSA and loose assets in the Assets tab only? Then, what if the mod in question has two BSA's - say for example Immersive Armors, which has a main plugin and BSA, and a secondary "dummy" plugin and BSA pair. Currently, I can disable the dummy plugin, but in your new scheme, in absence of the dummy plugin, I need to then manually manage priority order of IA's second BSA. It might be set by the mod author with the assumption that the second BSA loads after the main one, so I need to be aware of that and set the second BSA priority to a higher number (aka further down in the list for x to understand) than the main mod's slot. As an end user, I might also have extracted some textures to optimize them, and they could also be in the same MO mod folder for IA. With the IA example it seems tricky, but then the best way to represent it visually in the GUI would have an assets management tab, which splits apart every BSA into a single line entry (to get around mixed managed and plugin-order determined BSAs, plus loose files contained in the same mod.) So with the IA example, you'd see this: [+] Hothtrooper44_ArmorCompilation.bsa | Immersive Armors [-] Hothtrooper44_Armor_Ecksstra.bsa | Immersive Armors [-] Loose files | Immersive Armors [ ] DeadlyDragons.bsa | Deadly Dragons - Dragonborn In this represenation, [+] is a plugin-ordered BSA (the default), [ ] is a user-managed BSA (un-ticked), and [-] is user-managed loose files or an "orphaned" BSA. If the Assets tab becomes the place to manage asset priority order, then the left-hand pane would merely become the list of installed mods, and no longer be used to represent priority for assets loading. A different paradigm, but I can't think of any way to deal with the potential mixed situations as I've described with the IA example. Now another question is about what happens when you turn plugin-order determined BSA load priority? Does that BSA in the list jump into it's place between two other corresponding plugin-order managed BSAs? What if there are some user-managed entries between them? Will MO put it at the top or bottom (closest to the next lower or higher numbered plugin-order managed BSA)? Anyhow, like I said, the idea is very interesting, but it will require some considerations about how the GUI need to be re-implemented to accommodate the method.

Yes, yes, I know about symbolic links. Been using them in MacOS, *nix, and Windows for several years, including space-saving tricks when I had a smaller SSD + a large HDD. I use them so often I even installed this software, which allows you to make symbolic links using the contextual menu in Windows Explorer. One right click to pick the source, and then another right click to drop the symbolic link in your desired location. Cool stuff. But - no, my second suggestion with moving the UPs BSAs out of their MO mod folders into the real /data directory won't work with symbolic links, because of that operative word... move. Symbolic links are for making a "doppelganger" file or directory in a different location, that the system will treat just like the original. MO will only move the UPs BSAs into the "/data" group in the assets Priority tab if their BSAs are located in the real /data directory and not in the MO mod folder. Explained another way: There can only be one copy of each BSA being used, in the real /data directory, for it to show up in the /data list in the Priority tab (of the right-hand pane). So the symbolic link method can only be used as a more elegant way of making MO see the official DLCs as "mods" in the left-hand mod priority/"install" list pane. And yes, using symbolic links will preserve the pristine /data folder so that the Steam validate archive feature works, and updates work, etc. But I imagine where it seems like an elegant solution to me, there's probably some situation I'm not thinking of where a user could completely screw it up. So then if one BSA is not "managed" (un-ticked/un-checked) it goes like this: [*]Registered (official) BSAs [*]All managed (ticked/checked) BSAs -and- loose files, loaded according to MO's mod priority/"install" order [*]All un-ticked/un-checked BSAs not managed by MO, loaded according to their corresponding plugin order or if it's more convoluted than that, then I think on this one I just can't wrap my brain around it, sadly. Hmm, I didn't know that. I can't fathom why it would confuse people. But as long as we know it's correctly loaded after the original vanilla skyrim BSA assets, then fine. If you do decide to complete get rid of BSA priority management as it stands currently in MO, I sincerely hope you'll consider keeping the conflict reporting at least for loose files. Better yet, let MO continue to show asset conflicts that come through from the plugin-loaded BSA assets - because despite not having control over it directly in MO, it could be handled through LOOT/BOSS user rules to change plugin load order, or by extracting the assets desired in the game and throwing those loose files into a separate mod (so the loose files "win" over the BSA loaded versions.) I have to say, being able to hunt down assets provided by two different mods in the way the MO does it is a complete godsend. Anyhow, I've made my two suggestions, as has been nicely summed up by TechAngel. Shall I make them official suggestions on the MO Bug Tracker site, Tannin?

CJ, does this get all of the seasonal/festival objects that appear to be placed correctly - such as strings of flags are again attached to the corners of buildings instead of floating? Also - are there any other REGS mods you can think of which would "break" the placement of those temporarily added objects? Ripple gives a lot of thought to everything he does, and really knows his stuff. In essence, because both CRF and InconNPCs are making similar changes to the Thalmor Embassy using somewhat different methods - which result in a bit of duplication and "overcrowding", the patch needs to revert some things CRF does back to vanilla state so that the InconNPC changes are the one ones applied. It's probably really important to note here that this patch definitely should NOT be cleaned for ITMs in TES5Edit, because that will "break" some of the things it does in reverting some records to vanilla state. (Note to mod authors and patch makers - there are tricks to "trick" TES5Edit into not recognizing intentional ITMs, such as giving a record an Editor ID (EDID) if it didn't have one in the vanilla record, or possibly by changing the position of an object by 0.0001 - which wouldn't be noticed in game.) Both my post on the forums here and Arthmoor's post on the AFK Mods Forums have the full list of LCTN sub-record types that get forwarded and don't need patching, so print it out on a small card as a "cheat sheet." phryxolydian - I'm looking at you...

Ah, okay, I see. So just to be sure - If all BSAs are left managed by MO, then the assets priority load order is: [*]Registered (official) BSAs [*]All managed BSAs and loose files, loaded according to MO's mod priority/"install" order and if BSA management is turned off for even one BSA, then the assets priority load order is: [*]Registered (official) BSAs [*]All managed (ticked/checked) BSAs, loaded according to MO's mod priority/"install" order [*]All un-ticked/un-checked BSAs not managed by MO, loaded according to their corresponding plugin order [*]All loose files, loaded according to MO's mod priority/"install" order Have I got that right? I'm also still curious where Update.bsa is, from MO's perspective. The .esm is listed in the plugin load order, but the .bsa doesn't show up in the assets tab. So yes, my second suggestion in my above post is a bit of a hack for your number 5, but I don't see how it's a "mess" because after relocating the UP BSAs to the real /Data directory, MO allowed me to get the Official & UP BSAs in the correct load order. That's what were trying to do on this one point, correct? It does require not unpacking the UP BSAs, but I haven't seen any ground shattering reasons why they would need to be unpacked, especially when any modified assets could be put in another separate mod with a higher priority value (and thus override the ones in the UPs' BSAs) So - is there any way to "trick" MO into thinking the UPs - or even just their BSAs - are located in /data rather then separately, so that the UP BSA priority order can be managed among the official DLCs BSAs? Yes - I know it's a bit of a "hack", but then so was making them false .esm with all of the good reasons to do so, etc. etc. Otherwise, the thing that is most worrisome about throwing out BSA management is how MO would then present conflicts. Would it still properly show conflicts for the plugin-loaded BSA assets with regards to the loose files that load afterwards? Also - the ability to disable "dummy" .esp plugins and still load their BSAs would be gone, right?

Yes, that sums it up pretty much. I suppose after reading your rant I could apologize for having knowledge of this (only having finally wrapped my head around it about a month ago) but not alerting you - I was going under the assumption that you were already aware of it. But I was certainly not holding any secret discussions with anyone else. Just the good old keeping it to myself, perhaps due to not having an absolute feeling of 100% confidence about the whole thing. Yes, that definitely won't work, because there are other mods which are built around the idea that their scripts and other assets will overwrite ones supplied by the UPs because the UPs are "guaranteed" to load very early. I believe Live Another Life and Cutting Room Floor do this with some UP-supplied scripts for example. But there are plenty of other mods expecting that some of their assets overwrite the UPs "fixed" ones. So - now I think you've reminded me why you suggested not mixing MO-managed and un-ticked BSAs loading based on plugin-order. It's because MO's managed BSA assets + loose files are loaded before the plug-in loaded BSAs. I guess that begs the question of why MO allows BSA management to be changed on a per-file basis rather than a complete on/off toggle switch. Anyhow - a bit of good news: I've just realized that there's another possible solution/workaround to get the official DLCs BSAs and the UP BSAs to load in the correct order in MO: Instead of what I explained in my previous post, keep all the official Beth's .BSAs in /data, and move the UP's .BSAs into /data. This moves the .BSAs in MO's perspective into the /data folder, as viewed in the Assets tab. When I did this, they magically got ordered correctly! Not sure how... maybe based on plugin order? However, if that doesn't happen for everybody, then a little-known trick of drag-and-drop re-ordering can be used to get the correct BSA priority load order with the official BSAs followed by the corresponding UP BSAs. This trick only works with BSAs inside a single "group" (with the tiny display toggle triangle next to it. Screenshot time! This solution allows for an almost pristine vanilla+DLC /data directory, and won't "break" Steam's auto-update and archive-validation features. And since the virtual /data directory presented to Skyrim combines the contents of the real /Data directory with all active mods in MO - TESV.exe doesn't know that the UP's .ESMs and .BSAs started off in different places. Downside to this option? Every time the UPs get updated, you have to remember to move the new .BSA out of its respective MO mod directory and into /Data. A little cleaner than my previous suggestion though. I'm afraid in testing this out I only got as far as loading up a couple of save games, and everything seems to be fine. It's the end of the day in my time zone, and I've got a work project to finish tonight, so I'll leave the testing and ongoing discussion to the rest of you for now.

Finally trying to catch up with this thread. Just want to say off the batm it's very difficult to follow due to all the misunderstandings and inconsistent use of terms. That's funny - because I changed to this about a month ago, when I noticed that although I had my cleaned Beth's .ESMs in the correct priority/"install" order with the corresponding UPs, the BSAs were not loading in the proper sequence. To be crystal clear about this, some pics would help. So this was my mod priority/"install" order in MO's left-hand pane: Note that the (cleaned) Bethesda mods were only the .ESM, without their corresponding .BSA files. But then, in MO's Archive tab in the right-hand pane, the BSA assets priority order shown was this: This was of course despite having the correct plugin load order, as set by BOSS or LOOT: So I figured I had two choices - either: 1. un-tick/uncheck just the official & unofficial BSAs so that MO wouldn't manage them, allowing them to load following the order of the .ESMs, or 2. duplicate or move the official BSAs into MO's mod folders for the three official DLCs (with (cleaned) in the name in first pic above), which would then allow MO to manage BSA asset priority I decided against #1, because even though the official & unofficial patch BSA's would get loaded following the .ESM plugin order, and theoretically those .BSA assets would get loaded before all of the ticket/managed .BSA and loose file assets, I recall asking Tannin about mixing & matching managed & not-managed .BSAs in MO, and he recommended against it. I should also note with regards to option #1 that Update.bsa does not show up anywhere in MO's Archives tab, so there's actually no way to disable MO's management of that BSA, and to be honest I'm still unclear about how the load priority of official .BSA assets are handled by MO (maybe Tannin can clarify on this specific point.) So, because I have an SSD where space is costly and "precious", and I have Steam's automatic updating for Skyrim turned off, I went with #2. I moved the BSA files for the three DLCs into the MO mod folders that already had the cleaned .ESMs, and stuck the original official .ESM's in /optional/original plugin, like this: So, after moving all three of the official DLC .ESM & .BSAs in this way, then MO's Archive tab showed the .BSA priority load order matching my mod priority/"install" order - as can be seen here: Note the lack of Update.bsa in this list, but my assumption is it is loaded after Skyrim - VoicesExtra.bsa. At this point, as long as I leave all .BSAs ticked and managed by MO, I believe that theoretically I could unpack the unofficial patch BSAs and everything would work as expected - because MO treats all managed .BSA assets and loose files as "equals" in determining what gets loaded into its virtual file system with overwrite priority based on the mod priority/"install" order. Theoretically, as I said, but I have absolutely no reason to do it, so I'm not even trying it. So what's the moral of the story here? Well, if there was some confirmation on exactly how un-ticking/un-checking the Beth's & unofficial patch .BSAs would be handled by MO, then my option #1, as explained above, could be a viable solution for an update to the STEP Guide. However it would require the .BSA assets priority loading in MO to work like this: Registered Skyrim base .BSA files load Update.bsa loads Un-ticked/un-checked .BSAs load following .esm / .esp plugin load order All managed (ticked/checked) .BSAs and loose files load, according to MO's mod priority/"install" orderIf that's the way MO works now, then this whole sub-topic can hopefully be put to rest. If not, then perhaps the solution could an option in MO to allow Skyrim's official DLCs to be treated as mods in MO's left-hand mod priority/"install" order pane - without having to copy or duplicate their files into the MO folder structure. Otherwise, then yes, you'd have to do what I've outlined here (and others have already suggested.) Major apologies for arriving "late" to the party and also for not posting about what I had done before now!

I started my new play-through not long after v4.01 was released, and so far it's been working as advertised. I'm not using Frostfall, but I am using iNeed, Convenient Horses, Footsteps, Wet & Cold, Enhanced Blood Textures, and AutoPV, among perhaps a few other script-heavier mods I can't recall ATM. With all that, I'm not seeing the same massive lag as you, phryxolydian. Sure, there's a bit of a delay after the screen goes black, my gear is taken, and then the "recover your gear" quest is started, but nothing that gets me checking my watch. Version 4.5 has been put up today, and requires a special "clean save" procedure (explained on the mod's description page) if you want to attempt to continue an in-progress game with the update. According to the comments thread sticky, from a user perspective the update offers only some bug fixes, but this new version's main focus is on paving the way for custom content that can be added with additional plugins. A recent check with Papyrus logging turned on showed very little "noise" after an initial slew of messages as the savegame got loaded, so I guess I'm going to be a sucker and try this so-called "clean update" method and see what happens. I'm only on Level 16, so at worst, I'll have to retrace a few days worth if it turns out a new game is the best way to go. A bit off topic, but AutoPV also got a major update today, which requires a "clean save" as well - and the author even suggests using the Save game script cleaner. How times have changed!

Oops. I made the same mistake. LOL! Typical Dunmer-hating Nord. Ugh. Tell me about it! Balderin, my new play-through Wood Elf, is really offended. CJ - seeing the patch you created for Millwater Retreat listed in the ETaC v11 patch installer was the first I've heard of that mod. Not really within the scope of REGS, but it's very interesting nonetheless as it's quite a departure from the typical player home mod.

Yeah, I saw that too - thanks for pointing it out (and answering your own question! ) Well, this confirms that MaxHeightData (MHDT) is a record type that does need conflict patching if a later-loading plugin blanks out the data needed for DG/DB to work properly. EDIT:And... it would seem it's not necessary after all.

I know that Aurora Village was out first, but I kind of wish there was an optional Aurora Village Relocated mod. Of course, it unfortunately wouldn't fit in with the local landscape / surroundings anymore. Oh well. Kulde's post? Don't you mean my post? :O_o: Either way, as I said before, ELFX-Exteriors simply add/changes too many lights to work well with ETaC, Dawn of Riften, and some other REGS mods, and I highly recommend not attempting to use it with ETaC or REGS. It appears so, but the patch has also been updated. From the v11.0 changes list: 8. Winterhold - Changed WoodWall02 texture (more weathered). - Added player house (purchasable from Malur Seloth). - Removed guard barracks. - {CJ} Re-built Winterhold Lanterns of Skyrim Patch. - {CJ} Updated Winterhold EWDR Patch. - Changes built-in for 3DNPCs -- No patch needed.Thanks, CJ, for your tireless efforts into REGS & the ETaC project!

This prompts a rare anim-gif moment from me...

Well, well, well... MadFrenchie is back - in Markarth of all places! Only on Steam Workshop ATM, but I imagine we'll see the Nexus debut soon.

Yes, he has. For more details, try this trick:

Nothing a little old disable in the console or TES5Edit wouldn't fix. There's nothing saying a user has to use a mod as is after they've downloaded for personal use. Yes, it requires re-implementation of your personal preference modifications each time a mod is updated, but isn't it worth being able to enjoy it otherwise if it's just a few minor details?

I finally had a chance to ask about it on the TES5Edit WIPz thread on AFK Mods, and zilav replied. Basically zilav says that 0.01 change that sometimes happens in xEdit is due to floating point rounding and the way the program works. In the case of the Sound Descriptor values where this is happening is a non-issue. A 0.01 change doesn't really make any difference. So, you can continue making patch records for AOS worry-free!