Jump to content

[RELz] LOOT - Load Order Optimisation Tool


WrinklyNinja

Recommended Posts

8 hours ago, coldcell said:

Possible bug report

 

I'm using Audio Overhaul Skyrim and RealisticWaterTwo. There is a patch by AOS for RWT, but LOOT puts the patch above RWT while RWT is sorted as last. This made the patch useless since it's above RWT. As a result the in-game sound of waterwall is extremely loud. I manually put the patch below RWT every time I need to sort.

Other than that, LOOT works great.

 

Thanks!

Please provide the specific plugin names if you want metadata to get added.

5 hours ago, oSloRSIsTeRI said:

With the latest masterlist, I had a cyclic error on a build I had already been running, but could not find what had changed in the masterlist to result in this.

I solved this by adding to "My Home Is Your Home.esp" a load after "RealisticWaterTwo+-+Verdant+Patch.esp" tag.  I am still learning the master list, so any education on what happened would be helpful.

Are you using a dev build or the latest release? Please upload your debug log, that'll give the details of what's happened.

  • Like 1
Link to comment
Share on other sites

1 hour ago, WrinklyNinja said:

Please provide the specific plugin names if you want metadata to get added.

Are you using a dev build or the latest release? Please upload your debug log, that'll give the details of what's happened.

I removed my custom metadata rules and reran to generate the error.  Debug log attached.  I am using Dev Build loot_0.12.5-15-g0388f4f_update-cef Version 0.12.5 (build 0388f4f5)

LOOTDebugLog.7z

Link to comment
Share on other sites

OK, it looks like "RealisticWaterTwo+-+Verdant+Patch.esp"  should get put into the same group as RealisticWaterTwo.esp (or My Home Is Your Home.esp moved into a later group), because it has RWT as a master but is in the default group, so MHIYH tries to load after it while also loading before RWT. This may be a general problem though, where patches to plugins in late-loading groups cause cycles with plugins in in-between groups, I need to have a think about whether there's a general solution that's intuitive and doesn't involve adding the patches to the late-loading groups...

  • Thanks 1
Link to comment
Share on other sites

On 17/04/2018 at 11:23 AM, coldcell said:

Possible bug report

 

I'm using Audio Overhaul Skyrim and RealisticWaterTwo. There is a patch by AOS for RWT, but LOOT puts the patch above RWT while RWT is sorted as last. This made the patch useless since it's above RWT. As a result the in-game sound of waterwall is extremely loud. I manually put the patch below RWT every time I need to sort.

Other than that, LOOT works great.

 

Thanks!

It's because Audio Overhaul Skyrim 2 realistic water patch does not have RWT as a master, because it does not require it.

Edit: New meta-data rule has been submitted.

Link to comment
Share on other sites

6 hours ago, cptmcsplody said:

It's because Audio Overhaul Skyrim 2 realistic water patch does not have RWT as a master, because it does not require it.

Edit: New meta-data rule has been submitted.

And I've merged it, so that issue should be fixed now.

Link to comment
Share on other sites

On 17/04/2018 at 8:47 PM, oSloRSIsTeRI said:

I removed my custom metadata rules and reran to generate the error.  Debug log attached.  I am using Dev Build loot_0.12.5-15-g0388f4f_update-cef Version 0.12.5 (build 0388f4f5)

LOOTDebugLog.7z

 

On 19/04/2018 at 12:29 AM, WrinklyNinja said:

OK, it looks like "RealisticWaterTwo+-+Verdant+Patch.esp"  should get put into the same group as RealisticWaterTwo.esp (or My Home Is Your Home.esp moved into a later group), because it has RWT as a master but is in the default group, so MHIYH tries to load after it while also loading before RWT. This may be a general problem though, where patches to plugins in late-loading groups cause cycles with plugins in in-between groups, I need to have a think about whether there's a general solution that's intuitive and doesn't involve adding the patches to the late-loading groups...

I've filed loot/loot-api#22 to track the general case of this issue.

  • Thanks 1
Link to comment
Share on other sites

Currently the groups for official bethesda plugins are defined across all masterlists like this:

Spoiler

Oblivion

Oblivion.esm / Main Game Master
DLCShiveringIsles.esp / DLC & Unofficial Patches
DLCBattlehornCastle.esp / DLC & Unofficial Patches
DLCThievesDen.esp / DLC & Unofficial Patches
DLCMehrunesRazor.esp / DLC & Unofficial Patches
DLCVileLair.esp / DLC & Unofficial Patches
DLCHorseArmor.esp / DLC & Unofficial Patches
DLCOrrery.esp / DLC & Unofficial Patches
DLCSpellTomes.esp / DLC & Unofficial Patches
DLCFrostcrag.esp / DLC & Unofficial Patches
Knights.esp / DLC & Unofficial Patches
Unofficial Oblivion Patch.esp / DLC & Unofficial Patches

  - name: &gameMasterGroup Main Game Master
  - name: &dlcGroup DLC & Unofficial Patches

 

Skyrim

Skyrim.esm / default
Update.esm / Update.esm
Dawnguard.esm / Unofficial Patches
HearthFires.esm / Unofficial Patches
Dragonborn.esm / Unofficial Patches
HighResTexturePack01.esp / Unofficial Patches
HighResTexturePack02.esp / Unofficial Patches
HighResTexturePack03.esp / Unofficial Patches
Unofficial Skyrim Patch.esp / Unofficial Patches

  - name: &updateEsmGroup Update.esm
  - name: &unofficialPatchGroup Unofficial Patches

 

Skyrim Special Edition

Skyrim.esm / default
Update.esm / DLC
Dawnguard.esm / DLC
HearthFires.esm / DLC
Dragonborn.esm / DLC
cc.esl / DLC

  - name: &dlcGroup DLC
  - name: &unofficialPatchGroup Unofficial Patches

 

Fallout 3

Fallout3.esm / default
Anchorage.esm / DLC
ThePitt.esm / DLC
BrokenSteel.esm / DLC
PointLookout.esm / DLC
Zeta.esm / DLC

  - name: &dlcGroup DLC
  - name: &uf4pGroup Unofficial Patches

 

Fallout New Vegas

FalloutNV.esm / default
DeadMoney.esm / DLC
HonestHearts.esm / DLC
OldWorldBlues.esm / DLC
LonesomeRoad.esm / DLC
GunRunnersArsenal.esm / DLC
ClassicPack.esm / DLC
MercenaryPack.esm / DLC
TribalPack.esm / DLC
CaravanPack.esm / DLC

  - name: &dlcGroup DLC
  - name: &yupFixesGroup YUP NPC Fixes

 

Fallout 4

Fallout4.esm / default
DLCRobot.esm / DLC
DLCworkshop01.esm / DLC
DLCCoast.esm / DLC
DLCworkshop02.esm / DLC
DLCworkshop03.esm / DLC
DLCNukaWorld.esm / DLC
DLCUltraHighResolution.esm / DLC
cc.esl / DLC

  - name: &dlcGroup DLC
  - name: &fixesGroup Fixes

 

As can be seen, there are certain aspects that are treated differently, which is primarily a result of how the former priority numbers were defined. This was not a huge problem until now, however, now that we use groups and therefore, the group names can be seen within LOOT's sidebar (as clear text) if the metadata editor is opened, I think it is going to be a bit more of a problem. Well, not a problem per se, but .. it's irritating. Especially if the user uses more than one game that LOOT supports and is therefore likely to notice this sooner or later.

In order to standardise this naming scheme for all masterlists, I would suggest the following:

 

Oblivion:

  • Rename "&dlcGroup DLC & Unofficial Patches" to "&dlcGroup DLC"
  • Set up "&unofficialPatchGroup Unofficial Patches" and let it load after "&dlcGroup"
  • Switch the group for "Unofficial Oblivion Patch.esp" (and alike) to "&unofficialPatchGroup"

Skyrim:

  • Create "&dlcGroup DLC"
  • Switch the official DLCs to "&dlcGroup DLC" .. they are currently defined as unofficial patches

Fallout 3:

  • Rename "&uf4pGroup Unofficial Patches" to "&unofficialPatchGroup Unofficial Patches"

Fallout New Vegas:

  • Rename "&yupFixesGroup YUP NPC Fixes" to "&unofficialPatchGroup YUP NPC Fixes"

Fallout 4:

  • Rename "&fixesGroup Fixes" to "&unofficialPatchGroup Unofficial Patches"

 

Furthermore, I suspect that Oblivion's "Oblivion.esm" was given the "&gameMasterGroup" group for a reason (that I can't recall right now) .. this makes Oblivion.esm the only main plugin across the masterlists that is not in the default group. If that's what is needed, no issue, however would speak something against giving the other main plugins (Skyrim.esm, Fallout3.esm, et cetera) the group "&gameMasterGroup", aswell?

Then there is also Skyrim's "&updateEsmGroup Update.esm". I don't know, I'm not so keen on that name (to be precise, I'm not sure if plugin name == group name is a good idea). How about "&updateEsmGroup Pre Official"?

Link to comment
Share on other sites

IIRC the expected load order for some games' unofficial patches is such that it goes DLC, patch, DLC, patch, DLC, patch, so separating the DLC and unofficial patches group would complicate that. I agree that having more standard / descriptive names would be better though, and I'm open to suggestions / PRs.

I think the reason Oblivion.esm is in its own group is because Oblivion has several mod plugins that don't require Oblivion.esm (it was a relatively popular thing to do when Nehrim came out - I think I might have did it for a couple of mine), but it should still load first, so the group is there to enforce that. I haven't heard any other game having similar mod plugins, which is probably why no other masterlists have it.

Semi-similarly for Skyrim, it's the only game with an Update.esm and the load order behaviour of Update.esm is weird, so it has a special group so that it loads straight after Skyrim.esm as that's generally the most sensible place for it but it otherwise won't always load there.

Link to comment
Share on other sites

  • 2 weeks later...
On 4/23/2018 at 9:28 PM, WrinklyNinja said:

IIRC the expected load order for some games' unofficial patches is such that it goes DLC, patch, DLC, patch, DLC, patch, so separating the DLC and unofficial patches group would complicate that. I agree that having more standard / descriptive names would be better though, and I'm open to suggestions / PRs.

I think the reason Oblivion.esm is in its own group is because Oblivion has several mod plugins that don't require Oblivion.esm (it was a relatively popular thing to do when Nehrim came out - I think I might have did it for a couple of mine), but it should still load first, so the group is there to enforce that. I haven't heard any other game having similar mod plugins, which is probably why no other masterlists have it.

Semi-similarly for Skyrim, it's the only game with an Update.esm and the load order behaviour of Update.esm is weird, so it has a special group so that it loads straight after Skyrim.esm as that's generally the most sensible place for it but it otherwise won't always load there.

I'll be thinking of something tomorrow evening.

I like the look of the default group being colored orange. Now we can see the "top(s)", "bottom(s)" and the "center" of all groups, which helps bringing things into perspective.

Also, over at Nexus three people have written comments regarding LOOT's groups feature, you might want to look at those wrinkly.

Link to comment
Share on other sites

Probably unlikely to happen, but I'll ask anyway. In case of Skyrim, the Unofficial Skyrim Legendary Edition Patch is the current standard when it comes to unofficial patches, and it loads after the official DLCs. Previously the unofficial patch team had created individual patches for Skyrim and it's three DLCs, and these four unofficial patches were loaded interleaved among the official plugins. The thing is, these individual patches have long been superseeded and as it seems, they even got removed from Nexus. There are still files uploaded to Nexus like this one that are "on the old standard", however those are superseeded aswell and even link to the Legendary Edition Patch version.

As such, wouldn't it be reasonable to discontinue support for those old individual unofficial patches, for Skyrim, starting with the upcoming v0.13 masterlist branch (= remove those entries from the masterlist)? As it stands, all urls within Skyrim's masterlist that point to USKP, UDGP, UHFP and UDBP are dead anyway. What's your opinion on this @Arthmoor ?

Link to comment
Share on other sites

On 4/23/2018 at 8:28 PM, WrinklyNinja said:

IIRC the expected load order for some games' unofficial patches is such that it goes DLC, patch, DLC, patch, DLC, patch, ~

That remains true for Oblivion, from the Wrye Bash Pictorial Guide ..

 

35230-2-1501873920.png

Link to comment
Share on other sites

On 5/4/2018 at 9:40 AM, pStyl3 said:

I'll be thinking of something tomorrow evening.

I like the look of the default group being colored orange. Now we can see the "top(s)", "bottom(s)" and the "center" of all groups, which helps bringing things into perspective.

Also, over at Nexus three people have written comments regarding LOOT's groups feature, you might want to look at those wrinkly.

Thanks, I've taken a look and it seems like they're having the kind of problem described in loot-api#22.

8 hours ago, pStyl3 said:

Probably unlikely to happen, but I'll ask anyway. In case of Skyrim, the Unofficial Skyrim Legendary Edition Patch is the current standard when it comes to unofficial patches, and it loads after the official DLCs. Previously the unofficial patch team had created individual patches for Skyrim and it's three DLCs, and these four unofficial patches were loaded interleaved among the official plugins. The thing is, these individual patches have long been superseeded and as it seems, they even got removed from Nexus. There are still files uploaded to Nexus like this one that are "on the old standard", however those are superseeded aswell and even link to the Legendary Edition Patch version.

As such, wouldn't it be reasonable to discontinue support for those old individual unofficial patches, for Skyrim, starting with the upcoming v0.13 masterlist branch (= remove those entries from the masterlist)? As it stands, all urls within Skyrim's masterlist that point to USKP, UDGP, UHFP and UDBP are dead anyway. What's your opinion on this @Arthmoor ?

I'm generally against removing plugins, but removing dead metadata and adding "upgrade to X" messages would be sensible. Just because they're not available for download doesn't mean they aren't getting shared around in mod packs or that people booting up their years-old modded games wouldn't benefit from being told about the fact they're superceded.

Link to comment
Share on other sites

Agreed, probably best to just change all of the link data to point to using USLEEP instead since the old patches have been gone now for some time.

And a question of my own while I'm thinking about it. Which branch on GitHub should we be using in order to submit a contribution of some kind now for the masterlist on SSE?

Link to comment
Share on other sites

1 hour ago, Arthmoor said:

Agreed, probably best to just change all of the link data to point to using USLEEP instead since the old patches have been gone now for some time.

And a question of my own while I'm thinking about it. Which branch on GitHub should we be using in order to submit a contribution of some kind now for the masterlist on SSE?

The v0.10 branch, as it's the default. I'll merge everything in it into the v0.13 branch when that becomes the default.

Link to comment
Share on other sites

Hello.

The LOOT metadata for ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp from Valdacil's Item Sorting Fallout 4 mod seems out of date.

Current:

Spoiler

{
		    "after": [
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ArmorByClass.esp",
		            "name": "ValdacilsItemSorting-ArmorByClass.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCAutomatron-Weightless.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCAutomatron-Weightless.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCAutomatron.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCAutomatron.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCFarHarbor-Weightless.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCFarHarbor-Weightless.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCFarHarbor.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCFarHarbor.esp"
		        }
		    ],
		    "clean": [],
		    "dirty": [],
		    "enabled": true,
		    "globalPriority": 0,
		    "inc": [],
		    "msg": [],
		    "name": "ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp",
		    "priority": 0,
		    "req": [],
		    "tag": [],
		    "url": [
		        {
		            "link": "http://www.nexusmods.com/fallout4/mods/3877",
		            "name": ""
		        }
		    ]
		}

As the ZZ-DLCArmorBy…Override indeed has to be loaded after the default ValdacilsItemSorting-ArmorBy….esp, which would be the main non-DLC version, this seems correct at first. But Valdacil has uploaded an update, v9.1 opposed to 9.0.3, which actually is an update to this DLC version, but with the same name as the main one. So for the updated version, it should load after the other "armor" ESPs. I don't post this at the mod's forum, because there are already several comments about LOOT, most of which tell to simply not use it with Fallout 4.

Link to comment
Share on other sites

I have grown to despise this tool. It's always something...

For reasons completely unbeknownst to me LOOT is failing to update its masterlist.

Again.

I can copy the recent list into a text file and name it masterlist.yaml but that doesn't address the fundamental issue: wtf is wrong with this goddamn application that it refuses to function roughly 70% of the time?

Link to comment
Share on other sites

5 hours ago, whitelion1284 said:

I have grown to despise this tool. It's always something...

For reasons completely unbeknownst to me LOOT is failing to update its masterlist.

Again.

I can copy the recent list into a text file and name it masterlist.yaml but that doesn't address the fundamental issue: wtf is wrong with this goddamn application that it refuses to function roughly 70% of the time?

Try going outside, reading a book, or spending time with friends. It won't fix LOOT's issues, but it might get you in the right frame of mind to ask for help constructively.

Link to comment
Share on other sites

On 5/7/2018 at 7:24 PM, compleCCity said:

Hello.

The LOOT metadata for ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp from Valdacil's Item Sorting Fallout 4 mod seems out of date.

Current:

  Hide contents

 

  Hide contents

 




{
		    "after": [
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ArmorByClass.esp",
		            "name": "ValdacilsItemSorting-ArmorByClass.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCAutomatron-Weightless.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCAutomatron-Weightless.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCAutomatron.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCAutomatron.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCFarHarbor-Weightless.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCFarHarbor-Weightless.esp"
		        },
		        {
		            "condition": "",
		            "display": "ValdacilsItemSorting-ZZ-DLCFarHarbor.esp",
		            "name": "ValdacilsItemSorting-ZZ-DLCFarHarbor.esp"
		        }
		    ],
		    "clean": [],
		    "dirty": [],
		    "enabled": true,
		    "globalPriority": 0,
		    "inc": [],
		    "msg": [],
		    "name": "ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp",
		    "priority": 0,
		    "req": [],
		    "tag": [],
		    "url": [
		        {
		            "link": "http://www.nexusmods.com/fallout4/mods/3877",
		            "name": ""
		        }
		    ]
		}

 

 

As the ZZ-DLCArmorBy…Override indeed has to be loaded after the default ValdacilsItemSorting-ArmorBy….esp, which would be the main non-DLC version, this seems correct at first. But Valdacil has uploaded an update, v9.1 opposed to 9.0.3, which actually is an update to this DLC version, but with the same name as the main one. So for the updated version, it should load after the other "armor" ESPs. I don't post this at the mod's forum, because there are already several comments about LOOT, most of which tell to simply not use it with Fallout 4.

Can you give specific plugin names? The "this DLC version", "main one", "So for the updated version, it" confuse me, I don't know what you're referring to.

Link to comment
Share on other sites

19 hours ago, WrinklyNinja said:

Can you give specific plugin names? The "this DLC version", "main one", "So for the updated version, it" confuse me, I don't know what you're referring to.

Okay, another attempt. (Let me say, that installing VIS isn't less confusing. ;) )

Valdacil's Item Sorting

I go for the "by class" option but I guess it's the same for the "by slot" one.

From the main mod, v. 9.0.3 – has to be installed first:

  • ValdacilsItemSorting-ArmorByClass.esp – Name of the file that would sort armor by class for a non-DLC game.
  • ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp – Name of the file with DLC.

The FOMOD tells that only one has to be used, and it should be loaded last. (Well, sort of – the same is said for the cosmetics and weapons ESPs.) I guess, this is why the current LOOT metadata contains the cited load order.

Spoiler

{
    "after": [
        {
            "condition": "",
            "display": "ValdacilsItemSorting-ArmorByClass.esp",
            "name": "ValdacilsItemSorting-ArmorByClass.esp"
        }

Then there is an update in the files' section, v. 9.1. It requires the DLC. There are no specific installation instructions, no ReadMe, only the file packed for an MM setup. This file's name is – bad choice – ValdacilsItemSorting-ArmorByClass.esp. Which is the same name as for the above listed non-DLC version, but this time with DLC. As it has the same name, LOOT metadata is applied to it. But as it also is an update to the ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp, it should be loaded after it, I suppose.

I have to tell that I haven't done a detailed look into the file's contents, I haven't compared the 9.0.3 and the 9.1 versions of the ESP, and it might be that the older file isn't necessary. Disabling that ZZ-DLCArmorByClassOverride-plugin would indeed solve this conflict, but do I know if there are any entries that are still needed?

 

Okay, seems this is redundant. Searched a bit through the mod's forum, and somewhere there's a hint that ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp can be disabled when the update is installed.

 

Edit: After disabling the redundant (and possibly conflicting ESP) LOOT warns with "You are sorting armor by class and also using DLCs. You may want to use "ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp" to enable the class sorting on DLC armor as well.

Edited by compleCCity
addendum
Link to comment
Share on other sites

7 hours ago, compleCCity said:

Okay, another attempt. (Let me say, that installing VIS isn't less confusing. ;) )

Valdacil's Item Sorting

I go for the "by class" option but I guess it's the same for the "by slot" one.

From the main mod, v. 9.0.3 – has to be installed first:

  • ValdacilsItemSorting-ArmorByClass.esp – Name of the file that would sort armor by class for a non-DLC game.
  • ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp – Name of the file with DLC.

The FOMOD tells that only one has to be used, and it should be loaded last. (Well, sort of – the same is said for the cosmetics and weapons ESPs.) I guess, this is why the current LOOT metadata contains the cited load order.

  Reveal hidden contents

{
    "after": [
        {
            "condition": "",
            "display": "ValdacilsItemSorting-ArmorByClass.esp",
            "name": "ValdacilsItemSorting-ArmorByClass.esp"
        }

Then there is an update in the files' section, v. 9.1. It requires the DLC. There are no specific installation instructions, no ReadMe, only the file packed for an MM setup. This file's name is – bad choice – ValdacilsItemSorting-ArmorByClass.esp. Which is the same name as for the above listed non-DLC version, but this time with DLC. As it has the same name, LOOT metadata is applied to it. But as it also is an update to the ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp, it should be loaded after it, I suppose.

I have to tell that I haven't done a detailed look into the file's contents, I haven't compared the 9.0.3 and the 9.1 versions of the ESP, and it might be that the older file isn't necessary. Disabling that ZZ-DLCArmorByClassOverride-plugin would indeed solve this conflict, but do I know if there are any entries that are still needed?

 

Okay, seems this is redundant. Searched a bit through the mod's forum, and somewhere there's a hint that ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp can be disabled when the update is installed.

 

Edit: After disabling the redundant (and possibly conflicting ESP) LOOT warns with "You are sorting armor by class and also using DLCs. You may want to use "ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp" to enable the class sorting on DLC armor as well.

OK, I understand now. Fortunately ValdacilsItemSorting-ArmorByClass.esp v9.1 has its version number in its description, so I've put a condition on that warning message so it's not shown for the updated plugin.

Link to comment
Share on other sites

I also have been looking at the metadata for Valdacil's Item Sorting mod, and I think I found a few more things to mention. The main file from VIS currently includes a total amount of 48 plugins. LOOT's masterlist contains all of them in the "after:" field of the plugin

- name: 'Radrose Usability Enhancements.esp'

So far so good. When it comes to the section where LOOT addresses the plugins directly (i.e.  - name: 'ValdacilsItemSorting-00-ValsPicks-DLCVersion.esp'), it only covers "most" of them. The following plugins are not covered:

ValdacilsItemSorting-ZY-DLCAutomatron.esp
ValdacilsItemSorting-ZY-DLCAutomatron-Weightless.esp
ValdacilsItemSorting-ZY-DLCContraptions.esp
ValdacilsItemSorting-ZY-DLCContraptions-Weightless.esp
ValdacilsItemSorting-ZY-DLCFarHarbor.esp
ValdacilsItemSorting-ZY-DLCFarHarbor-Weightless.esp
ValdacilsItemSorting-ZY-DLCNukaWorld.esp
ValdacilsItemSorting-ZY-DLCNukaWorld-Weightless.esp
ValdacilsItemSorting-ZY-DLCVaultTec.esp
ValdacilsItemSorting-ZY-DLCVaultTec-Weightless.esp
ValdacilsItemSorting-ZZ-DLCArmorBySlotOverride.esp
ValdacilsItemSorting-ZZ-DLCCosmeticsByClassOverride.esp
ValdacilsItemSorting-ZZ-DLCCosmeticsByTypeOverride.esp
ValdacilsItemSorting-ZZ-DLCWeaponsOverride.esp


However, LOOTs masterlist contains the following entries:

ValdacilsItemSorting-ZZ-DLCAutomatron.esp
ValdacilsItemSorting-ZZ-DLCAutomatron-Weightless.esp
ValdacilsItemSorting-ZZ-DLCFarHarbor.esp
ValdacilsItemSorting-ZZ-DLCFarHarbor-Weightless.esp
ValdacilsItemSorting-ZZ-DLCRuleArmorByClassOverride.esp
ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp

Regarding these 6 plugins: There is nothing wrong with "ValdacilsItemSorting-ZZ-DLCArmorByClassOverride.esp". On the other hand "ValdacilsItemSorting-ZZ-DLCRuleArmorByClassOverride.esp" does seem to be an old plugin, which no longer is used within the newest version of the mod. The other 4 plugin entries however .. it seems to me that here is an actual mistake within LOOTs masterlist. They should probably include a "ZY" and not a "ZZ" within their name (so the two DLCAutomatron and DLCFarHarbor plugins).

 

If that would be fixed, the plugins that probably should still be added to the masterlist, would then be:

ValdacilsItemSorting-ZY-DLCContraptions.esp
ValdacilsItemSorting-ZY-DLCContraptions-Weightless.esp
ValdacilsItemSorting-ZY-DLCNukaWorld.esp
ValdacilsItemSorting-ZY-DLCNukaWorld-Weightless.esp
ValdacilsItemSorting-ZY-DLCVaultTec.esp
ValdacilsItemSorting-ZY-DLCVaultTec-Weightless.esp
ValdacilsItemSorting-ZZ-DLCArmorBySlotOverride.esp
ValdacilsItemSorting-ZZ-DLCCosmeticsByClassOverride.esp
ValdacilsItemSorting-ZZ-DLCCosmeticsByTypeOverride.esp
ValdacilsItemSorting-ZZ-DLCWeaponsOverride.esp

Link to comment
Share on other sites

For those interested in testing groups, I've just landed a change to sorting's group cycle avoidance that should prevent cycles in more situations than before while hopefully not introducing any side effects. To get the change, replace your current loot_api.dll with this one. I've yet to update the docs to coverthe new rules, so here's my latest attempt to explain the change:

Before, if you had:

  • two plugins A.esp and B.esp belonging to groups A and B respectively
  • A.esp having B.esp as a master
  • group B loading after group A

LOOT would spot the cycle and avoid it by ignoring A.esp's group, as group metadata isn't as important as more specific metadata like a plugin's masters. However, given a more complex situation like:

  • Three plugins A.esp, B.esp and C.esp belonging to groups early, mid and late respectively
  • A.esp having C.esp as a master
  • late loading after mid, and mid loading after early

LOOT would avoid the cycle between A.esp and C.esp, but it wouldn't avoid the cycle between A.esp and B.esp, because when checking for cycles it would just be considering the groups of A.esp and B.esp but not the metadata of C.esp.

The change I've made is that now when LOOT spots the cycle between A.esp and C.esp, it gets the groups they belong to, and finds all the groups that form paths in the dependency tree between those two groups, then ignores A.esp's group when comparing it against all the plugins in all those groups, which in this case are the plugins in the mid and late groups. This should be fairly intuitive: if a plugin has specific metadata saying it needs to load after a plugin in the late group, it obviously can't load before anything in mid or late.

On 5/10/2018 at 9:13 PM, pStyl3 said:

I also have been looking at the metadata for Valdacil's Item Sorting mod, and I think I found a few more things to mention. The main file from VIS currently includes a total amount of 48 plugins. LOOT's masterlist contains all of them in the "after:" field of the plugin

...

Any chance you could turn that info into a pull request?

Link to comment
Share on other sites

6 hours ago, WrinklyNinja said:

Any chance you could turn that info into a pull request?

I will, in a couple of days.

Link to comment
Share on other sites

On 4/23/2018 at 9:28 PM, WrinklyNinja said:

IIRC the expected load order for some games' unofficial patches is such that it goes DLC, patch, DLC, patch, DLC, patch, so separating the DLC and unofficial patches group would complicate that. I agree that having more standard / descriptive names would be better though, and I'm open to suggestions / PRs.

For games that need both official DLCs and Unofficial Patches within the same group, how about we name such groups "&headGroup Head". The Head group would:

  • Contain official Bethesda plugins except the main game master files (Oblivion.esm, etc) and files such as Skyrim's Update.esm
  • Contain unofficial patches
  • Have a short and concise name, instead of e.g.  "DLC & Unofficial Patches". This would also have the side effect that this Head group would be more neutral towards unofficial patches/fix patches not containing the word "unofficial" within their name.

In addition, if Oblivion's group for "Oblivion.esm" is defined as "Main Game Master", could we define Skyrim's group for "Update.esm" then as "Main Game Update"? Basically the standard would be "Main Game X", where X stands either for Master if the game in question needs a master group, or for "Update", if the game has an additional Update.esm like Skyrim does.

That way, a "Head" group would then convey the message (by it's name alone), that it's the very first group to load after the "Main Game X" group.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...