Support for "The Elder Scrolls III: Morrowind"

[pStyl3]

Support for Morrowind has been requested a number of times, so let's discuss it here.

Since Morrowind does handle load order different than Oblivion, Skyrim, et cetera, support would entail to adapt LOOT's sorting algorithm for Morrowind.

We also need to build up a masterlist for Morrowind, that also get's maintained in the long run.
Help for this task would be greatly appreciated.

It has been suggested to take the masterlist of mlox as a starting point.
https://github.com/mlox/mlox/blob/master/License.txt

Is the above feasible and sensible in our case?
How accurate and up to date is the mlox masterlist?

We also would need some people testing the newly added support for Morrowind, once it is done.

[Ortham]

Off the top of my head, the code changes necessary to support Morrowind would be:

• esplugin supports Morrowind, but doesn't handle overlapping records correctly, as Morrowind plugins don't use FormIDs, so that would need changing
• libloot and LOOT would need new a new Morrowind game type and corresponding default config added
• loot-condition-interpreter would need a new Morrowind game type, though using the Skyrim or earlier game type would be fine.
• libloot and LOOT hardcode the directory that plugins are found in as "Data", this will need to be different for Morrowind (a minor change)
• libloot's API uses "FormID" in method names dealing with overlap, which would be inaccurate for Morrowind (they could be renamed to use "Record" instead, or equivalent methods using that term added)

I think everything else should be sufficiently generic, and libloadorder already supports Morrowind.

Questions:

• Does Morrowind have BSAs or equivalent resource archives? UESP says yes, the have the .bsa file extension.
  • How are BSAs loaded? E.g. in Oblivion they are loaded if their filename starts with the basename of an active plugin.
• Does Morrowind add a Registry entry that contains the path it's installed at, and if yes, what entry is it?
• How are conflicts resolved in Morrowind? E.g. in later games two records conflict if they have the same FormID, and generally the plugin that loads last has its version of the record applied. There are a few exceptions (e.g. cell records have more granular conflict resolution) but LOOT ignores that, and just cares about if any records with the same FormID exist.
  • Morrowind doesn't have FormIDs, it looks like there's an ID subrecord that is used for this purpose instead - it's often the NAME subrecord, but it varies by record type.

[NullCascade]

You may be interested in mlox, which has custom rules for what should be loaded before/after other mods, and other assorted warnings. This data could be scraped and incorporated into LOOT rules (though they haven't been updated in the past year or two).

Morrowind tool developers (like Hrnchamd, G7, and myself) tend to hang out in the Morrowind Modding Community Discord. If you have any questions specific to Morrowind's loading mechanisms shoot us a message.

[NullCascade]

Does Morrowind have BSAs or equivalent resource archives? IIRC the answer is no.

Morrowind does make use of BSAs. They are fetched from Morrowind.ini in the install directory, under [Archives]. E.g.:

[Archives]
Archive 0=Tribunal.bsa
Archive 1=Bloodmoon.bsa

Does Morrowind add a Registry entry that contains the path it's installed at, and if yes, what entry is it?

Nothing terribly consistent. Usually applications have to be installed in the Morrowind directory itself. The game is portable and doesn't require a defined directory in the registry.

How are conflicts resolved in Morrowind? E.g. in later games two records conflict if they have the same FormID, and generally the plugin that loads last has its version of the record applied. There are a few exceptions (e.g. cell records have more granular conflict resolution) but LOOT ignores that, and just cares about if any records with the same FormID exist.

Same as later games, late loaders win out (with exceptions like cells). However there are no FormIDs, everything is identified by a unique string, up to 32 bytes long.

[Ortham]

OK, I've worked out most of the parsing of record IDs (the FormID-equivalent data). I've come across a few more questions:

• Is there anywhere that comprehensively lays out which record types belong in which namespaces? I was wondering if there was any namespacing, then I saw Elminster said there is for some record types.
• Does anyone know what LAND records use as their ID?

I've also realised that esplugin's Plugin::count_override_records() won't work for Morrowind plugins because you can't tell what records are from another plugin without comparing a plugin against its masters... As things are this means that LOOT won't add any overlap edges between any Morrowind plugins. I'm not sure if that part of the sorting algorithm is suitable for Morrowind anyway though, so it's probably worth checking what good rules of thumb for manual loading exist first.

[pStyl3]

As a reference point, here are some popular Morrowind mods:

Accurate Attack
Better Clothes
Better Heads
Better Morrowind Armor
Morrowind Comes Alive
Patch for Purists
Province Cyrodiil
Real Signposts
Skyrim Home Of The Nords
Tamriel Rebuilt

The above mods have the following plugins:

Accurate Attack.esp

Better Clothes_v1.1.esp
Better Clothes_v1.1_nac.esp

Better Heads Bloodmoon addon.esm
Better Heads Tribunal addon.esm
Better Heads.esm

LeFemmArmor.esp
Snow Prince Armor Redux.ESP
Better Morrowind Armor DeFemm(a).ESP
Better Morrowind Armor DeFemm(o).ESP
Better Morrowind Armor DeFemm(r).ESP
Better Morrowind Armor.esp

MCA.esm

Patch for Purists - Base Patch.esm
Patch for Purists - Book Typos.esm
Patch for Purists - Dialogue Inconsistencies.esm
Patch for Purists - Dialogue Typos.esm
Patch for Purists - Expansion Implementation.esm
Patch for Purists - Floating Rocks.esm
Patch for Purists - Statistic Typos.esm

Cyrodiil_Grass.ESP
Cyrodiil_Main.esm

RealSignposts.esp

Sky_Main.esm
Sky_Main_Grass.esp

TR_Factions.esp
TR_Mainland.esm
TR_Preview.esp
TR_Travels.esp
TR_OldTravels.esp
TR_Travels_(Preview_and_Mainland).esp

There is also this guide that is apparently being worked on actively:
Morrowind 2019: Thastus Edition

[pStyl3]

@jhaakma @Greatness7 @Hrnchamd - You three have been named to be very knowledgeable regarding Morrowind. Would anyone of you be able to answer Ortham's questions?

[NullCascade]

Is there anywhere that comprehensively lays out which record types belong in which namespaces? I was wondering if there was any namespacing, then I saw Elminster said there is for some record types.

There's not really a lot of namespacing. You should never have two objects of different types with the same ID. Internally the game uses a hashmap of all objects by their ID, and there can be collisions there that can be unexpected. That said, the following are split out in different places in memory: races, class, birthsigns, scripts, cells, factions, sounds, globals, regions, then everything else is clumped together in the main object map.

Does anyone know what LAND records use as their ID?

LAND records do not have IDs. They are loaded on demand for cells and stored off of that in memory. There's no master list of land objects. Instead you get the CELL for a grid x/y then get the LAND off of it. The vtable for LAND records will return an empty string if you try to get their object ID. Since interiors can't have LAND records associated with them, you can fake your own ID using grid coordinates if necessary.

There is also this guide that is apparently being worked on actively:
Morrowind 2019: Thastus Edition

The Morrowind Graphics Guide is also popular and currently maintained.

[Ortham]

As noted on Discord, I've started work on the code changes necessary for Morrowind support in the morrowind-support branches, and there are now snapshot builds available on Bintray. Everything should work, except:

• An INFO record is not uniquely identifiable on its own, as they're related to the DIAL record that precedes them. esplugin can't currently handle this, so can falsely identify an overlap between two plugins if one adds an INFO record under one DIAL and another adds an identical INFO under another DIAL. This would mean LOOT's sorting might add overlap edges inappropriately and lead to wonky load orders, but...
• It's impossible to identify which of a plugin's records are overrides by only using the contents of the plugin, so esplugin can't count how many overrides a plugin contains, and so LOOT won't add any overlap edges between plugins.

There might also be bugs in how I'm reading/calculating IDs to uniquely identify records, but again, these won't be visible because they're only used to add overlap edges.

I've also created an empty masterlist for Morrowind. Like our newer masterlists, it's licensed under CC0. If anyone is going to convert metadata from mlox, bear in mind that's MIT-licensed, so it might be better to relicense under MIT and just include the mlox copyright notice in the license. Otherwise we'd need to include the mlox license in the masterlist repo, which might be a bit confusing.

[pStyl3]

From this point onwards it is important to get feedback from the community.

Before going to the step of potentially converting mlox's masterlist for our purposes, I think it would be best to actually see LOOT in action by it's own, on fully modded Morrowind games. That should be the best way to see what LOOT can do in regards to load order, or, not yet can - and if there are any bigger issues to begin with. @CptMcSplody has already implemented the official DLCs into the masterlist and opened an issue for adding Bethesda's official mods to it.

Anyone who wants to help us by testing LOOT with Morrowind, please follow these steps:

• Backup your load order
• Go to Bintray and download the latest LOOT snapshot build from the morrowind-support branch. For example, as of writing this post the latest build would be loot_0.14.3-18-ga4d9321_morrowind-support.7z. The higher the number after loot_0.14.3-, the newer the build.
• You also need to install the MSVC 2017 x86 redistributable, if you haven't already.
• After installing that snapshot, enable Debug Logging within LOOT's settings.
• In the game selection drop down menu, select TES III: Morrowind, if it isn't already selected.
• Sort your load order (and accept it).
• In LOOT's main menu, select Open Debug Log Location.
• Provide us with your LOOTDebugLog.txt from that folder. It contains the load order that LOOT calculated and many other information.
• Also provide us with the exact name of the snapshot that you've used to create that Debug Log. Quite possibly there will be multiple different snapshots in the morrowind branch, so it is important to be able to differentiate between the results of potential different snapshots.
• If you spot any mistakes, tell us which and why you think so. If there are any sources for why A should load after B, we would like to see those, if possible.

Please do not forget, at this point support for MW is a first (adapted sorting algorithm, newly created masterlist), so issues are to be expected. We would like to get as much feedback as possibe, so that we can improve overall using those information.

[Bluttier]

I can't seem to get LOOT to detect my Morrowind installation. I'd be happy to provide more information if I had it. Let me know if there's anything I can do.

[Ortham]

• Also provide us with the exact name of the snapshot that you've used to create that Debug Log. Quite possibly there will be multiple different snapshots in the morrowind branch, so it is important to be able to differentiate between the results of potential different snapshots.

The debug log includes that info, so it doesn't need to be provided separately.

I can't seem to get LOOT to detect my Morrowind installation. I'd be happy to provide more information if I had it. Let me know if there's anything I can do.

What version of Morrowind are you running (e.g. Steam, GOG, disk)? I've got the GOG version and set LOOT to use the registry entry that's added by its launcher.

[abitoftaste]

LOOTDebugLog.7z

notes: I don't think it is a good idea/it makes sense to process mods not currently loaded, as morrowind mod makers/advanced users are going to have plenty of test/unused/kept as reference mods in the same Data Files folder and a loading order is traditionally meant to only include LOADED mods (the ones listed under [Game Files] section in Morrowind.ini and , as it is, the Loot generated loading order is not easy to compare to loading order generated from standard Morrowind tools (Mash/MLOX) as it has also all unused/not loaded mods listed.

e.g.
169 a9 The Tribe Unmourned.esp
Solstheim_mage_tower SO.esp
170 aa Solstheim_mage_tower+No-mans Wharf SO.esp

for Morrowind it would be better to have a way to copy a list with:

• all entries not having hex prefix (not loaded) skipped
• loaded entries without hex prefix but with a numeric order prefix e.g. 001 instead (this way it would be much easier to compare to MLOX/Mash loading order lists)

[EDIT]ok, so I managed to strip redundant information from LOOT loading order and to compare it with my original loading order from Mash, nothing was changed in the effective relative plugin ordering (that's good, did not mess with my loading order!), but the file timestamps have all been changed.

I think ideally this should not happen if no changes to effective loading order are needed, as user may have plugin dates sorted by personal criteria (e.g. quest mods grouped in 2007 year) so better not mess with them if not needed for reordering

[MacSplody]

There's a copy load order option in the top right menu.

  0  0     Morrowind.esm
  1  1     Tribunal.esm
  2  2     Bloodmoon.esm
           Patch for Purists - Dialogue Typos.esm
           Patch for Purists - Floating Rocks.esm
           Patch for Purists - Base Patch.esm
           Patch for Purists - Book Typos.esm
           Patch for Purists - Expansion Implementation.esm
           Patch for Purists - Dialogue Inconsistencies.esm
           Patch for Purists - Statistic Typos.esm
  3  3     XE Sky Variations.esp

[Ortham]

LOOTDebugLog.7z

Note that you can usually upload the log files directly into comments here, though maybe that log file is too big. Most of what I got from that was that LOOT is doing a lot of checking if plugins are active and getting the load order! They're both pretty fast operations, but I should cut down on them or maybe not log them...

Good to see that loading plugins was fast (~2s for 459). Sorting is as slow as I'd expect for that number of plugins (~19s), as it scales terribly.

notes: I don't think it is a good idea/it makes sense to process mods not currently loaded, as morrowind mod makers/advanced users are going to have plenty of test/unused/kept as reference mods in the same Data Files folder and a loading order is traditionally meant to only include LOADED mods

The situation doesn't seem to be any different from the other games that LOOT supports, and I don't recall any complaints about LOOT sorting / showing inactive plugins. It's a feature, because the load order of inactive plugins has implications when building Bashed / merged patches. I don't know if this is different for Morrowind.

I think ideally this should not happen if no changes to effective loading order are needed, as user may have plugin dates sorted by personal criteria (e.g. quest mods grouped in 2007 year) so better not mess with them if not needed for reordering

LOOT detects if the sorted load order is unchanged and doesn't offer to apply it if so. That hasn't happened, I guess it reordered some inactive plugins that you stripped them out for your comparison.

More generally, if you're auto-sorting with LOOT, I think it's reasonable to consider that as waiving your ability to maintain your own choice of timestamps. Though libloadorder does reuse existing timestamp values when setting the load order, if you want stuff like "quest mods grouped in 2007" , just don't use LOOT.

[abitoftaste]

It's a feature, because the load order of inactive plugins has implications when building Bashed
merged patches

we don't have bashed patches in Mash, only merged leveled lists so for Morrowind it is definitely annoyance, not feature

I guess it reordered some inactive plugins that you stripped them out for your comparison.

probably, and that's another thing that does not make sense for Morrowind, they may be there in 2020 as easily grouped "only for reference"

if you want stuff like "quest mods grouped in 2007" , just don't use LOOT.

right, I think I will happily keep using MLOX and TESPCD then

[EDIT]quoting

[abitoftaste]

There's a copy load order option in the top right menu.

Is this for me? I know thanks, that's what I used

[MacSplody]

There's a copy load order option in the top right menu.

Is this for me? I know thanks, that's what I used

Yeah I realized that after, misread your post the first time.

[Bluttier]

I managed to get it to work, don't ask me how I'm apparently crazy.

Here's the debug log
LOOTDebugLog.txt

[Tyler799]

Seems to work to me, though I can't immediately comment on load-order correctness. Here's the log:

LOOTDebugLog.txt

[abitoftaste]

Seems to work to me, though I can't immediately comment on load-order correctness. Here's the log:

LOOTDebugLog.txt

What do you mean by "work", that it does not crash/is finding files? Wow, call me impressed.
from what I can understand from that log (the one important thing about a mod load ordering tool log should be clearly display before (original) and after (sorted) loading order, like MLOX does) is that the before running LOOT and after running LOOT mod loading order are the same, with (maybe, I'm not sure I understand correctly the last log part) the very bad exception of placing multipatch.esp on top? or is the mod on top of various sorting steps just current examined mod?

Anyway, it does NOTHING except maybe a BAD thing if it's moving multipatch.esp on top

From what I see, it needs a rules database like MLOX and even more than MLOX.
MLOX rules are already easy to understand and write, still nobody is getting the hassle to update them after Dragon32 who managed them for years practically alone, I doubt a new fancy format for rules will find new competent rules managers easily.

People are just a lazy bunch jumping on the latest and greatest tool (hey, it's new, must be better) hoping to magically solve problems clicking a button, but it's not always like this.

[Tyler799]

Jesus, ABOT, what is your deal? Why are you being so hostile? Why do you constantly make assumptions without knowing what you're talking about? Why do you hate absolutely anything new? Why are you like this in every channel I find you on?

The masterlist for LOOT is currently completely empty - IE it doesn't have any rules yet. Because the project just started.

The point was that they wanted to make sure it was detecting the plugins and was able to run fine without any issues. That's it.

Also it didn't place multipatch on top. :/

If you want to see what the rules look like for LOOT, you can see Skyrim SE's one here: https://github.com/loot/skyrimse/blob/v0.14/masterlist.yaml

That might clear it up a bit.

People are just a lazy bunch jumping on the latest and greatest tool (hey, it's new, must be better) hoping to magically solve problems clicking a button, but it's not always like this.

Of course, because re-writing portions of LOOT to work with Morrowind and making a masterlist from scratch is "lazy".

It was suggested because Mlox's current masterlist is seriously out-of-date, and the MLOX project seems pretty dead. It was a great tool and I respect the work that was put into it, but it just isn't enough anymore.

The hope was that with enough advertisement and a new project, we could garner some support and make it something great. Plus LOOT offers functionality that Mlox doesn't, like groups.

If you end up wanting to contribute, Morrowind's masterlist is here: https://github.com/loot/morrowind/blob/v0.14/masterlist.yaml

[pStyl3]

There is no need for such strong emotions @abitoftaste. We are at the beginning of supporting Morrowind through LOOT, with an adepted sorting algorithm and a mostly empty masterlist. As we said, problems at this point in time are to be expected and we set out to get feedback from testing our build with MW support. If certain plugins are placed incorrectly, okay, tell us and we will see what we can do.

You do need to understand though, that LOOT is not MLOX. On a technical as well as a design point, LOOT handles things different than MLOX (or BOSS), so it is important for us to first see what LOOT can do on it's own. What does it get right? What does it get wrong? Once we have more experience on this subject, we could reevaluate the situation with MLOX and it's own masterlist, but it wouldn't be in our best interest to outright start with converting MLOX's masterlist.

So please, let us stay calm and friendly, I'd prefer it this way.

[abitoftaste]

People are just a lazy bunch jumping on the latest and greatest tool (hey, it's new, must be better) hoping to magically solve problems clicking a button, but it's not always like this.

Of course, because re-writing portions of LOOT to work with Morrowind and making a masterlist from scratch is "lazy".

I am obviously not referring to LOOT developers, I'm referring to the average Morrowind noob player unable to install a mod without 1 click nexus manager seeing e.g. your enthusiasm about current LOOT for Morrowind compared to current MLOX

Jesus, ABOT, what is your deal? Why are you being so hostile? Why do you constantly make assumptions without knowing what you're talking about?

I know what I am talking about, I'm making mods an modding Morrowind since 2004

Why do you hate absolutely anything new? Why are you like this in every channel I find you on?

I don't hate all new things, I hate new things trying to shit on old working things without being yet nearly as useful as old things

The masterlist for LOOT is currently completely empty - IE it doesn't have any rules yet. Because the project just started.
The point was that they wanted to make sure it was detecting the plugins and was able to run fine without any issues. That's it.

Ok. That's it. It works. It finds files. Nothing more. No internal magic logic solving conflicts without a rules base. needs a little more work to start being interesting

Also it didn't place multipatch on top. :/

this is good, that's why I did not assume anything but asked if it being placed on top of log lines was some kind of temporary thing I did not understand what use for in the log. Still lots of noise in that log, maybe useful for LOOT delopers, certainly not for MLOX experienced morrowind users/modders trying to contribute (that's the reason why I suggested a simpler log/log part showing just before/after loading ordering)

If you want to see what the rules look like for LOOT, you can see Skyrim SE's one here: https://github.com/loot/skyrimse/blob/v0.14/masterlist.yaml

That might clear it up a bit.

I was no more feeling like updating MLOX rules which I know enough, go figure if I'm investing time learning something I think has currently no future...

It was suggested because Mlox's current masterlist is seriously out-of-date, and the MLOX project seems pretty dead. It was a great tool and I respect the work that was put into it, but it just isn't enough >anymore.

the problem is not the tool IMO, it's having enough morrowind experts maintaining the rules (at least until most of them can be replaced by program embedded logic, which I was hoping LOOT could do at least for some part but it does not seem so yet)

The hope was that with enough advertisement and a new project, we could garner some support and make it something great. Plus LOOT offers functionality that Mlox doesn't, like groups.

I think proper support for compiling rules may come only from very experienced modders/players using plenty of Morrowind mods/morrowind tools from plenty of years, able to solve conflicts etc, and they must be willing to do a lot of boring work or be a lot of people... there have not been many for MLOX (Dragon32 alone in practice), I doubt there will be many for LOOT.

What LOOT team should try to learn IMO is what tools are historically used by Morrowind experts to find and solve loading conflicts, manage things like merging objects properties, merging leveled list and so on, and try to interface with these tools (or even replace their functionality if possible, that would surely be a plus e.g. the one existing object merging tool crashes with big loading lists and existing workarounds are far from perfect)

I understand that adapting a general-game purpose tool like loot for the specifics of Morrowind game may not be easy, but I don't think there is really another way to replace old tools / interest seasoned modders

[pStyl3]

A few months have passed, and two things should be mentioned. First, rules for the official mods by Bethesda have been added (see here), and @Ortham tweaked the sorting algorithm. To quote him:

I've tweaked how sorting works for Morrowind plugins to make it more like for other games. Previously, MW sorting wouldn't add any overlap edges between plugins, because LOOT can't work out if MW plugins contain records that override their masters' records (it's a lot more complicated to do than for other games). Now, LOOT compares how many records MW plugins contain, compared how many override records other games' plugins contain . Hopefully the total number of records in a plugin generally correlates well with the number of override records in the plugin, so that the result is similar most of the time.

I've made this change in the improve-morrowind-sorting branch of libloot, so if you want to try it out and report back, replace the loot.dll in this build of LOOT: https://bintray.com/loot/snapshots/download_file?file_path=loot_0.14.3-20-g925f3bc_morrowind-support.7z with this build of libloot: https://bintray.com/loot/snapshots/download_file?file_path=libloot-0.14.9-2-g73befaa_improve-morrowind-sorting-win32.7z

Any feedback we can get would be appreciated.

[Ortham]

As I commented on Discord, it's possible for LOOT to work out how many override records a Morrowind plugin contains, but doing so would rely on all plugins' masters being present, and sorting would fail if that wasn't the case.

I wouldn't generally expect this to be a problem, unless filter patches are a thing in Morrowind? If that terminology isn't used in the Morrowind community, a filter patch is a patch plugin that is left deactivated and has many masters, and Wrye Bash (or Mash in this case) is used to merge in the changes to records from masters that are installed. It's an alternative to having a patch plugin per master.

[abitoftaste]

Now, LOOT compares how many records MW plugins contain, compared how many override records other games' plugins contain . Hopefully the total number of records in a plugin generally correlates well with the number of override records in the plugin

Completely arbitrary assumption IMO. There are mods just meant to add new records, and mods just changing mostly tons of cells data...

the one correct approach to estimate number of record conflicts for automatic ordering IMO would be

1. only consider mods actually included in loading list (you can read them from Morrowind.ini file) , not all the ones present in Data Files folder
2. look for real record fields conflicts (like the ones TESTool merge objects/ TES3merge try to solve/merge) or TES conflict plugin detector can find

If you need detailed examples of what to search/compare I think TES3merge is the recent one with available source and Nullcascade can answer about it.

[Ortham]

Completely arbitrary assumption IMO.

Not completely, but I know it's unlikely to hold true in too many cases, and that's why I've been working on implementing the same overlap detection for Morrowind that is used for all the other games LOOT supports. It's not quite done yet though, hopefully I'll have a build out tonight.

the one correct approach to estimate number of record conflicts for automatic ordering IMO would be

A lot more work than the simplistic "is this record present in both plugins" logic that LOOT currently uses for other games, and LOOT's current approach is good enough the vast majority of cases AFAIK, so that's why I'm aiming to bring Morrowind support in line with that.

After all, if two plugins touch the same record, LOOT will say that the one that contains more non-new (i.e. override) records should load before the other, so that each plugin's 'impact' on your game is maximised. If the plugins don't actually make incompatible changes, then the order they're loaded in doesn't matter, but LOOT still needs to pick an order for stable sorting. It could fall back to the tie-breaking logic, which would preserve the existing load order, but the distinction generally has a minor impact if any, so it's not really worth going to all the extra effort of proper conflict detection.

[Ortham]

Right, here's a libloot build that counts override records correctly, as I mentioned above:

https://bintray.com/loot/snapshots/download_file?file_path=libloot-0.14.9-3-g5fa5b29_improve-morrowind-sorting-win32.7z

Just drop it into the same morrowind-support LOOT build as before, replacing the existing loot.dll.

[Ortham]

I've also updated LOOT's morrowind-support branch to use the latest libloot build, so anyone wanting to test only needs to download this archive.

[Ortham]

Another day, another libloot update: I've gone for a hybrid approach, so LOOT will use the proper override record count for a plugin that has all its masters installed, and fall back to using the total record count instead for a plugin with missing masters.

My logic is that a plugin with missing masters can't be loaded by the game, so if it gets sorted incorrectly it's less (or not at all?) significant, and it's better to be able to sort a load order with missing masters and get a slightly wonky result than to error out completely given that.

AFAIK this means that LOOT's Morrowind support is now pretty much on par with the other games (not counting the masterlist, just code), so I've released libloot v0.14.10 with the changes, updated LOOT's morrowind-support branch to use it, and rebased the branch on top of master. You can now grab the latest build here.

[Ortham]

I've merged the morrowind-support branch into master, so I'm closing this issue. If anyone testing Morrowind support comes across something that looks wrong, please file a new issue for it.