Why LOOT is much better than BOSS ever could be

[RitualClarity]

This one got me until I realised this is FalloutNV DLC not Skyrim Mod

I have a question r/t LOOT.. Yes.. another one.

 

Add: Deflst

 

It is under DeadMoney.esm. It is there after I cleaned the mod as instructed. The others don't have this notation. Want to be sure that I am not missing something that needs to be done.

Thanks.

So I checked FalloutNV MasterList in Notepad++ (Great Text Editor you all should use it inhstead of Windows rubbish one)

As I suspected it has Tag: keyword so is simply a Bashed Patch Tag like Delev and Relev in Skyrim.

 

Wrye Bash in general and Bashed Patch specifically are much better for other games.

Skyrim Developement stalled as Merging with Oblivion became the priority back when SW, arrived.

Both Wrye Bash Team and NMM Team panicked and made rash Knee Jerk reactions to it's appearance.

Skyrim Developement basically ceased for both, as the new directions took over, for both it was a very bad mistake, they've never recovered.

Wrye Bash Team only resumed work on the Skyrim Bashed Patch this year, it is Wrye Bash's main unique feature and should always have been their first priority.

 

So yes, just a Bashed Tag is all, but please mention if you are talking about another game, this is the Skyrim Forum, so some hint helps get your answer.

 

Noted.. Sorry didn't think that it would have confused someone. I just thought the Deflist was all was needed to know what that code was for and didn't think that the game mattered. Will add games used to questions not r/t Skyrim.. Thanks.

[Uhuru N'Uru]

Snipped …

So, you may call me a fanboy now.

LOOT can use all the fan boys it can get, Especially for the older games with less active users, though BOSS MasterList wasn't as out of date for them, due to much less activity, that also makes getting LOOT MasterList upto date harder.

 

 

EDIT: Perhaps I should mention that I'm using Wrye Bash and thanks to that many conflicts can be seen in the install tab and be therefore avoided before they actually occur in the game. I do not use BSA's except for the Unoffiicial Patches because I want to know in advance if any files will conflict. A classic example is "Werewolf Mastery" (comes in a BSA) the werewolf script of which conflicts with the Race Compatibility scripts by TMPhoenix which must be used when you play a custom race. Werewolf mastery must be loaded after that. Just as an example for people who ask themselves why they would want to know which files are inside their BSA's.

I prefer MO's method keep BSA's for size on my SSD but treats contents as if Loose Files.

With any other game they both support WB is a Serious contender for the Title of Best Manager.

My familiarity with MO would likely tip the balance in it's favour for me, the older the game the more the scales tilt to WB, though for Oblivion the last pre merger version has more functionality than the current, it appears to do, at least.

Skyrim though is different as I said above, the Skyrim/Oblivion merger was a huge mistake, that WB is still second to MO and near enough, that familiarity alone can tip the balance in it's favour, shows just how good it was once and can be again.

Not many programs can stagnate as long as WB did and still compete with the best, STEP only switched to MO from WB last October, the admins all Long Term WB users finally switched to MO with regret, and about a year later than honest assesment indicated was the right time to change and provide the new modular STEP Guide with the Multiple Profile Serious Testing manager it required.

MO is for SSD's undeniably more efficient and size concious, when combined with the total lack of developement for WB there was no other reasonable choice.

This year, Lo Jack one of the main WB Devs returned and the Bashed Patch is getting worked on, there is yet hope that this giant among mods can rise up once more.

But back to topic: LOOT of course cannot do the job of giving you a stable game all on its own. The combination of

 

- Wrye Bash, Mod Organizer or any mod manager that shows you conflicting files before you even install the mods - avoid crap like NMM because it's doing everything behind a GUI that leaves you with no clue as to which files exactly are conflicting.

Totally agree that NMM is total shit that will totally burn your Skyrim and it is far superior to SW wether you choose MO or WB used correctly your game is in safe hands.

MO users can also use WB and do, most just for the Bashed Patch, it's just another tool to be used.

 

- The SkSE v1.7 with the memory patch

Little extra: To clean unregistered update events automatically at every game start, add this to \Data\SKSE\skse.ini:

 

[General]

ClearInvalidRegistrations=1

 

If you don't have an skse.ini, create a new text file and name it "skse.ini".

 

The ClearInvalidRegistrations-command is 100 % safe for work. It does not work miracles and functions only in the long run (so having that in the skse.ini is quite reasonable), but is one little step further towards a stable Skyrim gameplay.

 

- The Unofficial Patches Series

Unofficial Patch Project Team's Unofficial Skyrim Patch - USkP

Unofficial Patch Project Team's Unofficial Hearthfire Patch - UHfP

 

Unofficial Patch Project Team's Unofficial Dawnguard Patch - UDgP

 

Unofficial Patch Project Team's Unofficial Dragonborn Patch - UDbP

 

Unofficial Patch Project Team's Unofficial High Resolution Patch - UHRP

- Wrinkly Ninja's LOOT

 

- ElminsterAU's TES5Edit Updated for Skyrim by Hlp, Zilav and Sharlikran and using it to clean your ESM / ESP files - tutorials are on the site there

 

- FlexCreator's Savegame Script Scalpel - Disassembler - Diagnostic Tool - Papyrus Data Transfer - use it with brain 1.0 activated

This may become the most useful but Author has a prior attempt, he does apprear genuine, this has much potential

- The Safely working Hadoram's Save Game Script Cleaner use it with brain 1.0 activated as well.

There have been several other programs of that kind in the past that were more or less risky, this one is very reliable as long as you do the basic cleaning only and leave all other functions of this tool alone. Read the mod description page!

Really must emphasize both these are new, still haven't been completely assessed and can destroy your saves, always make back ups and RTFM First.

The biggest problem can be users use these sort of tools then blame other mods for things they caused by using these things wrongly and unsafely.

Finally I must here strongly disagree, Brain v1.0 is obsolete and actually a known menace, get the latest up to date version Brain v2.4

Last minute update a serious security flaw has been found in Brain v2.4 a hotfix update has been released

Brain v2.4.0000001

 

- Mikanoshi's Skyrim Mods Complex Optimizer - SMCO to optimize textures of mods (you wouldn't believe how many unnecessarily bloated textures are hidden in BSA's or come in loose files which are not Hi Res or so, they are just in the wrong compression formats, completely uncompressed or with unnecessessary alpha cannels and whatnot).

Use this

My understanding is this is a Mass Tool, it does all or nothing, I may be wrong this is just reading from the description.

 

Ethatron's BSAopt - Bethesda Archive Management and Optimization

to unpack BSA's. I haven't used it for BSA optimization because I avoid BSA's wherever I can, therefore I cannot say if that function can be recommended.

Actually, This is the wrong tool I to compare, it is purely for BSA Extraction and Compression and does that job very well. Textures it does nothing to, however it has a related Tool, that is for Teture Optimizing.

Ethatron's DDSopt - Optimization of DDS Textures

This is the preferred Tool used by both STEP and Myself, it does everything BSAOpt does and Texture optimizing, it appeares more versatile just optimizing the files you tell it to do, working on the files one at a time giving more control. All in one go seems easier, not all textures need optimizing some are optimized by the authors and reoptimizing actually makes things worse, SMCO has an exclusion list, but that needs constant updates which it's not getting, it also appeares to exclude the Vanilla files completely, they do need optimizing. I use this, but do not know SMCO well enough to say it's worse, I just took the STEP advice.

Use This Make your own assesment, your own choice.

 

STEP generally uses the best available tools and they do not have favourites, if a new tool appears they actually rigorously test for what's best.

With the usual caveat, as always there are never enough mod users willing to actually help, to test everything.

 

Guide:BSA Extraction and Optimization - S.T.E.P. Project Wiki

 

Guide:DDSopt - S.T.E.P. Project Wiki

These two Wiki Guides cover the subject in great detail, with links to further analysis.

 

Whether you use the Main STEP Guide or not. The Site is the best place I know to get unbiased facts and advice on all aspects of modding, but especially it is the only general site I know that discusses in great depth how to get mods to run well together, providing advice from basic to the most advanced, I especially recommend

 

Skyrim Revisited - Legendary Edition (A STEP hosted mod guide created and maintained by Neovalen) - S.T.E.P. Project Wiki

 

The most technical and thorough Modding guide I've ever seen, it's currently being rewritten in a post Sheson form. Pre sheson it stablized a heavily modded Skyrim, when he found the Dual Wield mod he used was made obsolete by Skyrim Update, he made Dual Sheaf Redux for the guide.

Now the issue with most Modding guides is you disagree with Mod Choices, understanably so, tastes differ, the real value of following this guide is the techniques you learn while doing it, those techniques will benefit all your modding fot as long as continue. The same applies to the Main STEP Guide, indeed it is best to Learn STEP's techniques for a solid foundation, the university of Neovalen is built on thaose foundations.

 

This is nothing to do with MO support being there, that benefits both STEP and MO, but they separately stand or fall on their own merits, not each others.

 

Overall you're points are good and advice sound, my comments are more additions than any major disagreement and there's no argueing at all with your final point, it is the ultimate aim of all of us

makes a stable game. Finally.

 

[b3lisario]

While I think LOOT is an improvement over BOSS, I am testing this particular case where I think that BOSS works better than LOOT.

It's just because I don't need to create a rule using BOSS, and now I am forced to do it.

 

 

MODS USED

 

Skyrim.esm

Update.esm

ModB.esp --> unknown

ModA.esp --> unknown

 

I say they are unknown because neither BOOS nor LOOT have these mods in their master lists, and there is no user rule for them (that's what I am testing).

There is a conflict between ModA and ModB, both mods edit the value of the Iron Armor. They have the same masters.

- ModA.esp contains:

00012E49 ArmorIronCuirass --> value 0

0003619E ArmorLeatherCuirass --> random edit

- ModB.esp contains:

00012E49 ArmorIronCuirass --> value 1000

0001396B ArmorDaedricCuirass --> random edit

 

INITIAL LOAD ORDER

 

I made this load order with Wrye Bash because I prefer the edit done to Iron Armor by ModA:

Skyrim, Update, ModB, ModA

I am checking the AppData/Local/Skyrim/plugins.txt file.

 

RUNNING BOSS

 

Expected result: Skyrim, Update, ModB, modA

Actual result: Skyrim, Update, ModB, ModA

 

BOSS ignores unknown mods, doesn't sort them. OK

 

RUNNING LOOT

 

Expected result: Skyrim, Update, ModB, ModA

Actual result: Skyrim, Update, ModA, ModB

 

LOOT knows there is a conflict between ModA and ModB. There is an option "Show only conflicting plugins" that shows ModA, ModB and Skyrim.esm

In this case ModA and ModB were correctly sorted and LOOT broke that without even a warning...

 

ADDITIONAL TESTS

 

- In ModA, ArmorIronCuirass, change value 0 to value 10000. There is no change in load order.

- Rename ModA to ModC. Now the load order is Skyrim, Update, ModB, ModC (alphabetically again)

 

CONCLUSION

 

In case of conflict, with no user rules, LOOT sorts "unknown" mods alphabetically, instead of preserving their load order.

 

Maybe it is something in my end. If not, this could be a bug

ModA.esp

ModB.esp

[love this game 1993]

Least loot is more stable then boss and it doesn't open up a web browser like boss does 

[Uhuru N'Uru]

While I think LOOT is an improvement over BOSS, I am testing this particular case where I think that BOSS works better than LOOT.

It's just because I don't need to create a rule using BOSS, and now I am forced to do it.

 

 

MODS USED

 

Skyrim.esm

Update.esm

ModB.esp --> unknown

ModA.esp --> unknown

 

I say they are unknown because neither BOOS nor LOOT have these mods in their master lists, and there is no user rule for them (that's what I am testing).

There is a conflict between ModA and ModB, both mods edit the value of the Iron Armor. They have the same masters.

- ModA.esp contains:

00012E49 ArmorIronCuirass --> value 0

0003619E ArmorLeatherCuirass --> random edit

- ModB.esp contains:

00012E49 ArmorIronCuirass --> value 1000

0001396B ArmorDaedricCuirass --> random edit

 

INITIAL LOAD ORDER

 

I made this load order with Wrye Bash because I prefer the edit done to Iron Armor by ModA:

Skyrim, Update, ModB, ModA

I am checking the AppData/Local/Skyrim/plugins.txt file.

 

RUNNING BOSS

 

Expected result: Skyrim, Update, ModB, modA

Actual result: Skyrim, Update, ModB, ModA

 

BOSS ignores unknown mods, doesn't sort them. OK

 

RUNNING LOOT

 

Expected result: Skyrim, Update, ModB, ModA

Actual result: Skyrim, Update, ModA, ModB

 

LOOT knows there is a conflict between ModA and ModB. There is an option "Show only conflicting plugins" that shows ModA, ModB and Skyrim.esm

In this case ModA and ModB were correctly sorted and LOOT broke that without even a warning...

 

ADDITIONAL TESTS

 

- In ModA, ArmorIronCuirass, change value 0 to value 10000. There is no change in load order.

- Rename ModA to ModC. Now the load order is Skyrim, Update, ModB, ModC (alphabetically again)

 

CONCLUSION

 

In case of conflict, with no user rules, LOOT sorts "unknown" mods alphabetically, instead of preserving their load order.

 

Maybe it is something in my end. If not, this could be a bug

No, not unknown to LOOT that's the difference, even if you've just made the plugin and never released it publicly, so only you even know it exists, LOOT will still sort it correctly according to the Master Files it requires.

LOOT knows by actually looking inside, at the File Header to see what are required MasterFiles.

 

Unknown means BOSS has no MasterList entry, so it is not sorting the plugins at all, just dumping them to the bottom of the Load Order, it's not checking for any conflicts at all and never has, so if it's dumping the plugins in an order that suits you it's pure luck, nothing else.

BOSS must have a MasterList Entry to sort plugins at all. BOSS never checks for anything without a MasterList Entry it just ignores all Plugins they remain unsorted and dumped to bottom of the List.

I'm not sure but I think BOSS may just dump to bottom of list in same order the current set up is in, that would make sense to me.

 

You must take all situations into account not just the 4 plugins in your example, it's not a true picture, you know Skyrim.ESM and Update.ESM are 1st and 2nd in the order by Default or by MasterList depending on Manager (with MO the are unmovable by default). so the other two are dumped to bottom of the Load Order, with just the 4 plugins this means nothing at all.

If the were supposed to be 3rd and 4th of 100+ Plugins and were dumped to bottom, even if they kept the relative order between each other, it wouldn't be by design but just luck, not much use to the 100+ plugins that should come after them and now come before,

 

It is totally pointless talking aboutr internal plugin conflicts BOSS knows nothing of these at all, even for plugins with a MasterList Entry.

I don't see how you think it's magically checking conflicts it knows nothing about.

 

Your conclusion is wrong on both counts

1. LOOT sorts Known Plugins, there are no unknown plugins for LOOT, this is the main functionality it has, it knows because it actually looks in each plugin to find out.
2. LOOT does not sort plugins Alphabetically at all, but only by Master Files Requirements it knows exist. It sorts purely by making sure that each Plugin Loads after it's required Masters,
   1. No fancy sorting at all, it doesn't care whether a plugin is directly after the it's last Master or if there are 200+ other plugins between them, just that it's after. That's all that's needed, the requirements are met.
   2. This covers 99.9% of plugins, for the 0.1% of plugins this doesn't work for a MasterList Entry is required and at the moment that's under 300 plugins.
   3. Many more have Bash Tag, Dtirty Edit Entries but they are nothing to do with Load Order, purely an extra benefit.

Yes LOOT tells you plugins conflict but how that conflict is dealt with must be a user choice, that may be

• Compatibility Patch to enable both to function for all mod users
• User edit in LOOT for personal choice.

I understand your apparent issue but the restriction to 4 plugins is masking the real effects, no bugs at all in this situation.

You are looking for something BOSS has no effect on or knowledge of at all and comparing it's supposed but nonexistant effect with LOOT, which knows the conflict exists and alerts the user of its existance, but righly leaves the decision on what to do about it entirely up to each user.

 

I may want the exact opposite result to what you want in any paticular conflict, no program can predict that decision.

Wrye Bash I'm sure doesn't make choices for you even though it alerts you to these conflicts also, why would you expect LOOT to do so.

 

[Edit]

Just Noticed you said you Manually Sorted the Order in Wrye Bash first, how do BOSS or LOOT know this at all ?

[Pinute]

 

While I think LOOT is an improvement over BOSS, I am testing this particular case where I think that BOSS works better than LOOT.

It's just because I don't need to create a rule using BOSS, and now I am forced to do it.

 

 

MODS USED

 

Skyrim.esm

Update.esm

ModB.esp --> unknown

ModA.esp --> unknown

 

I say they are unknown because neither BOOS nor LOOT have these mods in their master lists, and there is no user rule for them (that's what I am testing).

There is a conflict between ModA and ModB, both mods edit the value of the Iron Armor. They have the same masters.

- ModA.esp contains:

00012E49 ArmorIronCuirass --> value 0

0003619E ArmorLeatherCuirass --> random edit

- ModB.esp contains:

00012E49 ArmorIronCuirass --> value 1000

0001396B ArmorDaedricCuirass --> random edit

 

INITIAL LOAD ORDER

 

I made this load order with Wrye Bash because I prefer the edit done to Iron Armor by ModA:

Skyrim, Update, ModB, ModA

I am checking the AppData/Local/Skyrim/plugins.txt file.

 

RUNNING BOSS

 

Expected result: Skyrim, Update, ModB, modA

Actual result: Skyrim, Update, ModB, ModA

 

BOSS ignores unknown mods, doesn't sort them. OK

 

RUNNING LOOT

 

Expected result: Skyrim, Update, ModB, ModA

Actual result: Skyrim, Update, ModA, ModB

 

LOOT knows there is a conflict between ModA and ModB. There is an option "Show only conflicting plugins" that shows ModA, ModB and Skyrim.esm

In this case ModA and ModB were correctly sorted and LOOT broke that without even a warning...

 

ADDITIONAL TESTS

 

- In ModA, ArmorIronCuirass, change value 0 to value 10000. There is no change in load order.

- Rename ModA to ModC. Now the load order is Skyrim, Update, ModB, ModC (alphabetically again)

 

CONCLUSION

 

In case of conflict, with no user rules, LOOT sorts "unknown" mods alphabetically, instead of preserving their load order.

 

Maybe it is something in my end. If not, this could be a bug

No, not unknown to LOOT that's the difference, even if you've just made the plugin and never released it publicly, so only you even know it exists, LOOT will still sort it correctly according to the Master Files it requires.

LOOT knows by actually looking inside, at the File Header to see what are required MasterFiles.

 

Unknown means BOSS has no MasterList entry, so it is not sorting the plugins at all, just dumping them to the bottom of the Load Order, it's not checking for any conflicts at all and never has, so if it's dumping the plugins in an order that suits you it's pure luck, nothing else.

BOSS must have a MasterList Entry to sort plugins at all. BOSS never checks for anything without a MasterList Entry it just ignores all Plugins they remain unsorted and dumped to bottom of the List.

I'm not sure but I think BOSS may just dump to bottom of list in same order the current set up is in, that would make sense to me.

 

You must take all situations into account not just the 4 plugins in your example, it's not a true picture, you know Skyrim.ESM and Update.ESM are 1st and 2nd in the order by Default or by MasterList depending on Manager (with MO the are unmovable by default). so the other two are dumped to bottom of the Load Order, with just the 4 plugins this means nothing at all.

If the were supposed to be 3rd and 4th of 100+ Plugins and were dumped to bottom, even if they kept the relative order between each other, it wouldn't be by design but just luck, not much use to the 100+ plugins that should come after them and now come before,

 

It is totally pointless talking aboutr internal plugin conflicts BOSS knows nothing of these at all, even for plugins with a MasterList Entry.

I don't see how you think it's magically checking conflicts it knows nothing about.

 

Your conclusion is wrong on both counts

1. LOOT sorts Known Plugins, there are no unknown plugins for LOOT, this is the main functionality it has, it knows because it actually looks in each plugin to find out.
2. LOOT does not sort plugins Alphabetically at all, but only by Master Files Requirements it knows exist. It sorts purely by making sure that each Plugin Loads after it's required Masters,
   1. No fancy sorting at all, it doesn't care whether a plugin is directly after the it's last Master or if there are 200+ other plugins between them, just that it's after. That's all that's needed, the requirements are met.
   2. This covers 99.9% of plugins, for the 0.1% of plugins this doesn't work for a MasterList Entry is required and at the moment that's under 300 plugins.
   3. Many more have Bash Tag, Dtirty Edit Entries but they are nothing to do with Load Order, purely an extra benefit.

Yes LOOT tells you plugins conflict but how that conflict is dealt with must be a user choice, that may be

• Compatibility Patch to enable both to function for all mod users
• User edit in LOOT for personal choice.

I understand your apparent issue but the restriction to 4 plugins is masking the real effects, no bugs at all in this situation.

You are looking for something BOSS has no effect on or knowledge of at all and comparing it's supposed but nonexistant effect with LOOT, which knows the conflict exists and alerts the user of its existance, but righly leaves the decision on what to do about it entirely up to each user.

 

I may want the exact opposite result to what you want in any paticular conflict, no program can predict that decision.

Wrye Bash I'm sure doesn't make choices for you even though it alerts you to these conflicts also, why would you expect LOOT to do so.

 

 

You've missed the point entirely. B3lisario is commenting about the sorting done for esp/esms that have no master conflicts. His question, and possible bug report, is that LOOT changes the manual relative placement of mods that don't have conflicting master records. The number of records is irrelevant, the relevant question is why, when there are no master dependency conflicts, does LOOT change the manual relative placement? 

 

If LOOT's authors intent is for these cases to be resolved by otherwise unnecessary patches (the patch is only required because LOOT arbitrarily resorted the manual placement) or requiring your average user to learn to write metadata so be it. 

[b3lisario]

I figured out I can check LOOT source code.

 

The sorting algorithm is pretty complicated lol.

 

If I understand the code, when two mods edit the same record, first are sorted by the number of records overriden by each mod. In case they override the same number of records, they are sorted by name. This of course in case of no user rules, and they have the same masters.

 

That's the AddOverlapEdges() function in this file:

https://github.com/loot/loot/blob/master/src/backend/graph.cpp

 

Line 257:

else if (graph[*vit].Name() < graph[*vit2].Name()) { //There needs to be an edge between the two, but direction cannot be decided using overlap size. Just use names.

"Just use names"

 

So the key here in this case is how many records each mod is modifying. I think the mod that modifies more records gets the priority.

[RitualClarity]

I am getting confused...

 

I don't understand why it is a concern if a mod is listed in alphabetical order or not so long as the masters and general load order is correct. That combined with what b3lisario states that the mods that override the most get the priority seems like a very good general idea for sorting in those cases where the masters are the same amount of records are overridden. There has to be some rules for these situations.

 

That seems to cover 99% of the mods and needs that most people have. If there is one record that needs to be above another which would be lower in the list based on this the mod author could mention it on his / her page and submit a issue to the LOOT team. Advanced individuals like yourselves can make the manual metadata changes if need be for your own personal and private needs. If I understand the steps it is pretty quick to do.

 

As good or bad as a tool like LOOT is I still don't trust it completely to my load orders especially when running more and more complex mods and builds. I never will. It is just a nice tools to get the "majority" of the mods in order. There is an example in a game I am playing now (FNV) one mod just keeps popping up above the other in a wrong order. Fine. I just change it back and start play. Eventually I will attempt to set the manual meta data to get that in the order that I want it to be in.

 

So far for my uses it has been better and more reliable at broad sorting the load orders of my games (more than just Skyrim) than BOSS ever was.

[b3lisario]

Mmmm, when two mods don't override any record they are not sorted by name.

 

Now I am trying to figure out why the load order seems so random in case of no conflicts. It seems a matter of how LOOT is reading the data directory contents.

[RitualClarity]

Finding that out is interesting but it don't seem to matter when I played the game and tested with god only knows how many random mods given at any time. I had to open my old archive folder and grab more. Many aren't even compatible with each other and still tells me what I need to know and makes a pretty good selection of the load order considering. It is strange that it seems to be so random in its processing though..

[b3lisario]

LOOT is using a C++ library called BOOST to read the data contents.

The class it uses is directory_iterator, and the order in which it returns the file entries is unspecified. The entries are probably returned in whatever order the implementor figured would be faster.

So in case of no user rules, masters, masterlist, conflicts, etc, the unspecified order in which the mods are read also determines the load order.

 

https://github.com/loot/loot/blob/master/src/gui/main.cpp

http://www.boost.org/doc/libs/1_49_0/libs/filesystem/v3/doc/reference.html#Class-directory_iterator

http://pubs.opengroup.org/onlinepubs/000095399/functions/readdir_r.html

[b3lisario]

[Edit]

Just Noticed you said you Manually Sorted the Order in Wrye Bash first, how do BOSS or LOOT know this at all ?

They could read the C:/Users/***/AppData/Local/Skyrim/loadorder.txt or plugins.txt file. (AppData is a hidden folder)

 

I guess they do read it. At least BOSS because unknown plugins go to the end of the list in the order they were originally.

If LOOT reads the file, it seems to ignore its contents and just overwrites it.

[Uhuru N'Uru]

Mmmm, when two mods don't override any record they are not sorted by name.

 

Now I am trying to figure out why the load order seems so random in case of no conflicts. It seems a matter of how LOOT is reading the data directory contents.

and

Finding that out is interesting but it don't seem to matter when I played the game and tested with god only knows how many random mods given at any time. I had to open my old archive folder and grab more. Many aren't even compatible with each other and still tells me what I need to know and makes a pretty good selection of the load order considering. It is strange that it seems to be so random in its processing though..

 

Exactly Names are irrelevant, the important thing is for 99.9% of Plugins all that matters is that Required Master Files Load before each Plugin LOOT performs this task automatically and thats all thats required for them.

LOOT MasterList is for the few exceptions to this rule, I think every absolute (applies with all other plugins) exception is already in the MasterList.

The relative exceptions I'm equally sure are not all in MasterList yet, these are what require reporting to LOOT Team and be confirmed, then they are put on MasterList.

What's a relative exception.

Basically where two specific plugins are involved, so to even have the issue you must have both plugins installed in your Load Order, these appear to be mainly if not all Mods with BSA's that contain Scripts which conflict with each other, rarer than you may think at first and as these are not actual loading issues often mod users don't connect the issue with Scripts hidden inside BSA's.

These are legitimate candidates for MasterList Entries only if both Mods are positively Identified.

 

Theoretically with a correct and accurate MasterList, No Mod Issue that occurs in game should ever need to be fixed by adjusting Load Order, most often these are Script Conflicts solvable by Mod Priority/Install Order which is so easily changed with Mod Organizer, being simply a drag and drop matter.

The one advantage Wrye Bash had Left over Mod Organizer was the plugin conflict view, though this was never a real issue, as with Bashed Patch simply starting Wrye Bash with Mod Organizer allows Wrye Bash to see the virtual Data Folder, this is another advantage to Mod Organizer it can avail itself of the best features of other tools and combine with it's Mod Isolation and SSD friendly;

BSA's = Loose for conflict Management but stay as BSA's for size on SSD

Mod Organizer also now warns when conflicted Scripts require Mod Priority/Install Order adjustments to match Load Order of there plugins. This actually eliminates the above BSA script conflict issue which could remove Mod Organizer users from reporting these issues but the alert user can actually use this to aid the reporting simply by checking if the Mods have BSA's or not.

 

Reports are very few so either they are extremely rare or most who have them don't report it, many may just not know, some will though and just fix their own User List, these should make the repoets if the issues actually exist.

 

LOOT is using a C++ library called BOOST to read the data contents.

The class it uses is directory_iterator, and the order in which it returns the file entries is unspecified. The entries are probably returned in whatever order the implementor figured would be faster.

So this also determines the final load order.

 

http://www.boost.org/doc/libs/1_49_0/libs/filesystem/v3/doc/reference.html#Class-directory_iterator

http://pubs.opengroup.org/onlinepubs/000095399/functions/readdir_r.html

I've not delved that deeply into the coding side. So I assume this comes via LOOT site. My basic understanding is it starts with your current order and takes each Plugin one by one reads the Required Plugins from it's header, checks the masterlist (May do MasterList First) then places it in current Order,

onto Next Mod and repeat until done

 

My skill is explaining the practical well enough for ordinary users to understand and technical enough for advanced users to understand at the same time, it makes my post's long and I often repeat the same thing multiple ways.

Anyone who takes the time to read all my posts just in this thread will see that repeating, it's main purpose is to increase understanding.

Simply because by explaining something three different ways, three people may understand just one explanation each, this way all three get the idea.

It works rather well, is a pain to write, but worth the effort.

 

Last thing is I don't know it all, but when I find /am asked something I don't know, I reseach the subject until I find the answer, rarely actuallt asking a question on a forum, I find I learn much more this way, every question I think of has already been asked and I find many answers to questions I never even thought of asking, many answers to questions I would only have asked later on.

 

If you can tear holes in my logic then rip it to shreds, if you find factual errors point them out,  I expect no less and you can be sure I'll do the same to you.

It's simply about learning the truth and providing evidence to back up each fact. I don't take it as a personal attack, the attack is on the information not the person. It only gets personal if you use a big Axe on my Head, that might irritate me a little, just a little though.

[Pinute]

 

If you can tear holes in my logic then rip it to shreds, if you find factual errors point them out,  I expect no less and you can be sure I'll do the same to you.

 

 

It's simply about learning the truth and providing evidence to back up each fact. I don't take it as a personal attack, the attack is on the information not the person. It only gets personal if you use a big Axe on my Head, that might irritate me a little, just a little though.

 

 

Speaking only for myself, don't stop pointing out the advantages of LOOT over BOSS, since they are manifest. However. I recommend that you listen to people who have evidence-based criticisms, like the one B has brought up. I assure you, his comments have been about LOOT and not you or your logic. He has a well earned reputation for humility and courtesy.

 

I think this thread could be concluded with someone offering the suggestion to the LOOT maintainers that they should consider the existing plugins.txt as the default sort, and alter that sort as little as necessary.

 

And, as a personal request, could you kindly reduce the font sizes used in your signature? 

[Uhuru N'Uru]

 

If you can tear holes in my logic then rip it to shreds, if you find factual errors point them out, I expect no less and you can be sure I'll do the same to you.

 

 

It's simply about learning the truth and providing evidence to back up each fact. I don't take it as a personal attack, the attack is on the information not the person. It only gets personal if you use a big Axe on my Head, that might irritate me a little, just a little though.

Speaking only for myself, don't stop pointing out the advantages of LOOT over BOSS, since they are manifest. However. I recommend that you listen to people who have evidence-based criticisms, like the one B has brought up. I assure you, his comments have been about LOOT and not you or your logic. He has a well earned reputation for humility and courtesy.

 

I think this thread could be concluded with someone offering the suggestion to the LOOT maintainers that they should consider the existing plugins.txt as the default sort, and alter that sort as little as necessary.

 

And, as a personal request, could you kindly reduce the font sizes used in your signature?

 

Sorry you Misunderstood That wasn't aimed at B3lisario, I'm Fully aware of his exellent Modding contributions to this site and I have most if not all of them installed in My MO Mods folder, on the contrary though I pointed out what I thought were crucial misunderstandings he was making about how LOOT and BOSS differed, In my previous post I pointed out the fact that he was actually testing things in game in a methodical and scientific manner was commendable.

He never once questioned my factual statements and from the links hes posted it's clear he'd obviosly been on the LOOT site it looks like he checked things for himself, indeed he went delvng into it's guts to see exactly how it was doing the sorting, in his last post putting links to the core tools LOOT uses. I was obviously, so I thought, using him as the sort of example that should be followed, it's not so obvious, apparently

 

All B3lisario's methods are exactly the sort of thing I aim to do myself and recommend to others, this was my intent, maybe it's not as obvious to others as it appears to me, So I apologise for not making it clear, I will do so now It matters not whose right or wrong, that the debate is conducted without malice, but with open and clear points made using known facts and with conviction. In this instance B3lisario's starting assumption was wrong and restricting his test to 4 plugins disguised that fact.

I simply knew more about the specific subject than he did, it doesn't make me superior to him. It could very well be the opposite for the next subject

Knowledge is binary in nature, a fact is known or unknown, we all start off knowing nothing at all.

The first step on the road to wisdom is openly admitting a lack of knowledge and resolving to gain it.

Stupidity is refusing to admit any lack and therefore never learning anything.

 

I think this thread could be concluded with someone offering the suggestion to the LOOT maintainers that they should consider the existing plugins.txt as the default sort, and alter that sort as little as necessary.

This just wont work any better than the existing sorting method as I understand it it basically does this sort of thing already.

Simple Test resorting the same Load Order gives same result, nothings changed at all, thats the only definition of as little as neccessary that counts.

If it was doing uneccassary sorting this would change, exactly what it doesn't do is unessasary sorting.

What people often do is they manually sort things then expect it to somehow know that it's intended to accept those changes, thats the uneccessary sorting it should and must ignore. It cant assume any found order is correct, just because the user thinks it's uneccassary, doesn't make it true.

You want to make user edits use LOOT to do them and you can force any order you want.

 

And, as a personal request, could you kindly reduce the font sizes used in your signature? That Better?

I don't think it's bigger than the Images many use and it's much more useful.

[RitualClarity]

 

And, as a personal request, could you kindly reduce the font sizes used in your signature? That Better?

I didnt think it's bigger than the Images many use and it's much more useful.

I don't know about others here but your text clipped badly on my computer browser. It was hard to read. Now it is much easier to read and see.

[Uhuru N'Uru]

 

And, as a personal request, could you kindly reduce the font sizes used in your signature? That Better?

I didnt think it's bigger than the Images many use and it's much more useful.

I don't know about others here but your text clipped badly on my computer browser. It was hard to read. Now it is much easier to read and see.

 

My 3×Monitors are 7680×1440 in Eyefinity Single screen setup though

• 2×Monitors are 5120×1440 are used byFree Comander a two Window Tabbed Explorer replacement which is exellent, in it's own right but also accurateky shows MO Virtual Data Folder if opened by MO
• Leaves the third for Firefox at 2560×1440 and maybe that has some bearing on the Matter
• I seriosly doubt that though, there was very litle as in no vertical separation, which I think is the issue you refer to and changing the size has fixed that, that is purely a forum issue and should not occur at all, I suspect a 0 pixel setting above and below for that specific size.

Anyway as you say it does look better at this size even though it should make no difference.

 

Back to LOOT and why B3lisario's contribution still had great value

Example of why even though B3lisario's Starting Assumption and therefore his whole argument was incorrect, the methods he used were exactly right, I'm not meaning the actual testing, again though perfectly right to test things. Here I specifically mean his posting of his theory in a precise and logical manner.

It made me think and think hard, I wasn't just using my tried and trusted technique of repeating the same anwers in a different way, which as I've said works and very well at that.

B3lisario was asking new questions I'd never been asked before, that got my brain hot and pumping on full cylinders, it always likes a challenge they are what produce new knowledge.

 

Specifically I started thinking about LOOT's conflict reporting ability, I'd not actually thought about this at all, how does it do this, it's not in the MasterList and it's not in the File Header, that makes my current assumptions and explanations invalid and just plain wrong.

I need to fix this, I'm claiming to be an expert on this, actually no I've never claimed that, just that I'm a knowledgable user who as been told by others my explanations have helped expand their knowledge, this has a lot to do with the fact that I actually RTFM.

One thing about RTFM is it's not a one time only deal. To be clear, for simple mods and tools once, if at all, may be enough. With the complicated Mods and Tools once is never enough, the good ones are a reference resource to be returned to, over and over again, LOOT's is a good resource and rereading with a new specific question can shed new light on the process, things can change with updated software.

LOOT's UI is currently being refined and consolidated into one window

See End of post for further Details.

 

So Conflicts How does LOOT deal with them

I've actually been understating LOOT's Technical abilities, as I've said LOOT does check the plugins actual needs by reading the Data direct from the Plugin but it doesn't just read the file header it reads the entire plugins data, all of it.

The exact mechanics it uses are unclear to me as yet, but I now know enough to describe the practical results as far as the end user is concerned and thats all that really matters from a purely user perspective.

It does what TES#Edit does when you run it with all plugins are selected, It analyses the entire package, the difference is while TES#Edit then shows all that Data for editing, LOOT uses it to Sort the LO just as I say it does and present any plugin conflicts to the user to aid them in deciding which ones the user wants to win the conflict.

So actually LOOT is even better than I said it was at providing much more data to the user than BOSS ever could.

 

Summary

• RTFM Often and repeatedly for Complex mods and tools like LOOT, especially to find the answer to a specific question. You will;
• Learn something new.
• Correct a misunderstood aspect.
• Improve your understanding
• Reconfirm your current knowledge is still accurate.
• My recent debate with B3lisario, highlighted hear, shows that even when you know the core assumption is wrong and the entire theory because of that assumption, by still reading carefully the substance of that theory valuable insights can still be made, when sound principles are used as the basis for the theory.
• LOOT reads the entire plugin contents in essence the same way TES#Edit does, whether the method used is exactly the same I don't know, but that is irrelevant to the end result as seen by the user, so for understanding LOOT's abilities.
• LOOT reads plugins just like TES#Edit does !

The subject of exactly how LOOT chooses which plugin to use first eludes me for now, I suspect it's actually a lot more complex than it may appear and more than one factor is involved, I'm still working on this one and when I have a satisfactory answer I will post it.

Re-editing the OP is likely to be required as just cutting and pasting additions as the knowledge is refined and added to, is making the the OP rather big and unfocused, actually redoing it though will take some time and I want to get the sorting details right first.

 

 

▁▁▁▁▃▃▃▃▅▅▅▅▇▇▇▇████████▅▅▅▅████████▇▇▇▇▅▅▅▅▃▃▃▃▁▁▁▁

LOOT's UI is currently being refined and consolidated into one window

 

Therre is a working example

I have started to put together the new UI in the gh-pages branch (so a live view is available here). Actually tying the UI to a C++ backend is part of issues #134, #135 though.

 

UI Feature Implementation

 

 

Still to be implemented

• Message dialogs: Need title, content strings and type (error, info, question)
  • Redate plugins question
  • Redate plugins completition
  • Remove plugin metadata question
  • Remove all metadata question
• Editable Multi-column lists (ie. tables)
  • game list (settings)
  • incompatibilities list (editor)
  • requirements list (editor)
  • load after list (editor)
  • Bash Tags list (editor)
  • message list (editor)
  • dirty info list (editor)
• Filters display
• Editor panel
• Game list display
• Messages display
• Update Masterlist button highlighting if an update is available.
• Sort button highlighting if differences since last sort are detected (including no last sort).
• Current section highlighting (like GitHub Guides have, for example)
• Some sort of highlighting of master files, eg. bolding filenames in the sidebar? Requested by a few users.
• Drag 'n' drop into editor tables
• Plugin priority display
• Some sort of overlay / partial UI freeze while editing
• Correct button functionality for settings dialog
• Validation of table content on editor / settings exit.
• Conflict filter

 

Intentionally Non-Functional Items

 

• Masterlist Update button
• Sort button
• Saving of settings
• Saving of edits
• File menu buttons (Redate Plugins, Open Debug Log Location, Clear All User Metadata - the first and last have UI feedback)
• Game selection
• Help -> Help button
• Copy Metadata As Text
• Clear User Metadata (has UI feedback)

 

The Full Topic can be found here but be fully aware this is unreleased still in developement Work in Progress and may never be implemented, though that's unlikely it may end up looking completely different to this also.

GUI Redesign · Issue #132 · loot/loot · GitHub

 

▁▁▁▁▃▃▃▃▅▅▅▅▇▇▇▇████████▅▅▅▅████████▇▇▇▇▅▅▅▅▃▃▃▃▁▁▁▁

Finally

My real mistake in this post, not having a blatant and obvious example of why you should use MO. So this time I can only say you must use MO because I say so.

I will not provide MO support to anyone who doesn't use MO, therefore you must use MO because you must want my support, The Logic of that is circular and cyclic so you've simply no choice, you are surrounded by my unsound and unsafe Logic, so to be sound and safe in Skyrim you must use MO.

Note on finally:

Confused by that, then you need MO, consider that an order not a request.

Understand all that, then you're smart enough to know there is no other viable choice, you must already use MO.

[b3lisario]

...

In this instance B3lisario's starting assumption was wrong and restricting his test to 4 plugins disguised that fact.

...

LOL no. Using 4 plugins just made easier to prove the alphabetical sort in certain circumstances.

Why don't you test it by yourself? Download both mods from http://www.loverslab.com/topic/31389-why-loot-is-much-better-than-boss-ever-could-be/?p=792339, put them in your data folder with other 200 mods and run LOOT. Both plugins will sort alphabetically no matter what. You may rename them, and then they will sort alphabetically again. You can create 20 copies of those two mods and they all will sort alphabetically.

Proof:

 

 

 

In case of plugin conflict (two or more plugins that override the same record), their relative order is:

- the plugin that overrides more records win (it may be just the opposite, not sure)

- in case of they override the exact number of records, they are sorted alphabetically

 

I've been looking at the LOOT source code and I have more info about two subjects.

 

- Does LOOT actually read C:\Users\***\AppData\Local\Skyrim\loadorder.txt? It reads plugins.txt and loadorder.txt to know if a mod is active or not, but it doesn't use the position the mods have in loadorder.txt

 

- How exactly random is the resulting load order?

 

As Uhuru N'Uru said it's not 100% random because you always get the same order each time you run LOOT. LOOT reads the data folder, and stores the plugins in an unordered map, which I think is a container that "unorders" the stuff you put in there based on a hash function applied to the name of the mod. This means that if you rename a mod that you know it doesn't get sorted by any particular reason you may see it changing its position in the final load order.

As somebody said it doesn't matter how the non-conflicting mods are ordered, it doesn't affect the game. Is just ugly.

 

Source:

https://github.com/loot/loot/blob/master/src/gui/main.cpp function OnSortPlugins

http://en.wikipedia.org/wiki/Hash_function

http://svn.boost.org/svn/boost/trunk/boost/functional/hash/hash.hpp

[Uhuru N'Uru]

[Edit] Removed for Size reasons it was a copy of the above post placed here because often other posts are made while I write a respnse.

That has not occurred this time

Snip…

As somebody said it doesn't matter how the non-conflicting mods are ordered, it doesn't affect the game …Snip

That was me as well, though I may not be the only one

No, I don't believe I need to actually test the plugins, the evidence you show is pefectly clear, I accept your findings and given the conditions you specify for such plugins alphabetical is a logical way which was also used for BOSS MasterList when plugins were in same group, we appear to have posted within minutes of each other so I will assume you hadn't seen my last post in which I stated I wasn't sure of even the principles used for deciding the sorting and it required more research.

You've done some of that research and having seen your thoroughness, I'm confident enough to assume it's correct unless I find evidence otherwise.

 

I've always been talking about the general case and your original statement you conclusion

CONCLUSION

In case of conflict, with no user rules, LOOT sorts "unknown" mods alphabetically, instead of preserving their load order.

 

Maybe it is something in my end. If not, this could be a bug

was wrong on both counts as written this is what I said is not sorted Alphabetically

 

I now know the meaning you intended to convey, the Number of plugins used in the second example and the qualifying statement "the same Conflict" have focused things on exactly what this first statement was meant to convey.

 

Basically you were talking about a specific and very narrowly defined situation.

I was talking about the general and widely defined situation.

It was obscured further by your incorrect assumption LOOT had unknown plugins, which is just a know / Don't Know issue and as I've posted we all start out knowing Nothing.

 

Still my view is that alphabeticly sorting the identical conflicting yet otherwise equal plugins is the only logical solution for LOOT to use, in the wild they won't occur too often, LOOT provides a Mechanism for user settings to decide these conflicts, so if you are using LOOT it must assume you are using this method to control these issues, which are in the end purely a matter of user choice.

I believe only Wrye Bash actually shows these conflicts and can thus be used to manage them independantly.

LOOT cannot predict your manager choice and must work the same for all managers regardless, so basically using LOOT to manage these conflicts is entirely best even for WryeBash users.

 

Damn good work by the way, your second Post makes the real issues, which you tried to convey in the first, crystal clear .

 

Now I need to get this this sorting stuff clear in my head for the general case, your research will make that much easier, I've still got to check it out though.

 

[Edit] The First Post while it potentially (Fulfilled by 2nd) showed the same result, didn't do so. Only having 2 sample plugins (2 game ones not involved) added to the Lack of knowledge B3lisario had, as to how LOOT worked, combined with what conclusion quoted above stated. This meant the post did not prove his theory as intended and I misunderstood that intention as well.

B3lisario shows the proper response to my critisism, he gained the knowledge he lacked. He now knows more than I about, exactly how LOOT does what it does, my focus has been on the end user experience, rather than it's internal processes. He improved his experiment in and clearly showed the result. That led to me realising the remaining mutual misunderstanding and now we have a clear and correct report fully understood.

His conduct in this debate has been exemplary, correcting mistakes (By both of us) with patient and reasoned logical argument resulting in a better understanding by all, I compliment him and his example is one all should endeavour to follow.

[End Edit]

 

 

Question. You state making 20 identical plugins sorts alphabetically as the example shows.

Have you tested a number (doesn't have to be twenty but greater than 2 is desirable) of different plugins that have conflicting but different edits.

I expect the same result, but confirmation from experiment is always good.

 

[Edit] In B3lisario's original post he was comparing LOOT's treatment of unknown Plugins with BOSS's treatment of unknown plugins and stating BOSS's method was betterr.

LOOT has no unknown Plugins so the argument was invalid, as Like was not compared with Like. It's has occured to me that we never went on to actualy compare Like with Like.

Namely the situation if the Plugins are known by BOSS as they are always known by LOOT.

In this situation the plugins are only different by Name and the conflicting edit, the experiment was designed that way to eliminate any other influence.

This doesn't really matter because it's been established for LOOT to sort conflicting plugins alphabetically all othe factors must be equal.

Which means they have identical Master Files and the same one or more conflicting edits, so what does BOSS do in such situations.

 

Well it ignores the conflicting edits completely, it takes absolutely no account of them.

Having known identical Master files they would be placed in the same MasterList Group.

Every plugin in the same MasterList Group is sorted alphabetically.

So BOSS does the same as LOOT with known plugins, even though it actually ignores all conflicts completely.

 

Indeed many complaints about LOOT have been because it doesn't do this general alphabetic sorting because, it's ugly and not neat.

Totally ignoring the fact that BOSS's A-Z habit was to make the MasterList Editor's job easier, no other reason at all, definately not to be neat and pretty.

[fejeena]

I tried LOOT, laughed, and installed it.

Tried it with Oblivion.

A Map Mod that must be after any Mod that change a world cell ( or the new Map does not work) was sorted above many other Mods with world cells. 

And Lovers with PK was one of the first esp and direct after

LoversMB2.esp
Lovers3dorgasmMB2.esp
LoversIdleAnimsPriority.esp
Lovers3dorgasm.esp
LoversAnimObjectsPriority.esp

And after that, distributed over the whole load order, the other Lovers Mods. All Lovers Mods loaded after LoversIdleAnimsPriority.esp and LoversAnimObjectsPriority.esp can not work right.

 

So it was fun, but completely unusable. Perhaps in some years the Programm is as good as BOSS.

 

[Uhuru N'Uru]

I tried LOOT, laughed, and installed it.

Tried it with Oblivion.

A Map Mod that must be after any Mod that change a world cell ( or the new Map does not work) was sorted above many other Mods with world cells. 

And Lovers with PK was one of the first esp and direct after

LoversMB2.esp

Lovers3dorgasmMB2.esp

LoversIdleAnimsPriority.esp

Lovers3dorgasm.esp

LoversAnimObjectsPriority.esp

And after that, distributed over the whole load order, the other Lovers Mods. All Lovers Mods loaded after LoversIdleAnimsPriority.esp and LoversAnimObjectsPriority.esp can not work right.

 

So it was fun, but completely unusable. Perhaps in some years the Programm is as good as BOSS.

Actually it's Much better than BOSS

LOOT actually Reads each Plugin and sees exactly what the Mods Requirements are much Like what TES#Edit does when you run it with all plugins checked, for 99.9% of mods that's enough to sort them perfectly fine.

I know Skyrim and currently under 300 plugins actually require a MasterList entry to adjust their position due to unusual factors this analysis can't account for, that's out of approximately 100,000 plugins made (conservative estimate). The only outstanding ones left, if any exist, are rare script conflicts between pairs of mods not often used together.

Oblivion will be no different, the thing is the 0.1% of specials requre reporting to be added to the MasterList. Skyrim has many users but very Few who report any problems, still enough to have it running.

Oblivion has very few users and report makers may not even exist at all

Map changing plugins are not the very last thing in Oblivion MasterList, it says in the comments

# any map changing files esp have to go dead last

# These should never be in the active load order.

Then a number of plugins for this very final category

No map changing plugins are listed at all, this either means LOOT is sorting these ok already or if it's not then no one is roporting the ones that do need a special entry.

 

Though I have no real idea as to the current state of oblivion LOOT and the BOSS MasterList was not likely to be overwhelmed like Skyrim, BOSS will cease to be supported sooner or later.

 

Your reaction is one many using Skyrim had at the start, when they actually tried the game many were very surprised that the game ran fine, so give it a try even if you think it won't work. report anything that actually fails. It's all thats needed in the end.

Most of the things you may think look wrong, actually are not, just unfamiliar. How many actually Need MasterList entries that have none is the unknown factor.

[RitualClarity]

With lovers there probably are quite a few master list modifications that need to be made. When I used Oblivion before I used the same sense I used before on other games (FNV FO3 etc. ) check the masters required and just make sure that they fall in compliance with this. When I tried lovers.. that just didn't work. If you didn't follow the load order suggestions many of the mods wouldn't work properly if they worked at all.

[Pinute]

LOOT seems to have worked pretty damned well on Neovalen's SR:LE. Figured it might, since every objection I had were about corner cases. 

 

I haven't looked at every record conflict yet, but after checking for the obvious stuff (like dragonborn esps being sorted above vanilla ones!) so far I haven't found any mis-ordered edits. My totally ideosyncratic npc edit (a mashup of decent feminine women and ethereal elven overhaul with some of falmerbarnes designs) got placed properly!

 

 

[Prometeus5879]

I tried LOOT, laughed, and installed it.

Tried it with Oblivion.

A Map Mod that must be after any Mod that change a world cell ( or the new Map does not work) was sorted above many other Mods with world cells. 

And Lovers with PK was one of the first esp and direct after

LoversMB2.esp

Lovers3dorgasmMB2.esp

LoversIdleAnimsPriority.esp

Lovers3dorgasm.esp

LoversAnimObjectsPriority.esp

And after that, distributed over the whole load order, the other Lovers Mods. All Lovers Mods loaded after LoversIdleAnimsPriority.esp and LoversAnimObjectsPriority.esp can not work right.

 

So it was fun, but completely unusable. Perhaps in some years the Programm is as good as BOSS.

 

I've just tested LOOT with skyrim and the results were highly unpredictable.

 

Issues that I've noticed:

 

- HTD phisics not applied to armor anymore (generated by bodyslide)

- Changes mods make to NPC's only partialy applied (one npc ok, the other vannila state)

- Armor replacers not applied or only partial

- ...

 

I've started with a new game so no saved game conflicts could influence the test. Initialization messages of mods not showing was already a hint that it wouldn't be ok.

 

Went back to BOSS restarted a new game and everything is back to normal.

 

So my conclusion is that LOOT isn't ready to replace BOSS yet as Fejeena also concluded.

 

While I can understand that changes of a mod not being shown in the game at all can be due to load order not being optimized, what worries me more is what LOOT does with those mods where the changes are partialy visible and the rest is reversed to vanilla state. 

[Uhuru N'Uru]

What worries me is you think that a valid and fair test,

New Game started with existing Mod List, Already pre-organised using BOSS with Many user Edits and or BUM used, must be so as a virgin BOSS run would move many unknown mods to Bottom of the List causing much more issues than a virgin LOOT run would.

So you Compare LOOT's first run with a well ordered and previously managed BOSS run. 

Of course BOSS had no issues you'd fixed all them prior to the Test even starting.

New game only eliminated irrelevant savegame issues, which assuming your save loads, would not matter.

Blaming in game issues that in all liklihood have nothing to do with LO just because you see them means nothing without knowing the exact cause

 

Delete all the BOSS user edits let it move all unknown mods to the Bottom of the List, then try and see which is worse.

Testing both under the same conditions is just the starting point for valid testing, you never even started.

 

Your test proves only that you do not know how to test.

 

Read OP also about how in game issues are rarely anything to do with LO, those few that are, Namely from BSA's with Scripts, but only if conflicting with another BSA script, are valid MasterList entries for LOOT, which relies on users reporting the issues to put them in MasterList to begin with. Very few so far confirmed reports suggest rarity.