[RELz] LOOT - Load Order Optimisation Tool

[pek2000]

I have an odd problem, I clicked on the link in LOOT, not sure if this is the right place.  Every time I run LOOT for FO4, I have to apply changes.  Even back-to-back sorting I get the "Apply" button, so I guess something is screwed up, but I can't figure out what it going on.

[HylianSteel]

7 hours ago, pek2000 said:

I have an odd problem, I clicked on the link in LOOT, not sure if this is the right place.  Every time I run LOOT for FO4, I have to apply changes.  Even back-to-back sorting I get the "Apply" button, so I guess something is screwed up, but I can't figure out what it going on.

What mod manager do you use?

[pek2000]

NMM, latest release (well, 0.65.2 is what was downloaded, which is the patch, I guess).  Was working after the upgrade for a few days, but then LOOT decided to keep re-applying after the sort.

I uninstalled the last mod I loaded, but LOOT is doing the sort/apply loop.  And, it only does it if I exit LOT and open it again.  If I keep it open and sort, it doesn't apply again.  But if I close LOOT and then open it again, it does the sort/apply thing again.  And i do nothing but open and close LOOT, nothing else.

 

LOOT debug log:

[17:24:44.252162] [warning]: Chromium console message: Styling master document from stylesheets defined in HTML Imports is deprecated, and is planned to be removed in M65, around March 2018. Please refer to https://goo.gl/EGXzpw for possible migration paths.
[17:24:44.302525] [warning]: Blocking load of resource at https://fonts.googleapis.com/css?family=Roboto+Mono:400,700|Roboto:400,300,300italic,400italic,500,500italic,700,700italic

 

[HylianSteel]

18 hours ago, pek2000 said:

NMM, latest release (well, 0.65.2 is what was downloaded, which is the patch, I guess). 

Head here and grab the latest version (0.65.4)

Edit: Would also you be okay with completely uninstalling LOOT and deleting it's AppData folder, then fresh installing the newest version if updating NMM doesn't help?

[pek2000]

Sure, no problem, isn't working right, anyway.  I'll update NMM, then remove/install LOOT if that doesn't fix things.

[pek2000]

updating NMM didn't help, deleted the entire loot folder in the nmm floder, installed 0.12.5.  It's like there's a permission issue with a file that won't update, but loot isn't finding the one.  FO4edit runs through the mods with no real errors (lots of 'unused data' errors, but nothing to make it abend).  the game itself loads ok, I think, no visible errors, and it's been pretty picky about mod load order. 

Just loot making the sort/apply loop.

I tried LOOT again after I opened the game, this time the plugins.txt had been set to r/o, but  use f4se to start the game, not steam.  As far as I know, plugins.txt only gets set r/o if the game is started thru steam.  This is getting stranger & stranger.

[pStyl3]

Do you close NMM before running LOOT? If not, try it like this: Close NMM, start LOOT, sort your plugins and apply changes, close LOOT, start NMM.

[pek2000]

still does it, I ran LOOT from the executable in the LOOT directory, never opened nmm.

[pek2000]

Also tried running loot as admin, still no joy.

 

[pStyl3]

Do you have debug logging enabled within the settings? If not, please enable it and provide your Debug Log once more.

[pek2000]

Ok, debug's a lot bigger this time.

LOOTDebugLog.txt

[pStyl3]

As far as I can see there is nothing looking out of the ordinary .. wrinklyninja will be able to tell you more though.

One more idea, try installing LOOT outside of the NMM directory.

[WrinklyNinja]

On 5/12/2018 at 5:44 PM, pStyl3 said:

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

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

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

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

I don't think "Head" is a very descriptive name, I know what you mean by it, but I imagine the average user wouldn't? I'm not that fussed about the names though, I'm still more concerned about getting groups to work.

On 5/14/2018 at 6:23 PM, Artaios said:

Hey guys, I was wondering if it is possible to run Travis on my own fork of LOOT somehow.

I don't see why not, though there are a few secure tokens in the repository's travis config that you'd need to replace, or remove usage of. AFAIR they're used for publishing artifacts, so you shouldn't really need the bits they're used for.

On 5/16/2018 at 11:44 AM, pek2000 said:

I have an odd problem, I clicked on the link in LOOT, not sure if this is the right place.  Every time I run LOOT for FO4, I have to apply changes.  Even back-to-back sorting I get the "Apply" button, so I guess something is screwed up, but I can't figure out what it going on.

It sounds like loot/loot#946 might be related. Try this build, see if that works.

[Leonardo]

Quote

define Skyrim's group for "Update.esm" then as "Main Game Update"

That sounds logical to me.

Edited May 21, 2018 by Leonardo
Quoted wrong poster

[pek2000]

Sorry, no that didn't fix the sort/apply loop, still does it.

The debug log is different:

[0503/171030.801:ERROR:main_delegate.cc(713)] Could not load cef_extensions.pak
[0503/171031.016:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(37,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(48,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.024:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(31,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(42,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.402:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(52,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(63,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.409:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(49,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(60,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.425:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(49,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(60,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.653:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(57,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(68,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

 

 

 

[WrinklyNinja]

On 5/21/2018 at 10:51 PM, pek2000 said:

Sorry, no that didn't fix the sort/apply loop, still does it.

The debug log is different:

[0503/171030.801:ERROR:main_delegate.cc(713)] Could not load cef_extensions.pak
[0503/171031.016:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(37,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(48,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.024:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(31,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(42,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.402:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(52,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(63,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.409:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(49,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(60,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.425:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(49,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(60,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

[0503/171031.653:WARNING:angle_platform_impl.cc(41)] rx::HLSLCompiler::compileToBinary(224):
C:\fakepath(57,8-56): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\fakepath(68,9-41): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

 

 

 

That looks like the wrong debug log, CEFDebugLog.txt is no longer written to by LOOT, only LOOTDebugLog.txt is used now.

[pek2000]

Ok, rar'd the lootdebuglog.txt

 

LOOTDebugLog.rar

[WrinklyNinja]

7 hours ago, pek2000 said:

Ok, rar'd the lootdebuglog.txt

 

LOOTDebugLog.rar

I don't see any sorting attempts in that log.

[pek2000]

Try this one, I know I sorted this one.

 

LOOTDebugLog1.rar

[WrinklyNinja]

7 hours ago, pek2000 said:

Try this one, I know I sorted this one.

 

LOOTDebugLog1.rar

In that log, what's happening is that LOOT's sorting your plugins and changes the load order slightly (actually due to a bug in the new group stuff), then you click apply and LOOT tries to apply it. However, it fails because your plugins.txt is read-only. 44 seconds later you apply the load order again and this time it works (I assume you make plugins.txt writable in the time between).

That looks to me like everything (aside from the group bug) is working correctly.

[pek2000]

 ok, how about this, I ran loot, got the apply, closed it, got the lootdebuglog (lootdebuglog2.rar) , ran loot again immediately, got the apply button right again, closed it, got the loodebuglog (lootdebuglog3.rar).  So these 2 lootdebuglog's are back-to-back.  Got the apply button both times after the sort, ran nothing but loot.

LOOTDebugLog2.rar

LOOTDebugLog3.rar

 

I think that the sort is being applied correctly each time, at least FO4 loads ok without crashes, and fo4edit work each time, I just wanted to let you know something is off.

[WrinklyNinja]

56 minutes ago, pek2000 said:

 ok, how about this, I ran loot, got the apply, closed it, got the lootdebuglog (lootdebuglog2.rar) , ran loot again immediately, got the apply button right again, closed it, got the loodebuglog (lootdebuglog3.rar).  So these 2 lootdebuglog's are back-to-back.  Got the apply button both times after the sort, ran nothing but loot.

LOOTDebugLog2.rar

LOOTDebugLog3.rar

 

I think that the sort is being applied correctly each time, at least FO4 loads ok without crashes, and fo4edit work each time, I just wanted to let you know something is off.

OK, in this case I think the problem is that (due to the previously-mentioned group bug) LOOT is setting a load order that moves a creation club ESL plugin, which is actually impossible, but nothing complains. When getting the load order, LOOT's given a correct load order without the plugin moved, and so it always sees a difference between before and after.

I'm already working on fixing the group bug, but it might be worth also improving load order validation to check for CC plugins getting moved so the issue is made more obvious. I've filed libloadorder#51 to track that.

[pek2000]

Well, I can get rid of the free creation club mod, I'm cheap, I only went for it since it was free.  Was just making me a little nuts when i depend on LOOT to make sure my load order is right, too lazy to do it manually.

[pek2000]

Just to confirm, removing (manually) the mod fixed the sort/apply cycling.

[WrinklyNinja]

New build, there have been some significant changes since last time I posted a build:

• Group cycle avoidance now only ignores a plugin's group for all plugins in groups between its group and the group of the plugin it would cause a cycle with if the source or destination group is the default group, and the plugin ignored is the one in the default group. This improves cycle avoidance for plugins in groups that load before the default group.
• Updated libloadorder so that trying to set a load order where hardcoded plugins aren't in their hardcoded positions causes an error, which will help catch cases like the issue discussed in the posts above.
• I rewrote the masterlist update code because it was horrible and now it's much simpler and less likely to go wrong. If it does go wrong, it now leaves your filesystem in a better state (your masterlist might be messed up / missing, but your userlist and load order backups aren't moved around any more). I also fixed file handles possibly being left open while trying to move files around, which would cause errors. I expect this will fix most issues that are currently resolved with "delete your LOOT game folder".
• I finally tracked down and fixed the "cannot read 'status' of undefined" error, it turned out to be in a third-party library related to LOOT update checking.
• If you're offline or LOOT update checking fails for some other reason, it'll now add an error message to your general messages section.
• You can now turn LOOT update checking off in LOOT's settings.
• I'm not sure if this is new, but LOOT's now smarter about displaying Bash Tag suggestions. It now displays Bash Tags that are already in the plugin description with silver text, and only shows removal suggestions (in red text) for tags that are in the plugin description.

I'd also like to give special mention to CptMcSplody for doing a lot of valuable testing of the group sorting changes, that was really helpful.

I don't know of any issues with this build, so if nobody finds any I'll probably make a release soon. I'd like to also include the Polymer 3 UI update, but Google is dragging its feet releasing non-prerelease versions of its v3 elements and there's no indication of when they'll be done...