Jump to content

Recommended Posts

2 hours ago, Sharlikran said:

ESL flag has 0000000000 impact on load order
an .esp behaves exactly the same, no matter if it has the ESL flag or not
FormID prefix has nothing to do with load order
01, 02, FE000, 03, FE001, ... that's a valid load order
load order is determined by the order in which the modules load. at which point they are assigned the next full or light slot depending on the ESL flag
the ESL flag does not change the load order

Unordered lists are easier to handle.

Suppose we have 4000 of the things- it's not going to look nice on the WB tabs. The option of having them either merged or filtered out in the mods tab might be better.

The only way it can be done is to snapshot or dump what's in the save header each load and use that as the current comparator. Then match the alphabetic list to it. Checking the changing order of mods in the save header might be a thing as well. Snapshot that on load and see. Best trialed on a small mod load. There's a tiny one here if you want to test.

Share this post


Link to post
Share on other sites

I apologize but I cant keep commenting on things that I have no control over. I didn't make the esl feature Bethesda did. In doing so there is no way to do what you ask. As always if you find someone to volunteer to make an skse plugin that saves the order of the plugins with a file name that matches the save, and python code to associate the output with the exact save so they match then have them submit a pull request.

Share this post


Link to post
Share on other sites

When I try to access the program it immediately crashes and provides the below information. I have been banging my head against the wall for a couple hours trying to figure it out. Now I am just doing what the error message is telling me to do, I feel the fixing is a little beyond me. Any insight would be appreciated.

Traceback (most recent call last):
  File "bash\bash.pyo", line 227, in main
  File "bash\bash.pyo", line 393, in _main
  File "bash\basher\__init__.pyo", line 3981, in Init
  File "bash\basher\__init__.pyo", line 4021, in InitData
  File "bash\bosh\__init__.pyo", line 2726, in refresh
  File "bash\bosh\__init__.pyo", line 1382, in refresh
  File "bash\bosh\__init__.pyo", line 1358, in new_info
  File "bash\bosh\__init__.pyo", line 1277, in new_info
  File "bash\bosh\__init__.pyo", line 393, in __init__
  File "bash\bosh\__init__.pyo", line 274, in __init__
  File "bash\bosh\__init__.pyo", line 405, in _reset_cache
  File "bash\bosh\__init__.pyo", line 1108, in readHeader
  File "bash\bosh\save_headers.pyo", line 62, in __init__
  File "bash\bosh\save_headers.pyo", line 78, in load_header
  File "bash\bosh\save_headers.pyo", line 88, in load_image_data
OverflowError: Python int too large to convert to C long

Share this post


Link to post
Share on other sites

@acidblood719:  That's a start, but he needs more info to figure things out (including which game you are attempting to use).  Please see the "Reporting bugs" section in the first post of this thread.

-Dubious-

 

Share this post


Link to post
Share on other sites

@acidblood719 Go to the second post, download 307.201807311531 and use that instead. If the error persists then please run Wrye Bash with the -d parameter. However, if you used the EXE installer it will have added shortcuts to the start menu that say they will run Wrye Bash in debug mode. That error log produced in Debug mode is better because it shows more information, specifically the version of Wrye Bash and which game you are using this with.

Share this post


Link to post
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

Support us on Patreon!

×