Jump to content

[RELz] LOOT - Load Order Optimisation Tool


WrinklyNinja

Recommended Posts

I've now released LOOT API v0.12.0, and merged LOOT's protobuf and and update-api branches into the dev branch, so you can use _dev builds and get all the ESL and protobuf changes.

Link to comment
Share on other sites

The toml-settings branch (latest build here) replaces LOOT's settings.yaml with a settings.toml, swapping out the relatively complex yaml-cpp dependency for the far simpler cpptoml. I've also added a new page to LOOT's website that you can use to convert your existing settings.yaml to a settings.toml.

Feedback on this would be great, as it's something that will affect all current users when they update, so communicating the change effectively and making it easy to deal with is important.

Link to comment
Share on other sites

The new page is interesting.

Works for the null case: {}  by producing a null file.

If the YAML is {a: 1, b: 2} we get 

Quote

a = 1
b = 2

But the carriage return is omitted in the D/L as expected. Nice.

Edit: Oops (see post below). The line-feed is the M/L separation character.

Link to comment
Share on other sites

I can reproduce what @lmstearn found with the CRLFs being stripped on the download link.  I tested in the latest Windows Chrome, Waterfox 55, and Firefox 57.

Copy + pasting out of the TOML box is fine and the line endings are preserved.

Here's my converted settings.toml from the download link: settings.toml

I ended up copying and pasting the converted text out of the browser and the resulting TOML file works fine.  So does the new LOOT. :)

EDIT: I'm half asleep.

Link to comment
Share on other sites

2 hours ago, lmstearn said:

The new page is interesting.

Works for the null case: {}  by producing a null file.

If the YAML is {a: 1, b: 2} we get 

But the carriage return is omitted in the D/L as expected. Nice.

Edit: Oops (see post below). The line-feed is the M/L separation character.

 

1 hour ago, Beermotor said:

I can reproduce what @lmstearn found with the CRLFs being stripped on the download link.  I tested in the latest Windows Chrome, Waterfox 55, and Firefox 57.

Copy + pasting out of the TOML box is fine and the line endings are preserved.

Here's my converted settings.toml from the download link: settings.toml

I ended up copying and pasting the converted text out of the browser and the resulting TOML file works fine.  So does the new LOOT. :)

EDIT: I'm half asleep.

The file available in the download link has LF line endings, but LOOT accepts them for me.

Link to comment
Share on other sites

On 3.11.2017 at 5:52 AM, WrinklyNinja said:

The decimal indices start with 0 for consistency, though I'm actually wondering if hex indices wouldn't be more useful as they could be used to work out in-game FormIDs, and would be consistent with the other indices too.

4095_dec = FFF_hex, 4096_dec = 1000_hex

4095 in hex is the last hex number with 3 digits, which is another good reason to use hex numbers instead of decimal ones. In order to gain space I would say, don't display the # afterall, too.

Link to comment
Share on other sites

On 11/2/2017 at 11:52 PM, WrinklyNinja said:

The decimal indices start with 0 for consistency, though I'm actually wondering if hex indices wouldn't be more useful as they could be used to work out in-game FormIDs, and would be consistent with the other indices too.

This is a hot topic for me, especially since Nexus Mod Manager doesn't offer the option to print out or copy the load order with numerical indices, so LOOT is the only source of plugin index information for vast hordes of us unwashed NMM users. I average at least one use a week of LOOT's 'copy load order to clipboard.' So, my primary request is please do not remove this functionality from LOOT, no matter how you decide to show plugin indices.

The hex indices are stupendously helpful in determining the first two (hex) digits of any mod-added (or override) item (FormID as you said.) I would hate to see them changed in any way except as required to accommodate SSE/FO4x64's expanded limits.

The decimal index is of secondary importance, used mainly to provide a count of plugins and to easily 'SWAG' how far down in a load order a particular plugin might be, or the relative position of two plugins. As such, I rerspectfully submit that there is no value to USERS to force numerical value concordance between the decimal indices and the hex indices, and the decimal indices would be more valuable TO USERS if the first one was correctly and logically labeled '1' instead of forced to '0' simply to enforce numerical concordance with the hex indices for no valid reason other than OCD :teehee: Trust me, I know about OCD (ask my husband about my shoe closet) and sympathize- but there is no value for users to have the decimal index off by one, forcing us to mentally say "Hmm, I see that Immersive Jewelry is my (42+1=) 43rd plugin of a total of (231+1=) 232 plugins, so it's relatively early in my load order and well ahead of Ultimate Assortment, which contains many of the same items and loads at position (186+1=) 187." In other words, the (apparently irrational) need to have the decimal index match the numerical value of the hex index not only doesn't add value, it makes certain thought processes MORE DIFFICULT than they would be if they simply started, logically, at 1.

And finallly, if it has to start at 0 instead of 1, it's not an index at all- it's an offset.

I tried to quote pStyl3's post using multi-quote but it doesn't work as (I) expected. He said:

Quote

Currently the decimal numbers for the .esl plugins start with 0. That isn't strictly needed, isn't it? Therefore wouldn't it be better, if that would start with 1?

YAY! :alienjump: Obviously, I agree with what he said- the decimal "plugin counter" should start at 1- maybe if we stop calling it an "index" it'll be easier to see why it should start at 1.

Link to comment
Share on other sites

No. All internal counters start at 0 and the esl counter exists inside the game and is part of the runtime formID. Starting at index 1 will create inconsistencies when converting.

 

Link to comment
Share on other sites

13 hours ago, Vyxenne said:

This is a hot topic for me, especially since Nexus Mod Manager doesn't offer the option to print out or copy the load order with numerical indices, so LOOT is the only source of plugin index information for vast hordes of us unwashed NMM users. I average at least one use a week of LOOT's 'copy load order to clipboard.' So, my primary request is please do not remove this functionality from LOOT, no matter how you decide to show plugin indices.

The hex indices are stupendously helpful in determining the first two (hex) digits of any mod-added (or override) item (FormID as you said.) I would hate to see them changed in any way except as required to accommodate SSE/FO4x64's expanded limits.

The decimal index is of secondary importance, used mainly to provide a count of plugins and to easily 'SWAG' how far down in a load order a particular plugin might be, or the relative position of two plugins. As such, I rerspectfully submit that there is no value to USERS to force numerical value concordance between the decimal indices and the hex indices, and the decimal indices would be more valuable TO USERS if the first one was correctly and logically labeled '1' instead of forced to '0' simply to enforce numerical concordance with the hex indices for no valid reason other than OCD :teehee: Trust me, I know about OCD (ask my husband about my shoe closet) and sympathize- but there is no value for users to have the decimal index off by one, forcing us to mentally say "Hmm, I see that Immersive Jewelry is my (42+1=) 43rd plugin of a total of (231+1=) 232 plugins, so it's relatively early in my load order and well ahead of Ultimate Assortment, which contains many of the same items and loads at position (186+1=) 187." In other words, the (apparently irrational) need to have the decimal index match the numerical value of the hex index not only doesn't add value, it makes certain thought processes MORE DIFFICULT than they would be if they simply started, logically, at 1.

And finallly, if it has to start at 0 instead of 1, it's not an index at all- it's an offset.

I tried to quote pStyl3's post using multi-quote but it doesn't work as (I) expected. He said:

YAY! :alienjump: Obviously, I agree with what he said- the decimal "plugin counter" should start at 1- maybe if we stop calling it an "index" it'll be easier to see why it should start at 1.

Indices will remain zero-based, because that's consistent with the games' handling. Copy Load Order will continue to print load order indices as decimal and hex values. The indices under discussion are the active light master indices, which appear in the UI and the Copy Load Order output.

Your mention that using zero-based indices is irrational, but there's technical justification to using them, while using one-based indices is just your personal preference, and it's trivial to mentally +1 if you want to do so and create more work for yourself. If we were talking hex arithmetic, I'd sympathise, but whether you count from 0 or 1 is such an inconsequential thing. At the end of the day, LOOT is reporting a number that has a particular meaning, and I don't want to distort that meaning or make it ambiguous.

Link to comment
Share on other sites

Could you fellows take a look at this and tell whats wrong. When I run LOOT it doesn't show warnings of dirty or unclean masters. I'm running a the latest Skyrim but I've downloaded the previous Skyrim .exe from Steam so that I may run SKSE64. I cleaned the update esm with SSEEDit and got results so I know that they are dirty. Sorry if this posted in the wrong area I just followed the link on LOOT.

Edit: things I have tried are moving LOOT to different locations, deleting the attached folder so that LOOT whould generate a new one completely removing LOOT from pc and re-downloading, and disabling anything xbox related.              

Uinstalled everything reinstalled SSE, MO2, SSEEdit, and LOOT. Made sure I have the redistributable.           

LOOT.7z  

Link to comment
Share on other sites

:clap:Sorry I must have read 20-30 pages or more of information from all over about LOOT and could find nothing on my problem. I'm working off a fresh install of windows and I was worried maybe that there was something going on other than a problem with LOOT. I didn't mean come across as impatient or rude. 

Link to comment
Share on other sites

Hello. Been looking online for help with this particular issue, but I have not found a solution. I was using LOOT along with FO4edit and Nexus Mom Manager. I believe I had everything set up right after a bit of work. I was testing if a particular mod was causing a problem. I found a solution and started up LOOT to set the launch order. It had been working fine before doing so, but now it ceases to work. This is the text from the LOOT debug log:

[17:33:38.550242] [warning]: Blocking load of resource at https://fonts.googleapis.com/css?family=Roboto:400,300,300italic,400italic,500,500italic,700,700italic
[17:33:38.550742] [warning]: Blocking load of resource at https://fonts.googleapis.com/css?family=Roboto+Mono:400,700
[17:35:34.128990] [error]: libloadorder failed to set the load order. Details: "C:\Users\David\AppData\Local\Fallout4\plugins.txt" could not be written. Details: ios_base::badbit set: iostream stream error: Libloadorder error

This is the CEF debug log:

[1113/173338.396:ERROR:main_delegate.cc(726)] Could not load cef_extensions.pak

 

The solutions I found online were to see if a program was blocking LOOT access to the internet. It was working before and had no problem, but I created an exception just in case. The problem persisted. I also found a suggestion to delete the Fallout4 folder in app\data\local\LOOT and restarting LOOT. This did not work as well. So can someone offer me some help? Thank you.

Link to comment
Share on other sites

@WrinklyNinja, would it possible to have LOOT put SOTAntiCTD.esp as far down the load order plugins.txt as possible? Failure to do so will result in Skyrim being very unstable and CTDing all the time. Currently LOOT automatically places it in the top 25 spot of my 210 esp load order. I have to manually correct it each time. It took a week of my Skyrim crashing and me trouble shooting it to figure out that that was crashing it. 

Link to comment
Share on other sites

LOOT 0.11 is crashing with the following exception on my PC: (0x40000015) occurred in the application at location 0x688a4505. I've uninstalled it and installed 0.10.3 which hasn't crashed once. I don't have the logs any more but I'm willing to re-install 0.11 and upload the logs if that would help you.

Link to comment
Share on other sites

One thing I forgot to mention is that I've finally fixed the snapshot builds telling you a newer version of LOOT exists - LOOT now compares the date of the latest release to the date of the snapshot build.

14 hours ago, TheCipher said:

Hello. Been looking online for help with this particular issue, but I have not found a solution. I was using LOOT along with FO4edit and Nexus Mom Manager. I believe I had everything set up right after a bit of work. I was testing if a particular mod was causing a problem. I found a solution and started up LOOT to set the launch order. It had been working fine before doing so, but now it ceases to work. This is the text from the LOOT debug log:

[17:33:38.550242] [warning]: Blocking load of resource at https://fonts.googleapis.com/css?family=Roboto:400,300,300italic,400italic,500,500italic,700,700italic
[17:33:38.550742] [warning]: Blocking load of resource at https://fonts.googleapis.com/css?family=Roboto+Mono:400,700
[17:35:34.128990] [error]: libloadorder failed to set the load order. Details: "C:\Users\David\AppData\Local\Fallout4\plugins.txt" could not be written. Details: ios_base::badbit set: iostream stream error: Libloadorder error

This is the CEF debug log:

[1113/173338.396:ERROR:main_delegate.cc(726)] Could not load cef_extensions.pak

 

The solutions I found online were to see if a program was blocking LOOT access to the internet. It was working before and had no problem, but I created an exception just in case. The problem persisted. I also found a suggestion to delete the Fallout4 folder in app\data\local\LOOT and restarting LOOT. This did not work as well. So can someone offer me some help? Thank you.

The resource blocking is harmless, I've added an FAQ entry about it, your problem is that libloadorder can't write to your plugins.txt - make sure it's not read-only.

13 hours ago, thebunnyrules said:

@WrinklyNinja, would it possible to have LOOT put SOTAntiCTD.esp as far down the load order plugins.txt as possible? Failure to do so will result in Skyrim being very unstable and CTDing all the time. Currently LOOT automatically places it in the top 25 spot of my 210 esp load order. I have to manually correct it each time. It took a week of my Skyrim crashing and me trouble shooting it to figure out that that was crashing it. 

Try giving the plugin a high global priority value using the metadata editor. If that works for you, it can be added to the masterlist.

13 hours ago, thebunnyrules said:

LOOT 0.11 is crashing with the following exception on my PC: (0x40000015) occurred in the application at location 0x688a4505. I've uninstalled it and installed 0.10.3 which hasn't crashed once. I don't have the logs any more but I'm willing to re-install 0.11 and upload the logs if that would help you.

That's probably since been fixed, try the latest snapshot build.

Link to comment
Share on other sites

1 hour ago, WrinklyNinja said:

The resource blocking is harmless, I've added an FAQ entry about it, your problem is that libloadorder can't write to your plugins.txt - make sure it's not read-only.

This worked. It was set to read-only. Tyvm for taking the time. :)

Link to comment
Share on other sites

@WrinklyNinja As recommended, I've lowered SOTAntiCTD.esp 's place in the loadorder by editing the metadata. My Skyrim's been running very smoothly since, is there something I can do to help you update the master list? I can pastebin my plugins.txt if that will help.

Link to comment
Share on other sites

On 15/11/2017 at 11:18 AM, thebunnyrules said:

@WrinklyNinja As recommended, I've lowered SOTAntiCTD.esp 's place in the loadorder by editing the metadata. My Skyrim's been running very smoothly since, is there something I can do to help you update the master list? I can pastebin my plugins.txt if that will help.

The best way to get your changes in the masterlist is to submit a pull request, see How To Contribute for details, though while it goes through making changes on your PC, you can also do everything through your web browser, since the masterlists are now all small enough to edit online.

Link to comment
Share on other sites

Off topic and not related to LOOT, but may I please ask, if I am trying to use a Bethesda tool Elric (xtexconv.exe) and it says it's missing MSVCP110.dll how do you find out which redist to get? I have a texconv.exe from the Microsoft GitHub which might be the same thing only newer but I wanted to run the exe provided. The files in _CommonRedist for the SSE folder didn't fix the issue.

Link to comment
Share on other sites

On 11/18/2017 at 5:18 PM, Sharlikran said:

Off topic and not related to LOOT, but may I please ask, if I am trying to use a Bethesda tool Elric (xtexconv.exe) and it says it's missing MSVCP110.dll how do you find out which redist to get? I have a texconv.exe from the Microsoft GitHub which might be the same thing only newer but I wanted to run the exe provided. The files in _CommonRedist for the SSE folder didn't fix the issue.

http://www.majorgeeks.com/files/details/visual_c_runtime_installer.html

Use this to install all the most recent visual C++ updates. It should fix your problem.

Link to comment
Share on other sites

The latest snapshot build of the update-loot-api branch changes the light master indices in the sidebar to be hex triplets (eg. 0A2). I'm not sure if it's worth padding to three digit or whether to just have them appear as 1, 11 and 111 (as opposed to 001, 011 and 111) as they increase.

Link to comment
Share on other sites

Screenshot 1 - Screenshot 2

I like it as it is now. If we want consistency between what LOOT displays and what the ingame runtime FormIDs are, then LOOT should always display 3 digits for the .esl plugins, even if 1 or 2 would be sufficient (so 001 instead of 1).

Note: Don't mind the number of errors I had within LOOT in those screenshots. That's because the used .esl plugin is a FO4 plugin and requires Fallout4.esm, but I used it for SSE in LOOT.

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