Load Order and You

Introduction

Load ordering is the method used to determine how conflicts between mod plugins (.esp, .esm files) should be decided. If two plugins alter the same game data, then the changes made by the plugin loading later will override those made by the plugin loading earlier. This "rule of one" results in a list of plugins, with those earlier in the list having any conflicting changes overriden by those later in the list. This list is the load order of the plugins.

A game will only load the plugins that are active. Up to 255 plugins, including the game's .esm file, can be active at any one time. Active plugins are listed in the game's "plugins.txt" file, which is stored in the user's local application data folder. Nevertheless, it is useful when working with load orders to consider the load order of all plugins, even if only some of them will actually be loaded. This is both because it is easier to display a single list of plugins than a list and an unordered set, and because modders have engineered methods that allow the changes made by inactive plugins to be loaded by another plugin (eg. Wrye Bash's Bashed Patch). When any such methods are being used, the load order of inactive plugins decides which plugins override others, similar to as if they were active.

In Oblivion, Nehrim, Fallout 3, Fallout: New Vegas and early versions (pre-1.4.26) of Skyrim, load order is decided by the relative timestamps of plugins in the game's Data directory. An installed plugin's load order is therefore an intrinsic property of that plugin.

In Skyrim v1.4.26, a new text-based load order system was introduced, in which load order is decide by the order in which plugins are listed in "plugins.txt". This brought with it a fundamental change, in that load order is no longer an intrinsic property of a plugin. This has the result that inactive plugins do not have any load order.


The Solution

The solution agreed on by Lojack (Wrye Bash), Kaburke (Nexus Mod Manager), WrinklyNinja (BOSS) and Dark0ne (owner of the Nexus sites) was that total load order would be stored in a "loadorder.txt" file, itself stored in the same location as "plugins.txt". "plugins.txt" would be kept in synchronisation with "loadorder.txt" so that the order of plugins that the game loaded was the same for both files, but the latter would allow the load ordering of inactive plugins.

Modding utilities would then perform their changes on "loadorder.txt", updating "plugins.txt" to reflect any changes to active plugin load order as required. This provides a common store for the total load order in lieu of the plugin timestamps used by the other games.


What This Means For... Mod Makers & Users

The bad news: Any utilities that you use to manage load order may stop having any effect. This is because nothing currently released knows about the change in load order system. In time, utilities may be updated to handle the text-based system as their programmers become aware of it. Until then, Skyrim's launcher is the only way to change load order. Also be aware of the current limitations of the solution, given above.

One very important thing is that if you have a utility that can handle the text-based system, do not use Skyrim's launcher to set load order. This is because it doesn't know about the total load order, so if you change the load order through it, only the active load order changes and synchronisation between the two is lost. The only way for a utility to re-sync the two load orders is to undo the changes you made in the launcher.

The good news: Nothing changes when it comes to making or using mods, it's just business as usual. Just bear in mind the point about the utilities you use to manage load order needing updating, and have patience while the programmers do their thing.


What This Means For... Mod Utility Programmers

The bad news: Your utilities will no longer function when it comes to load order (both getting and setting) until you update them to support the current system.

The good news: I've already done a lot of the work for you. The BOSS API supports both the timestamp-based and text-based load order systems through the same interface, so you don't need to worry about the differences, and includes all the functions required for querying and changing load order and activation status. The BOSS API will be included in the v2.0 release of BOSS, but if you PM me I'll send you a copy if v2.0 hasn't been released yet.

Note that the BOSS API is licensed under the GNU GPL v3.0 license, so your utility's license will have to comply with that to use the API. If it doesn't or you don't know if it does, it's still worth contacting me, as I may be able to help you through the legal quagmire, and I'll still give information on the load order solution to anyone who needs to implement their own interface with it.


Utility Compatibility List

All known modding utilities that make use of load order in their functionality are listed below, with their compatibility status with regards to the text-based load order system. The three possible states are:

Compatible: The latest release of the utility is fully compatible with both the text-based load order system and the timestamp-based load order system.
Compatibility In Progress: The utility author(s) is (are) working on adding compatibility for the text-based load order system, but the latest release is not yet compatible.
Incompatible: The utility is not compatible with the text-based load order system and the author(s) has (have) either stated that they will not be adding compatibility, or are not known to have made any statement on whether they're working on compatibility or not.

(I've also made a note of what isn't using the API, for my own benefit so I don't forget who to send updates to.)

BOSS - Compatibility In Progress
Wrye Bash - Compatibility In Progress
Mod Organizer - Compatibility In Progress (Not using BOSS API)
Nexus Mod Manager - Compatibility In Progress
Oscape - Compatibility In Progress (Not using BOSS API)
TesModManager - Compatibility In Progress


Final Notes

Please remember to have patience if you're waiting on someone to do something in relation to this issue, eg. users waiting on programmers, or programmers waiting on me to fix an API bug (though I couldn't find any). Everyone who can do anything about this situation is pretty busy, and these things take time to get done right.

Also please don't hate on Bethesda for changing the system. It's better than the old one, and the issues that it brought up are because we're too smart for our own good, coming up with ways to bend the rules (eg. Bashed Patches), so it's wrong to think that Bethesda need to cater for the situations in which they arise.

It's probably a good idea if people post below any utilities that use load order in some way that aren't listed above, so that I can add them to the compatibility list.

Finally, spread the word. If someone's having trouble setting the load order, let them know that it might be to do with this. If you know of a modding utility not listed above that changes or uses load order in any way, let the author(s) know about this. Please be polite while doing so though, I don't want to end up reading verbal abuse resulting from this instruction. When letting utility authors know, don't demand they update their utility, just post a note saying that it doesn't work any more and link to this thread.

Related links:
http://www.gameskyrim.com/topic/1353517-important-load-order-and-you/
http://forums.nexusmods.com/index.php?/topic/583662-important-load-order-and-you/
http://forums.nexusmods.com/index.php?showtopic=583688

I suggest "explicit ordering" for the name.

Blargh, I cant think of anything constructive to say other than good luck you guys getting the tools working with this new system. At least they did this relatively early on instead of like half a year from now with their first major DLC(just a guess).

Is this new implementation to do with the whole BSA plugin load ordering shenanegans?

It's primarily because they finally built a Data Files window with load order option. And because they already built the "check for updates" system around file-date they needed a different way to manage load order.

No, that's a separate set of issues. This is just dealing with plugin load order.

Though Bethesda have apparently changed the BSA system so that plugin-loaded BSAs are loaded in the order that their plugins are loaded, and are overriden by loose files. That's what GStaff told me, at any rate. I don't think anyone's actually looked at the BSA stuff again since then to see if things work as advertised, though I notified Lojack.

Thanks for the information wrinklyninja, and for all the work you and everyone else is doing to improve our ability to manage mods.

The next patch is not officially released yet and you had this issue almost fixed . Thanks for your effort and keep the good work

That would jive with the findings Kivan and I have, as well as one other guy who's name I can't remember right now. It means that when the 1.4.27 patch goes final I can put my alt-start mod up on the Workshop and expect it to work properly.

Hi! Sorry but I don't get it: this means that from next patch the BSAs will always be loaded after loose files without being included in skyrim.ini?

The opposite, apparently. Loose files will be applied instead of files in BSAs wherever they exist. Though at this stage it's probably best to treat it as hearsay. I defer to Lojack on this subject.

I dont know if it affects Surazal, or which of his utils would be affected .. But I just sent him a PM linking to this topic.

Edit: Has anyone seen Mooo recently ?, pretty sure he had something in the works too (although it was an Oblivion project which could possibly develop into a Skyrim utility).

I hadn't thought of anything of Surazal's. BUM will likely be affected, BAT I'm not so sure.

The only other utility that sprung to mind when I was writing was TES5Edit (though it's not been released yet). Unfortunately, its previous incarnations have been closed-source (IIRC there's code Elminster can't legally release involved), so if the same is true for TES5Edit then it wouldn't be able to use the BOSS API, though I'm still around if he wanted to interrogate me for info.

You can edit your load order in TES4Edit?

I only partially understand the need for the new file. Seems like that will end up being a headache as well since its not explicitly supported. Why not use timestamps to control ordering for inactive plugins and defer to the plugin.txt for primary load ordering? If I ended up using SteamWorkshop for anything does that not automatically change the plugin.txt and not the loadorder.txt file and thus causing an conflict?

I realize there are issues with that as well but you could use the timestamp as a hint of where inactive plugins should be when displaying it in a list.

I haven't seen the development of TES5Edit yet, but if its anything like TES4Edit then load order is very important to that utility (if you ever at least clean any mods you will realise why - screeny http://www.bild.me/bild.php?file=8196152Untitled.png )

I know that Load Order is important to it, but it doesn't manipulate the LO, it just reads it, right?

Well, Nehrim as well, but that's because Nehrim is Oblivion.

Anyway, hoping that this end well.

Oh yes, just reads it

Thanks, wn for all your hard work.

I'll second this one. Sums up in 2 words what the new system does and it's pretty plain english.

And... Thank you, all of you, who make these utilities. you make mod users (and creators to an extent) lives much easier.

I haven't had a chance to test this out yet (keyboard's FUBAR, using the on-screen one), but once I do, I'll post up a new "BSAs and You" thread with the updated information. Mostly I think it'll just be to let people know what order stuff loads in now, but it sounds like the problems are fixed.

As for TES5Edit, when it comes out, YES, it will have to be aware of the new ordering scheme, since Load Order is important to it as well, even if it's reading it. That means it'll need to read plugins.txt correctly (read: Load Order = the order they're listed in plugins.txt now).

As others have said, even utilities that only read the load order will need to be updated.

Timestamps aren't an option because:

1. They cause Steam Workshop to redownload mods you're subscribed to if you change them. Big deal, some might say, but see point 2.

2. They aren't an indication of active load order. You could use timestamps for setting the load order of inactive plugins, ignoring the first point, but then you'd have two totally unrelated load orders: one for inactive and the other for active plugins. Our requirements are such that we need to be able to position inactive plugins precisely amongst active plugins, and you can't do that with two unrelated load orders.

As for using Steam Workshop being an issue, the sync between plugins.txt and loadorder.txt is only an issue if you're using a modding utility other than what Bethesda provides in conjunction with the launcher to manage load order. If you're only using the launcher/SW then there will be no loadorder.txt and there's no issue: the two will use plugins.txt to set active load order and don't care about inactive plugins. If you're using only modding utilities (that are compatible), then plugins.txt and loadorder.txt will always be in sync. It's only if you mix the two that problems may arise.

I'm unfamiliar with the subscription process, but when mixing SW with modding utilities, even if it does reset load order when you subscribe to something, that doesn't matter, as the next (compatible) modding utility you open will have the ability to reset the correct load order from loadorder.txt (actual behaviour is decided by clients, not the API). There's a difference to subscribing to a mod and managing your load order: subscribing may introduce changes to load order you don't want, in which case this method provides a fallback, whereas managing load order is about making changes to your load order you want to keep. I'm saying you shouldn't do the latter through the launcher.

Hopefully that was clear enough. It can get complicated, and this particular issue gave me a headache or two when I was trying to work out the optimal behaviour.

Hi wrinklyninja

As always, many thanks for keeping everyone informed.

BAT doesn't do anything with load order so it is unaffected by this change.

As far as I can make out, BUM should also be unaffected, because it only deals with Userlist rules. So, providing that BOSS will still handle Userlist rules, BUM should be fine. BUM does not distinguish between Active and Inactive mods in terms of Userlist rule generation, but I am assuming that the changes you are making to BOSS will take care of it.

Finally, I am working on the next version of BUM, which focusses on a cleaner UI, performance and accommodating the various installation preferences that BOSS v2.0 will offer. So if there is anything you think I have misunderstood, it would be really good to know.

Thanks a lot for the info wrinklyninja!

It might also worth it to note that one should perhaps wait until at least BOSS 2.0 is released before updating to the next non-beta patch.

As for names for the new load order system here are a few:

Appdata-Based

plugins(.txt)-based

Load Order: The .txt chronicles