Jump to content

[RELz] LOOT - Load Order Optimisation Tool


WrinklyNinja

Recommended Posts

On 7/18/2018 at 3:32 AM, cptmcsplody said:

Hi Guys,

I'm adding Bash Tag suggestions for SSE main files and USSEP and was looking for some feedback. Since they're the base of the game I'd like to get them right.

USSEP currently has tags in its header, but I'd like to include it for discussion as some of the tags suggestion listed below are currently not used in LE or SSE.

Available Bash Tags any tag with a strike-through doesn't seem to be useful for SSE.

  Reveal hidden contents
  • Actors.ACBS
  • Actors.AIData
  • Actors.AIPackages
  • Actors.AIPackagesForceAdd
  • Actors.Animations
  • Actors.CombatStyle
  • Actors.DeathItem
  • Actors.Skeleton
  • Actors.Spells
  • Actors.SpellsForceAdd
  • Actors.Stats
  • Body-F
  • Body-M
  • Body-Size-F
  • Body-Size-M
  • C.Acoustic
  • C.Climate
  • C.Encounter
  • C.ImageSpace
  • C.Light
  • C.Location
  • C.Music
  • C.Name
  • C.Owner
  • C.RecordFlags
  • C.Regions
  • C.SkyLighting
  • C.Water
  • Creatures.Blood
  • Deactivate
  • Delev
  • Eyes
  • Factions
  • Filter
  • Graphics
  • Hair
  • IIM
  • Invent
  • InventOnly
  • Merge
  • MustBeActiveIfImported
  • Names
  • NoMerge
  • NpcFaces
  • NpcFacesForceFullImport
  • NPC.Class
  • Npc.EyesOnly
  • Npc.HairOnly
  • NPC.Race
  • Relations
  • Relev
  • Roads
  • R.AddSpells
  • R.Attributes-F
  • R.Attributes-M
  • R.ChangeSpells
  • R.Description
  • R.Ears
  • R.Head
  • R.Mouth
  • R.Relations
  • R.Skills
  • R.Teeth
  • ScriptContents
  • Scripts
  • Sound
  • SpellStats
  • Stats
  • Voice-F
  • Voice-M

Bash Tag Suggestions

  Reveal hidden contents

For reference Wrye Bash Advanced Readme Latest Version
Issue 255 Update, DLC & USSEP bash tags
Update.esm



      - Actors.ACBS
      - Actors.CombatStyle
      - Actors.Stats
      - C.RecordFlags
      - C.Regions
      - C.Water
      - Delev
      - Graphics
      - Invent
      - Names
      - NPC.Class
      - Stats

Dawnguard.esm



      - Actors.AIData
      - Actors.DeathItem
      - C.Location
      - C.RecordFlags
      - C.Regions
      - Delev
      - Graphics
      - Invent
      - Names
      - NPC.Class
      - NPC.Race
      - Relations
      - Relev
      - Stats

Hearthfires.esm



      - Actors.AIPackages
      - C.Location
      - Factions
      - Graphics
      - Invent
      - Sound

Dragonborn.esm



      - Actors.ACBS
      - Actors.Stats
      - C.Location
      - C.RecordFlags
      - Factions
      - Graphics
      - Invent
      - Names
      - Relev
      - Stats

Unofficial Skyrim Special Edition Patch.esp
 



      - Actors.ACBS
      - Actors.AIData
      - Actors.AIPackages
      - Actors.CombatStyle
      - Actors.DeathItem
      - Actors.Spells
      - Actors.Stats
      - Body-Size-F
      - Body-Size-M
      - C.Acoustic
      - C.Climate
      - C.Encounter
      - C.ImageSpace
      - C.Light
      - C.Location
      - C.Music
      - C.Name
      - C.Owner
      - C.RecordFlags
      - C.Regions
      - C.Water
      - Delev
      - Factions
      - Graphics
      - Invent
      - Names
      - NPC.Class
      - NPC.Race
      - R.AddSpells
      - R.Description
      - Relations
      - Relev
      - Sound
      - SpellStats
      - Stats

 

 

@cptmcsplody Well the only reason there are redundant Bash Tags is because they have not been switched on for the newer version of Wrye Bash supporting newer games. Its due to the situation with how many patchers they dont have when compaired to Oblivion Wrye Bash.

In the case of Bash Tags they do not need to be developed really, just switched on in Wrye Bash code, but obviously the associated Patchers to get the appropriate records into the Bashed Patch do.

So allowing them to be in the masterlist is not going to cause any issues, same as allowing them to be listed completely in the plugins header itself .. One day Wrye Bash will be able to utilise them (well, fingers crossed anyway). And going with the authors suggested recommends (well at least from authors like Arthmoor who know what can be included as "important for the mod to work") will save you redoing them later on.

Maybe another masterlist maintainer in the future, if you are no longer around, and who has not seen this conversation, may well think there could have been good reason for leaving out the full list .. And does not change them just in case.

Maybe even Mator Smash can also utilise them at some point, or another Mod Manager like TES Mod Manager wouldn't surprise me.

  • Thanks 1
Link to comment
Share on other sites

21 hours ago, jimbosi said:

Anyone else get an error like this (or exactly):

Cyclic interaction detected between "Unofficial Skyrim Special Edition Patch.esp" and "Apachii_DivineEleganceStore.esm". Back cycle: Apachii_DivineEleganceStore.esm, Lanterns Of Skyrim - All In One - Main.esm, Unofficial Skyrim Special Edition Patch.esp

It's curious for me:

LOOT won't sort, like, at all, and
I've had the listed mods installed for a while, and the error is sudden.

Seems like a Masterlist issue.

Any way around this, so LOOT can ignore the warnings and sort as ordered?

As a side note, are there any alternatives to LOOT? Wyre Bash seems to have some sort of functionality there, but I don't know enough.

Anyway, FYSA, and TIA for responses. Cheers!

LOOTDebugLog.txt

Probably no difference- but do you have the USSEP patch for Apachii active?

Link to comment
Share on other sites

11 hours ago, alt3rn1ty said:

@cptmcsplody Well the only reason there are redundant Bash Tags is because they have not been switched on for the newer version of Wrye Bash supporting newer games. Its due to the situation with how many patchers they dont have when compaired to Oblivion Wrye Bash.

In the case of Bash Tags they do not need to be developed really, just switched on in Wrye Bash code, but obviously the associated Patchers to get the appropriate records into the Bashed Patch do.

So allowing them to be in the masterlist is not going to cause any issues, same as allowing them to be listed completely in the plugins header itself .. One day Wrye Bash will be able to utilise them (well, fingers crossed anyway). And going with the authors suggested recommends (well at least from authors like Arthmoor who know what can be included as "important for the mod to work") will save you redoing them later on.

Maybe another masterlist maintainer in the future, if you are no longer around, and who has not seen this conversation, may well think there could have been good reason for leaving out the full list .. And does not change them just in case.

Maybe even Mator Smash can also utilise them at some point, or another Mod Manager like TES Mod Manager wouldn't surprise me.

Okay, well some of the Tags for Skyrim & SE such as NpcFaces can be used by Mator Smash. But they're quite different to the Oblivion version and what's listed in the Wrye Bash Advanced Readme. I'll have to keep track of records used for these tags, in case they're ever implemented in wrye bash and need to be revised.

Top is Oblivion.

    // Bookmark: NpcFaces
    if asTag = 'NpcFaces' then
    begin
        EvaluateByPath(asTag, e, m, 'HNAM');
        EvaluateByPath(asTag, e, m, 'LNAM');
        EvaluateByPath(asTag, e, m, 'ENAM');
        EvaluateByPath(asTag, e, m, 'HCLR');
        EvaluateByPath(asTag, e, m, 'FaceGen Data');
    end;

    // Bookmark: NpcFaces
    if asTag = 'NpcFaces' then
    begin
        EvaluateByPath(asTag, e, m, 'Head Parts\PNAM - Head Part');
        EvaluateByPath(asTag, e, m, 'HCLF - Hair color');
        EvaluateByPath(asTag, e, m, 'FTST - Head texture');
        EvaluateByPath(asTag, e, m, 'QNAM - Texture lighting');
        EvaluateByPath(asTag, e, m, 'NAM9 - Face morph');
        EvaluateByPath(asTag, e, m, 'NAMA - Face parts');
        EvaluateByPath(asTag, e, m, 'Tint Layers');
    end;

I see Some Tags are being switched on in beta.

Link to comment
Share on other sites

On 7/21/2018 at 3:52 PM, jimbosi said:

Anyone else get an error like this (or exactly):

Cyclic interaction detected between "Unofficial Skyrim Special Edition Patch.esp" and "Apachii_DivineEleganceStore.esm". Back cycle: Apachii_DivineEleganceStore.esm, Lanterns Of Skyrim - All In One - Main.esm, Unofficial Skyrim Special Edition Patch.esp

It's curious for me:

LOOT won't sort, like, at all, and
I've had the listed mods installed for a while, and the error is sudden.

Seems like a Masterlist issue.

Any way around this, so LOOT can ignore the warnings and sort as ordered?

As a side note, are there any alternatives to LOOT? Wyre Bash seems to have some sort of functionality there, but I don't know enough.

Anyway, FYSA, and TIA for responses. Cheers!

LOOTDebugLog.txt

Can you enable debug logging in LOOT's settings, try again, and upload the log that gives you? I'm guessing that Apachii_DivineEleganceStore.esm wants to load after USSEP but for some reason it's loading before Lanterns of Skyrim, though I can't see any reason for that in the current masterlist.

On 7/22/2018 at 4:09 AM, Sharlikran said:

I have never had enough plugins to have ghosted files. If a .ghost extension exists will it be in loadorder.txt for old Skyrim? Will it be in plugins.txt but without the "*" for Skyrim SE?

I think ghosted plugins are listed without their .ghost extension, but I think LOOT will handle plugins listed with the .ghost extension too.

Link to comment
Share on other sites

I have some ESL load order questions:

Are/should-be ESMs (regardless of their extension(s)) always load ordered first-first?
Are even community/non-game/CC ESMs load ordered before CC ESLs?
Are CC ESMs load ordered before CC ESLs or are they always load ordered in the .ccc order, regardless of ESL/ESM extension and plugin flag?
Are .esl's always load ordered before ESPs?

I know there was a fair amount of discussion earlier, but on one hand I'm not sure whether additional logic is needed in my creation-club-entries.py script and I'm also seeing some inconsistent ESL behaviour with LOOT… but I want to be sure I understand what's supposed to be going on before I start making issues. :)

Link to comment
Share on other sites

CC ESLs will load before user made ESM files, but after the official master files. Same with CC ESM files. They're coded to do so via the exe file.

With the advent of the *.ccc file for each game, the load order may be handled by the order of the filenames in that .ccc file, but that hasn't been tested for yet.

As for the rest, I did a test on ESL load ordering here:

Keep in mind that was just for a vanilla record being overridden so it didn't have anything else to account for, but the results were clear.

Link to comment
Share on other sites

23 minutes ago, Arthmoor said:

With the advent of the *.ccc file for each game, the load order may be handled by the order of the filenames in that .ccc file, but that hasn't been tested for yet.

Right. The cc-entries script currently just loops over the .ccc file and adds them in the order they're there, but I'm thinking if I should make it have two passes so it first spits out the CC .esms and then afterwards the CC .esls.

I'm also seeing LOOT put a community .esl in between community .esms, and thinking about filing a LOOT issue about that, but trying to confirm that this is not intended behaviour.

Link to comment
Share on other sites

3 hours ago, Freso said:

Right. The cc-entries script currently just loops over the .ccc file and adds them in the order they're there, but I'm thinking if I should make it have two passes so it first spits out the CC .esms and then afterwards the CC .esls.

I'm also seeing LOOT put a community .esl in between community .esms, and thinking about filing a LOOT issue about that, but trying to confirm that this is not intended behaviour.

.esls can load amongst .esms from my testing, and if I'm reading Arthmoor's results right they say the same, so I don't think two passes are necessary. AFAIK LOOT's current behaviour is correct.

Link to comment
Share on other sites

With Alternate Start - Live Another Life 4.0.7, Arthmoor recommends that we now sort it before Open Cities. The masterlist needs to be updated to allow us to do that. (If it hasn't already. I haven't actually checked in a couple days.)

Edit: It's already been done. my apologies.

Link to comment
Share on other sites

Just a quick announcement: LOOT now has an official Discord server! I've been more or less the only person active in our IRC channel (with a small handful of lurkers, thanks guys ❤️) for literally years, and recently got sucked into various other modding tools' servers… so I talked with WrinklyNinja and created this:

https://discord.gg/SZVPRzf

Come join and say hi and hangout!

(I'll update website and such tomorrow so we have more official links to it too.)

Edited by Freso
Link to comment
Share on other sites

  • 2 weeks later...

I've just completed the upgrade of LOOT's UI from Polymer 2 to 3, which was a big change internally that should have almost no visible impact, so I'd appreciate if people could poke and prod this build to see if everything looks and works as they expect.

The only changes I've noticed are in the metadata editor:

  • Tables in the editor now have their headers styled like in the settings dialog.
  • Autocomplete text inputs now look slightly different, most obviously they don't have a cross icon when you enter text.

The move to Polymer 3 means that development uses the same tools and workflow as across the wider web UI development ecosystem. This makes it much easier to move away from using Polymer, which I think has turned out to be a very bad bet (maybe I'll write a blog post at some point about why). I'm looking at moving to React: in fact, the build linked above already contains an element that's partially written in React, because there's an element that LOOT was using that hasn't been updated to support Polymer 3. Vue also looks interesting, as a sort of half way point between Polymer's and React's designs, but I'm more interested in exploring something completely different to Polymer (that is enormously popular).

Link to comment
Share on other sites

Seeking some clarification as to how LOOT "groups" work even after reading the documentation.

I've built a number of "merged plugins" for "Fallout New Vegas": being careful to maintain both the ordering of LOOT's sort and the needed contiguous nature of the files to be merged.  These "merged plugins" have been mixed in among other individual files in the sorted load order and function just fine.

"Groups" seemed like a natural way to ensure those contiguous collections of plugins that made up the "merged plugin" would remain placed together when it becomes necessary to rebuild the merge.  So I created a "group" for and added the single existing "merged plugin" file to that group.  (Later I added the individual plugins that make up the merged file to the same group, but the problems started before then.)

Now here is where I get confused.  At first I added the new "merged plugin group" into the chain of "masterlist groups" just after the "default" group (as it normally sorted just after the "YUP Gameplay Tweaks" group, the last "masterlist group" before "default").  Normally (without assigning any new group) it had a couple of other "default" plugins preceding it.  But immediately upon assigning the plugin to that new group, it changed position in the load order.  The only difference was the creation of the group and inserting it into the descent chain of groups.

(Not clear to me what the "Dynamic Patches" group refers to.  Various forms of "merge patch files"?  It would help the documentation if the "masterlist groups" were explained.  I realize these groups seem to vary by game, but that just suggests their explanation needs to be "included" in the help file once the specific game has been identified.)

So I removed that group from the chain between "YUP" and the "default" groups, and just connected the "default" group to the "merged plugin" group (green circle).  I was expecting it to return to it's previous location in the sort order, but instead that causes the group to appear at the bottom of the load order; below the "LOD" group.

I tried various other experiments and the results seem to be that adding a plugin to a group immediately causes that plugin's normal position in the load order to be ignored, and the group position in the chain to override.  If not daisy-chained, but simply "spurred" off of "defaults" (green circle) the groups get sorted to the bottom of the load order below any other "default" (ungrouped) plugins, and not even in the same order relative to their position in the load order as individual files.  Even "daisy-chains" seem to ignore the intervening placement of single plugins.

I'm still assuming the "ungrouped" sorting should prevail first.  The individual plugins that were interspersed among the "merged plugin" files still need to be loading prior where that occurs.  The assignment to a "group" seems to break those priorities.

Also noticed that you can't simply remove a group entry from a plugin in the metadata.  Apparently you have to clear the entire metadata for that plugin and start over.


-Dubious-

Link to comment
Share on other sites

17 hours ago, Dubious said:
Seeking some clarification as to how LOOT "groups" work even after reading the documentation.

I've built a number of "merged plugins" for "Fallout New Vegas": being careful to maintain both the ordering of LOOT's sort and the needed contiguous nature of the files to be merged.  These "merged plugins" have been mixed in among other individual files in the sorted load order and function just fine.

"Groups" seemed like a natural way to ensure those contiguous collections of plugins that made up the "merged plugin" would remain placed together when it becomes necessary to rebuild the merge.  So I created a "group" for and added the single existing "merged plugin" file to that group.  (Later I added the individual plugins that make up the merged file to the same group, but the problems started before then.)

Now here is where I get confused.  At first I added the new "merged plugin group" into the chain of "masterlist groups" just after the "default" group (as it normally sorted just after the "YUP Gameplay Tweaks" group, the last "masterlist group" before "default").  Normally (without assigning any new group) it had a couple of other "default" plugins preceding it.  But immediately upon assigning the plugin to that new group, it changed position in the load order.  The only difference was the creation of the group and inserting it into the descent chain of groups.

(Not clear to me what the "Dynamic Patches" group refers to.  Various forms of "merge patch files"?  It would help the documentation if the "masterlist groups" were explained.  I realize these groups seem to vary by game, but that just suggests their explanation needs to be "included" in the help file once the specific game has been identified.)

So I removed that group from the chain between "YUP" and the "default" groups, and just connected the "default" group to the "merged plugin" group (green circle).  I was expecting it to return to it's previous location in the sort order, but instead that causes the group to appear at the bottom of the load order; below the "LOD" group.

I tried various other experiments and the results seem to be that adding a plugin to a group immediately causes that plugin's normal position in the load order to be ignored, and the group position in the chain to override.  If not daisy-chained, but simply "spurred" off of "defaults" (green circle) the groups get sorted to the bottom of the load order below any other "default" (ungrouped) plugins, and not even in the same order relative to their position in the load order as individual files.  Even "daisy-chains" seem to ignore the intervening placement of single plugins.

I'm still assuming the "ungrouped" sorting should prevail first.  The individual plugins that were interspersed among the "merged plugin" files still need to be loading prior where that occurs.  The assignment to a "group" seems to break those priorities.

Also noticed that you can't simply remove a group entry from a plugin in the metadata.  Apparently you have to clear the entire metadata for that plugin and start over.


-Dubious-

Your observations about how groups work all seem by design, but obviously you've got a model in your head that doesn't match that. If that's an intuitive model, how can we improve the docs to counter that intuition, and if that's a model you built from the docs, how can we improve the docs to get it right?

Also, there are no ungrouped plugins, so your point about not being able to remove a group entry is a by-definition thing. There is a point to be made that you can't easily reset to the group it has in the masterlist (if it has one set there).

Link to comment
Share on other sites

Hi, Wrinkly, hope all is going well for you!

Using LOOT Version 0.13.1 (build fc664279)  and it's working fine. The reason for this post is to let you know of a small QOL issue that you might want to look at: whenever I'm in the Game dropdown (the one where I choose which game to sort plugins for) the cursor changes to an I-Beam as I mouse over the game names, instead of the expected finger-pointing-hand icon. Normally, the I-beam means whatever it's on is not clickable, is not a link. So in this small way, LOOT is being deceptive, or at least less helpful to work with than it could be. I tried to get a screenshot to illustrate this, but my PrintScrn control is apparently set to NOT show the mouser cursor and I don't know how to fix that.

Thanks again for your work on this- I have no idea how we would be able to run 200+ plugins in our games without this essential tool. :wub:

Link to comment
Share on other sites

Re: LOOT Groups.

Sorry for the delayed response.  I had to step back and think over your questions, and check some of my initial assumptions.  One is that I have only been using LOOT with games that use the "Gamebryo" engine (Oblivion and Fallout New Vegas).  That has afforded me the luxury of ignoring the difficulties Skyrim and other "Creation Engine" games have brought to LOOT's table.  So, while the basics are still there I needed to re-learn how those differences impacted LOOT by reading the "Introduction to Load Orders" article.  (Nice article on the differences.  Doesn't seem to be linked into the "Application Documentation" though.)

However, the topic of how "Masterlist Groups" are applied is not covered (or I failed to find it) in the "Application Documentation".  Without attempting to dig into either the code or the instructions for maintaining the "masterlist", the "abstract picture" I perceived from the existing documentation runs as follows:

1. Plugins are loaded in current "load order" (meaning in date/time stamp sequence for Gamebryo engine games).
2. Master/dependency relationships are determined from the plugin headers.
3. Game and DLC masters are sorted to the top (lowest mod index) positions in dependency order.
3a.  Where dependency of "master" files is not related, they ''probably'' remain in timestamp or original load order.
4. Other "masters" are sorted to follow the "DLCs".
5. Probably the "dependencies" are then allowed to remain in the orginal load order sequence as they were encountered.
6. "Masterlist" groups are applied to both "masters" and "dependents".  (How is not explained.  The following are suppositions.)
6a. Presumably the "Master" mod-index position ordering relative to other "masters" is maintained.
6b. Dependents are checked to determine they do not violate other "master-dependent" relationships and then "masterlist groups" use their meta-data criteria (e.g. "load after") to place them after their "master" within the placement for that "masterlist group.
6c. Where there is no meta-data affecting their sequence, the master files remain in load order sequence.
6d. "Masterlist groups" follow the hierarchy of the "daisy-chain" links shown in the "Edit Groups" diagram.  (How this is applied is not known to me, and generally not considered important for user understanding.  It is only with the introduction of "user defined groups" (UDGs) that it appears to matter.)  These "masterlist groups" are generally categorized as "early", "mid", and "late" loading groups, with "default" group apparently determining the "mid" point.
7. All plugins which do not fall into any other "masterlist group" are placed in the "default" group in the sequence they appear in the load order after sorting for "master-dependency" relationships.  It was stated on the forum that "all plugins must belong to a group", which had been an unspoken assumption in the "Editing Plugin Groups" documentation which should be added and emphasized.  The "default" group is in the "mid" category of "masterlist groups".
8. Where needed, date/time stamps or "plugins.txt" files are updated.

The old "priorities" system appeared to have been a way of imposing a "secondary hierarchy" on the "default" group of plugins.  (This may have been another point where the "abstract picture" breaks down.  If the older priorities could override the "masterlist groups", I never tried to discovered it as I only used it with what appears to now be called the "Dynamic Patches" group: e.g. "TES5Merged Patch", "Bashed Patch", and "Override Patch" files to force them to load last in the correct order.)

Following the "rule of one" principle I have developed the habit of adding new plugins to my load order as near the top (low mod-index) as seemed practical (e.g. just below "unofficial patches"), and letting LOOT sort them down to the highest necessary override position as a solution to the "every author wants to load their plugin last so it wins" problem.  I've learned I can safely make some adjustments to the sorted sequence as long as I respect LOOT insisting that certain plugins follow others.  This permitted me to "group" plugins in contiguous sequence which could then be combined into a "merge plugin".  But it often meant that I had to split some logical groupings into more than one sub-group in order to respect LOOT's insistence.  (For example, I have four "Fixes" merged plugins for that very reason: LOOT wouldn't let them sit together.  One of them has combined 20 individual plugins.)

It initially appeared to me that the addition of UDGs were adding a "secondary" level of grouping to plugins within the "default" group, OR for inserting UDGs into the "masterlist group" "daisy-chain" sequence.  But the experimental evidence is that UDGs have the same level of "priority" as "masterlist groups".  They are "primary" level hierarchy instead of "secondary".  If UDGs (even those consisting of a single "master" file) are added to the "default" group without hierarchy (no daisy-chain but simply "spurred" off the "default" group as "green circle" nodes), then they get moved to the bottom of the "default" group as "overrides" without regard for whether or not their master had previously preceded others in the "default" group; which was not the intent.  If they are "daisy-chained", then they become separate "masterlist" level groups following the "Default" group.  I can now see why it was implemented that way, but the documents don't make that clear.

The problem is apparently that a UDG is not merely a "grouping" of related mods (as implied in the "Editing Plugin Groups" documentation), but also a hierarchical change to the "masterlist" without the same rigor and rationale as that used by the masterlist maintainers.  It appears my mistake is somewhere along the line I got the impression it was a "secondary" rather than "primary" grouping: e.g. sub-groups within the "default" group.  My intent had been to "pull-up" dependents somewhat randomly placed lower due to the date/time stamp on the original file to immediately follow the "primary" merged plugin file of the group.

Now my concern is that "user defined grouping" plugins may be overriding the sorted hierarchy without regard for the "master" relationship with plugins outside of the UDG, with the UDG automatically becoming the arbitrary "winner".  If it doesn't matter, that is one thing.  But automatically making UDGs the override winners seems to be going back to the "everyone wants to be last" problem.

I foresee problems with making UDGs the equivalent of "masterlist groups".  That sort of thing should be requested of the LOOT maintainers so it gets the proper consideration.  Most users don't understand the issues.  Going by my own experience, I don't want that capability.  I want the ability to define sub-groups within the catch-all "default" masterlist group to keep together specific sequences of plugins that can usually be re-positioned within limits without attempting to override other plugins.  I don't want to have to define UDGs of unrelated plugins just so I can daisy-chain the other plugins in the "default" group (attempting to leave it empty) around my "merge plugin" UDGs. 

I think UDGs are a great idea, but not at the same level as the "masterlist groups".  Better as sub-groups of masterlist groups.

-Dubious-

Link to comment
Share on other sites

  • 2 weeks later...

A couple of weeks late replying to these, but better late than never!

On 8/17/2018 at 11:33 PM, Vyxenne said:

Hi, Wrinkly, hope all is going well for you!

Using LOOT Version 0.13.1 (build fc664279)  and it's working fine. The reason for this post is to let you know of a small QOL issue that you might want to look at: whenever I'm in the Game dropdown (the one where I choose which game to sort plugins for) the cursor changes to an I-Beam as I mouse over the game names, instead of the expected finger-pointing-hand icon. Normally, the I-beam means whatever it's on is not clickable, is not a link. So in this small way, LOOT is being deceptive, or at least less helpful to work with than it could be. I tried to get a screenshot to illustrate this, but my PrintScrn control is apparently set to NOT show the mouser cursor and I don't know how to fix that.

Thanks again for your work on this- I have no idea how we would be able to run 200+ plugins in our games without this essential tool. :wub:

Filed as loot/loot#1001, thanks.

On 8/18/2018 at 3:52 AM, Dubious said:

Re: LOOT Groups.

Sorry for the delayed response.  I had to step back and think over your questions, and check some of my initial assumptions.  One is that I have only been using LOOT with games that use the "Gamebryo" engine (Oblivion and Fallout New Vegas).  That has afforded me the luxury of ignoring the difficulties Skyrim and other "Creation Engine" games have brought to LOOT's table.  So, while the basics are still there I needed to re-learn how those differences impacted LOOT by reading the "Introduction to Load Orders" article.  (Nice article on the differences.  Doesn't seem to be linked into the "Application Documentation" though.)

However, the topic of how "Masterlist Groups" are applied is not covered (or I failed to find it) in the "Application Documentation".  Without attempting to dig into either the code or the instructions for maintaining the "masterlist", the "abstract picture" I perceived from the existing documentation runs as follows:

1. Plugins are loaded in current "load order" (meaning in date/time stamp sequence for Gamebryo engine games).
2. Master/dependency relationships are determined from the plugin headers.
3. Game and DLC masters are sorted to the top (lowest mod index) positions in dependency order.
3a.  Where dependency of "master" files is not related, they ''probably'' remain in timestamp or original load order.
4. Other "masters" are sorted to follow the "DLCs".
5. Probably the "dependencies" are then allowed to remain in the orginal load order sequence as they were encountered.
6. "Masterlist" groups are applied to both "masters" and "dependents".  (How is not explained.  The following are suppositions.)
6a. Presumably the "Master" mod-index position ordering relative to other "masters" is maintained.
6b. Dependents are checked to determine they do not violate other "master-dependent" relationships and then "masterlist groups" use their meta-data criteria (e.g. "load after") to place them after their "master" within the placement for that "masterlist group.
6c. Where there is no meta-data affecting their sequence, the master files remain in load order sequence.
6d. "Masterlist groups" follow the hierarchy of the "daisy-chain" links shown in the "Edit Groups" diagram.  (How this is applied is not known to me, and generally not considered important for user understanding.  It is only with the introduction of "user defined groups" (UDGs) that it appears to matter.)  These "masterlist groups" are generally categorized as "early", "mid", and "late" loading groups, with "default" group apparently determining the "mid" point.
7. All plugins which do not fall into any other "masterlist group" are placed in the "default" group in the sequence they appear in the load order after sorting for "master-dependency" relationships.  It was stated on the forum that "all plugins must belong to a group", which had been an unspoken assumption in the "Editing Plugin Groups" documentation which should be added and emphasized.  The "default" group is in the "mid" category of "masterlist groups".
8. Where needed, date/time stamps or "plugins.txt" files are updated.

The old "priorities" system appeared to have been a way of imposing a "secondary hierarchy" on the "default" group of plugins.  (This may have been another point where the "abstract picture" breaks down.  If the older priorities could override the "masterlist groups", I never tried to discovered it as I only used it with what appears to now be called the "Dynamic Patches" group: e.g. "TES5Merged Patch", "Bashed Patch", and "Override Patch" files to force them to load last in the correct order.)

Following the "rule of one" principle I have developed the habit of adding new plugins to my load order as near the top (low mod-index) as seemed practical (e.g. just below "unofficial patches"), and letting LOOT sort them down to the highest necessary override position as a solution to the "every author wants to load their plugin last so it wins" problem.  I've learned I can safely make some adjustments to the sorted sequence as long as I respect LOOT insisting that certain plugins follow others.  This permitted me to "group" plugins in contiguous sequence which could then be combined into a "merge plugin".  But it often meant that I had to split some logical groupings into more than one sub-group in order to respect LOOT's insistence.  (For example, I have four "Fixes" merged plugins for that very reason: LOOT wouldn't let them sit together.  One of them has combined 20 individual plugins.)

It initially appeared to me that the addition of UDGs were adding a "secondary" level of grouping to plugins within the "default" group, OR for inserting UDGs into the "masterlist group" "daisy-chain" sequence.  But the experimental evidence is that UDGs have the same level of "priority" as "masterlist groups".  They are "primary" level hierarchy instead of "secondary".  If UDGs (even those consisting of a single "master" file) are added to the "default" group without hierarchy (no daisy-chain but simply "spurred" off the "default" group as "green circle" nodes), then they get moved to the bottom of the "default" group as "overrides" without regard for whether or not their master had previously preceded others in the "default" group; which was not the intent.  If they are "daisy-chained", then they become separate "masterlist" level groups following the "Default" group.  I can now see why it was implemented that way, but the documents don't make that clear.

The problem is apparently that a UDG is not merely a "grouping" of related mods (as implied in the "Editing Plugin Groups" documentation), but also a hierarchical change to the "masterlist" without the same rigor and rationale as that used by the masterlist maintainers.  It appears my mistake is somewhere along the line I got the impression it was a "secondary" rather than "primary" grouping: e.g. sub-groups within the "default" group.  My intent had been to "pull-up" dependents somewhat randomly placed lower due to the date/time stamp on the original file to immediately follow the "primary" merged plugin file of the group.

Now my concern is that "user defined grouping" plugins may be overriding the sorted hierarchy without regard for the "master" relationship with plugins outside of the UDG, with the UDG automatically becoming the arbitrary "winner".  If it doesn't matter, that is one thing.  But automatically making UDGs the override winners seems to be going back to the "everyone wants to be last" problem.

I foresee problems with making UDGs the equivalent of "masterlist groups".  That sort of thing should be requested of the LOOT maintainers so it gets the proper consideration.  Most users don't understand the issues.  Going by my own experience, I don't want that capability.  I want the ability to define sub-groups within the catch-all "default" masterlist group to keep together specific sequences of plugins that can usually be re-positioned within limits without attempting to override other plugins.  I don't want to have to define UDGs of unrelated plugins just so I can daisy-chain the other plugins in the "default" group (attempting to leave it empty) around my "merge plugin" UDGs. 

I think UDGs are a great idea, but not at the same level as the "masterlist groups".  Better as sub-groups of masterlist groups.

-Dubious-

Thanks for the detailed breakdown, it seems that the main points that need improved documentation are:

  • All plugins belong to the default group by default, and only belong to another group if masterlist or user metadata says otherwise.
  • All groups are treated equally, LOOT doesn't distinguish between user-created groups and masterlist groups when sorting.

I don't think I follow your concerns about groups overriding the sorted hierarchy, or them being "override winners". In response to not wanting user-defined groups to be equal to masterlist groups, I'd rather users be given the access to that capability and the choice not to use it, than have them rely on the team making or merging in changes they need into the masterlist. Maybe there needs to be more of a speed bump to say "this is a power feature".

As for sub-groups for sorting groups of plugins within the (for example) default group, that would make things significantly more complicated, and there are design questions that would need to be solved (like how are plugins in the group but not a sub-group positioned?). It's been brought up before but I've yet to see a convincing argument for how they add new capabilities, let alone how those capabilities are worth the cost of the feature.

Link to comment
Share on other sites

Hello.

Updated to 0.13.2, and get some error messages:

- Your installed version of Place Everywhere is not compatible with your version of Fallout 4.

- Failed to check for LOOT updates! You can check your LOOTDebugLog.txt (you can get to it through the main menu) for more information.

Regarding the first error I don' have this mod installed (I've never used it). I've enclosed LOOTDebugLog for the second message.

I had none of these messages with 0.13.1.

LOOTDebugLog.txt

Link to comment
Share on other sites

58 minutes ago, Geir said:

Hello.

Updated to 0.13.2, and get some error messages:

- Your installed version of Place Everywhere is not compatible with your version of Fallout 4.

- Failed to check for LOOT updates! You can check your LOOTDebugLog.txt (you can get to it through the main menu) for more information.

Regarding the first error I don' have this mod installed (I've never used it). I've enclosed LOOTDebugLog for the second message.

I had none of these messages with 0.13.1.

LOOTDebugLog.txt

The first looks related to @Freso 's changes, I'm already looking into the second.

Link to comment
Share on other sites

Muy buenas,

Me pasa lo mismo que a "Geir" y a "WrinklyNinja" 

¿Alguien puede solucionar esto? Aunque no noto ningún problema en el funcionamiento de LOOT, ese mensaje inicial en "rojo alarma" resulta molesto. 

Link to comment
Share on other sites

23 minutes ago, Nightmore666 said:

Muy buenas,

Me pasa lo mismo que a "Geir" y a "WrinklyNinja" 

¿Alguien puede solucionar esto? Aunque no noto ningún problema en el funcionamiento de LOOT, ese mensaje inicial en "rojo alarma" resulta molesto. 

The Place Everywhere issue should be fixed in the latest masterlist, and I've just released LOOT v0.13.3 with a fix for the update checker.

Link to comment
Share on other sites

41 minutes ago, WrinklyNinja said:

The Place Everywhere issue should be fixed in the latest masterlist, and I've just released LOOT v0.13.3 with a fix for the update checker.

I installed 0.13.3 now, and the issues are gone. Thank you.

Link to comment
Share on other sites

  • 2 weeks later...

Hi guys,

I have been using LOOT since its birth (I used BOSS before) and he has always handled very well my severely modified Skyrim installation with more than 800 active mods and more than 200 merged and modified .esp files.

Some days ago I ve installed the latest version 0.13.3 and since then I have an unexpected issue that not modifies the good work of LOOT but annoys me a bit: All of my 40 .ghost files  generated by Wrye Bash appears as invalid whit the warning " LOOT has detected that "xxxxxxxxx.esp.ghost" is invalid and is now ignoring it. It's important? Can I forget the warnings and work as if they were not, or it's an previously undetected problem with my installation and should I try to repair it?

Thanks.

 

Link to comment
Share on other sites

10 hours ago, Anidok said:

Hi guys,

I have been using LOOT since its birth (I used BOSS before) and he has always handled very well my severely modified Skyrim installation with more than 800 active mods and more than 200 merged and modified .esp files.

Some days ago I ve installed the latest version 0.13.3 and since then I have an unexpected issue that not modifies the good work of LOOT but annoys me a bit: All of my 40 .ghost files  generated by Wrye Bash appears as invalid whit the warning " LOOT has detected that "xxxxxxxxx.esp.ghost" is invalid and is now ignoring it. It's important? Can I forget the warnings and work as if they were not, or it's an previously undetected problem with my installation and should I try to repair it?

Thanks.

 

It might be a bug, please supply your debug log.

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...