AS OF JULY 4, 2018, THIS MOD PAGE, AS WELL AS THE Qwinn's Bottomless Bag of Patches
PAGE, ARE DEPRECATED.

ALL PATCHES ARE STILL AVAILABLE AND IN A FAR MORE CONVENIENT FORMAT AT THE FOLLOWING LINK:

QUASIPC - Qwinn's Unified Automated Self Installing Patch Compendium

THIS IS NOT AN ANNOUNCEMENT OF END OF SUPPORT FOR THE PATCHES.
QUITE THE OPPOSITE.
OLD PATCHES WILL BE UPDATED AS NEED ARISES, AND NEW PATCHES WILL STILL BE DEVELOPED.
JUST AT THAT PAGE, NOT THIS ONE.

I hope you'll all join me there.  I think you'll all like the new, very sophisticated automated patch installer package.

Modders, Guide Authors:  If your page has a link to this or the Bottomless Bag of Patches page, please redirect your links to the new page.

I will leave these pages as is for a time, until links have been
redirected, but there's really no reason I can think of to prefer the
old patch style over the new one.  If you can think of such a reason, please do let me know at the new page.

------------------------------------------------------------------------------------------------------




FAQ

Q:  What is this mod?

A:  It's a Proof Of Concept "magic" variation of my Qwinn's Bottomless Bag of Patches mod, which currently has 25 compatibility patches for various popular mod combinations with many more to come.  If you want information about the patches themselves, please go to that page.

Q:  What's the variation?  Why do you call them "magic featherweight"?

A:  These are the same patches, except they do not use up a slot in your 255-plugin limit load order!!  Yes, really!  Though, for the time being, I'm recommending they only be used with Mod Organizer 2.  And don't use them with Creation Club content, at least not yet.  Let's see how the initial trial by non-CC users goes first.

Q:  Do I really have to read the wall of text below?

A:  If you wish to take part in this experiment, and for now it IS an experiment, you really should.  A lot of it actually has nothing to do with this new patching mod, it's an in-depth discussion of the proper placement of patches in your load order, which applies even if you download nothing from this mod, and which contradicts the conventional wisdom of the matter.  With examples.

Q:  HOW DOES IT WORK, QWINN?!?

A:  These patches are pseudo-ESL's... meaning, they are ESP's, but they have the "ESL" flag checked in the header.

Q:  ESLs?  I heard those are bad, especially for patches!  What gives?

A:  When true ESLs were introduced for the Creation Club, they were tested and found that they do not obey normal plugin order rules.  A true ESL will be forced to load immediately after the ESM's.  This is fatal for patches as it almost always makes them impossible to place after the mods that they are attempting to patch.  You also can't make an ESP a master to an ESL.

Q:  So why don't these patches have that problem?

A:  Because they are still ESPs.  They just have the "ESL" flag checked in the header record.  The result of this is that they obey normal plugin order rules, and other ESP's can be added to them as masters, BUT, they are loaded in ESL FE space, meaning they don't take up a slot in the 255 esp plugin limit.

Q:  Has this method been tested?

A:  By Fallout 4 modders and players, yes, for months actually.  An example is this mod, "Visual Reload Compatibility Patches"  by Zeridian, who I am very grateful to as he made me aware of this functionality., and I've spent a week playing my game to confirm that they work properly in SSE too.  I've tried like hell to break them, and can't. They seem to work perfectly, even added to an ongoing game, and even replacing the normal ESP patches from my QBBoP page with the new ELSified ESP in an ongoing game worked fine.  That is why I have not renamed the ESPs.  If you're already using my normal ESP patches, you can uninstall that, install this, and you won't even get a missing ESP warning.

Q:  How did you test that these obey the proper load order?

A:  Mostly by testing the blackface bug.  As anyone who has used multiple NPC replacers affecting the same NPCs knows, if they are not ordered in a very precise manner, with a synchronized install order AND plugin order, you'll get blackface.  I set up my replacer mods in such a way that if my patches for a couple of them weren't loading exactly where I placed them in my load order, blackface was inevitable.  And guess what?  No blackface.  The patches I tested are definitively, positively, absolutatively loading exactly where I placed them in my plugin order.

Q:  Wait - I checked out that Fallout 4 mod and in his sticky post where he talks about this, he says "The downside is just keeping track of them, because mod managers aren't updated to detect this workaround yet."  Is that still a problem?

A:  Not with Mod Organizer 2.  That post is from Dec 2017, and things have changed.  I chatted with Silarn on the MO2 Discord channel and he confirms that all versions of MO2 since v2.1.2 should handle ESP's flagged as ESL's properly.  And they work great - if you use these patches with MO2, you even get a little helpful yellow dot next to the patch in your plugin order that, when hovered over, says:  "This ESP is flagged as an ESL.  It will adhere to the ESP load order but it will be loaded in ESL space."  Which is awesome.

Q:  So these ESP's are sort of an ESP, and sort of an ESL?  What should we call these things?

A:  Zeridian calls them ESP LITE, but that seems bulky to me.  I prefer "ESPFE", because they are otherwise normal ESP's that just load into the FE space where ESLs are loaded.

Q:  Do they work with Creation Club mods, or other ESLs?
 
A:  I HAVE NOT TESTED THESE WITH CREATION CLUB MODS.  I strongly recommend not trying this with CC content at least until non-CC users have verified it works for them for a while.  I have tested these patches alongside true ESL's I converted myself, and they work fine in conjunction.  All true ESL's are shoved up to just below the ESM's as you'd expect, and occupy FE00, FE01, FE02 as you'd expect, ordered as ESL's were always ordered, and then the patches are ordererd FE03, FE04, FE05 in the order they exist in your plugin order.

Q:  What about NMM?

A:  Versions 0.65.2 and previous are confirmed to not work (when you add one of these patches, or any ESL for that matter, it will lock the entire load list).  It is possible that newer unofficial versions, which are available here, MAY work (the description of version 0.65.3 says it fixes that issue).   If you're an NMM user and feeling brave, you could give the newest versions a try - and if you do, PLEASE report back, but no promises that you won't have issues with it.  Definitely use at your own risk.

Q:  What about SSEEdit?

A:  ESPFEs will be loaded in the correct order, however, there is still an absolute limit of total 255 plugins that can be loaded by the tool, whether they be ESP, ESL or ESPFE.  If your total load order has more than 255 plugins, of ANY kind, you'll need to uncheck enough of them when starting SSEEdit to get the total count to below 255 in order to work with the remainder in SSEEdit.  The XEdit dev team has stated that they have no plans to increase that limit in the near future.

Q:  Wrye Bash?  Mator Smash?

A:  These tools remain absolutely essential for things like leveled lists.  Zeridian reports that Mator has stated that he's working on ESL support.  Wrye supports ESLs, but won't let you easily identify ESPFEs yet.   

Q:  Who do we have to thank for being able to use this?

A:  Fallout 4 fans appear to have discovered this and asked the MO2 team for support, and they got it.  Much gratitude to the FO4 fans AND the MO2 development team (particularly Silarn), because now we MO2 SSE players can use and enjoy it!  Thanks to Zeridian for making me aware.  

Q:  Can these ESPFE patches be merged with Merge Plugins?

A:  Yes.  But why would you normally need to?  The point is that this frees you up to place the patches exactly where you want them without impacting your total plugin limit, and the place I always recommend is immediately after the second mod that you are patching in your plugin order.  That's the only place that the typical patch can be guaranteed to work as intended.  The short explanation is:  If Mod A needs to come before Mod B in your load order, then all patches involving Mod A in any way have to come before Mod B as well.  So unless you're pretty skillful and going over everything in SSEEdit yourself to make sure ALL conflicts are accounted for, doing a Merge Plugins that moves all your patch records to the very bottom of your load order can have unpredictable results.  With these ESPFE patches, placing all patches at the bottom is no longer optimal.

Q:  Why is it not optimal to put patches at the bottom of the load order?  They *have* to go at the bottom if I'm merging them.  And I've always been told that patches should go at the bottom of the load order anyway.

A:  I'll explain why it's almost always a bad idea to put any patch any lower in the plugin order than absolutely required in a moment.  Those who advised this were probably primarily motivated to evade the 255 plugin limit and that it was worth the potential instability price (if they were aware of this issue at all, and it often was worth it, until now).  As for Merge Plugins, it's an excellent tool for circumventing the 255 plugin limit IF you know what you're doing and are deeply aware of every conflict in your load order and can compensate, but if it's NOT needed (and with these patches, the limit becomes much less of a problem), or you're NOT willing to really analyze your load order completely, then it is simply bad practice to use it *because* it requires moving patches lower in the load order than they need to be.  

Here's a simple example. Say you're using CRF, The Ordinary Women, and Bijin.  You set up your load order properly like this:

Cutting Room Floor.esp
TheOrdinaryWomen.esp
Bijin AIO.esp

Because your install order of these mods is the same (though that's not relevant right now), everything works fine.  Bijin overrides for the NPCs that Bijin changes, and TOW works on whoever's left over.  Then you add my TOW-CRF patch to the mix where I advise to put it.

Cutting Room Floor.esp
TheOrdinaryWomen.esp
Qw_TheOrdinaryWomen_CRF.esp
Bijin AIO.esp

Everything still works fine.  The patch gets to patch records that Bijin doesn't overwrite, and the ones that Bijin does overwrite, the patch is overwritten as well.

But now someone tells you to merge your patches!  So you do.  And that merged patch of course goes at the bottom.

Cutting Room Floor.esp
TheOrdinaryWomen.esp
Bijin AIO.esp
MergedPatch.esp (containing Qw_TheOrdinaryWomen_CRF.esp)

Now characters that Bijin overwrites have Bijin's meshes and textures, but TOW's ESP for the patched records.

Blackface.

To the response "Well, just don't merge NPC replacer patches", the principle holds for almost any mod combination that requires a specific load order to function, it's just most obvious with replacer mods.  If any Mod A *has* to come before Mod B for them to work correctly, any patches involving mod A (in any way!) *must also* come before Mod B.  I can illustrate a similar situation with Relighting Skyrim and ELE.  RS has to come before ELE for them to be compatible.  If you load RS after ELE, ELE will be almost completely wiped out.  If you load RS and then ELE, but add a patch for RS and some third mod and load it after ELE, you are wiping out ELE's changes to whatever interior cell records are in that RS patch.

So the point is, if you don't have to use Merge Plugins to stay within your 255 limit, and that's what this patching method is all about doing, then don't.  Always put your patches immediately after the second mod being patched.  Always.  In that spot, a patch can never hurt you unless it's bugged.  Anywhere else you place a patch for Mod A and some unrelated mod C, you take a chance of moving a small piece of that mod A after some other mod B, when the load order of Mod A THEN Mod B is critical for them to function together properly.  And in some cases, moving only a small piece of mod A after B can be worse than moving all of mod A after B.

And that's why evading the 255 limit as this patching method does, without having to merge and move patches far lower than both their base mods, is a fundamental game changer.

Q:  Should I use ESPFE's for anything other than a compatibility patch?

A:  NO.  ESPFE's have not been tested with mods that add new content (meaning, new FormIDs via their ESP) to the game, and that's because there's reason to believe it's risky and dangerous.  A quirk of ESL's and ESPFEs is that they can sometimes need to have their FormID's compacted, which can be tricky and can create issues if it's done in an ongoing game.  BUT.  An *exception* to this is if the FormID that you're using has already been loaded in your load order (either because it's a vanilla record or added by a previously loaded mod).  Those do NOT need to be compacted... and since generally every record in a PATCH is going to be modifying an existing record (because that's what patches do), it actually makes this method perfect for compatibility patches, and not much else. The way these records are ordered in a save game header file also does not appear to have a negative impact IF all the records were already previously loaded in the load order.  Again, this makes it fine for compatibility patches, but risky and dangerous for anything that actually adds new records into the game.  Leave anything that does that as a normal ESP.  This still solves the problem of freeing up where you can place your compatibility patches in the load order, and still does pretty much blow the 255 limit pretty much wide open (cause if you're patching that many mods properly, those compatibility patches are taking up a WHOLE lot of that limit.)

Q:  Are there any restrictions on how many of these ESPFEs you can use?

A:  SSE can theoretically handle up to 4096 mods in FE space (be they ESL or ESPFE), but there's also a restriction on how many total FormIDs they collectively alter.  A single ESL/ESPFE can only modify 2048 FormIDs, and if every single ESL/ESPFE you use has the maximum 2048 FormID's, this brings the total number of mods you can load in FE space down to 300.  Which is still a hell of a lot, and the vast majority of mods in ESL space aren't going to have that many FormIDs.  The biggest patch on this page modifies less than 20 FormID's, so I think the term "featherweight" is appropriate.  

Q:  Are you SURE I shouldn't merge some patches still?  Like, what if Immersive Citizens is near the end of my load order, and I have five of your ESPFE patches that need to come right after it.  Wouldn't that save me 4 of these FE slots?

A:  The saving is *seriously* trivial.  Let's do the math.  We know that the maximum number of FormID's is roughly 300 x 2048 = 614,400.  Divide that by the maximum number of FE slots (4096), and you can have an average of 150 formids per patch and still get use of the full 4096 slots.  The biggest patch in this compendium so far has about 20 formids.  Several have 3 or less.  I'm figuring it's going to be at LEAST a week before some crazed modder manages to increase their total plugin count from 255 to 4,351 (and the last 4096 being compatibility patches for the first 255).  Maybe even two weeks!  Let's worry about it then.  In the meantime, you couldn't run out of FE slots if you tried, unless you completely ignore me and start making your huge new content mods into ESPFE's, in which case you deserve your tears and it's all on you.  Oh, and if you do merge those Immersive Citizens patches, and then one of them gets updated, you gotta redo the whole merge process involving other patches that don't really need updating, increasing chances of human error, etc. etc., instead of just replacing that single patch, click and done.  Just.  Not.  Worth.  It.

Q:  I have an ESP in my load order that is empty, just there to load a BSA.  Can I apply this method to it?

A:  I believe that should be fine too, but I have not tested it myself.  If you want to try it, you can just open up that empty ESP in SSEEdit, click on its File Header, right click on Record Flags, and check "ESL".

Q:  If something goes wrong, can I blame you?

A:  Well, you can, but this hasn't seen widespread use in SSE yet, and should still be considered Proof of Concept.  But those brave and adventurous souls who are willing to try it out and hopefully confirm it's working for them as well as it does for me can be part in this grand experiment that, if successful, and if it gained widespread acceptance, would effectively go a long long way toward removing the 255 plugin limit and thus radically improve the way we can do our modding for SSE.