Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

8 hours ago, warmfrost85 said:

Since I did touch skyrimse/records.py to fix, does that mean Beermotor's experimental branch that enables more Bash tags is not acceptable?

I found the comments on 2dd08b4 for @Beermotor fork. @warmfrost85 I see that you mention that the fields are optional. Where did you get that information? The xEdit source code is the only information you should be consulting for any record definitions and there are no optional fields in Skyrim SE. Without the work I have done with the records and patchers since before 2014 (I forget I started on Oblivionworks) there would only be an Oblivion mode and the Skyrim mode would still have 18 of Skyrim's 120 records defined like it did for 304.3. Hardly any mods would be mergable and no container patcher, nothing but leveled lists.

The error to tell a user that the record is not the correct size has always been there. I just added a message to it for the records that Bethesda changed for Skyrim SE. Think of it this way. What if you ran a program in windows and it gave you an Error “22 - ERROR_BAD_COMMAND” and you don't know what it means so you google it. When you find it you discover it just means that the command you have entered is unknown to the program. Now what if the author of the program used intelligent exception handling and explained why the error happened and what to do?  Since the error is expected, explains what the error is, and offers a solution, can you explain why you are trying to fix it?

If mod authors and mod users want the error to go away, then update the plugin with the CK. Don't make it a silent error. The error is informative. If you make it a silent error then when something doesn't work people will ask why and then you have to tell them the error is suppressed because people thought it was annoying.  Mod users should know when the author has not properly updated the Skyrim mod for Skyrim SE.

Even the Check for Errors routine in xEdit can hurt a mod if users just start going off on the author.  I chose that error message to be as respectful as possible. I didn't want it to say something that would cause users to post rants and disparaging comments toward the mod author potentially damaging the mods reputation. I could have said just about anything along the lines of "this mod was not saved with the Skyrim SE CK, use with caution" or "This mod was not properly updated for Skryim SE, uninstall it" but I chose something more reasonable.

In fact if the mod has no ESP files as masters, only has ESM files with the ESM flag, and the user knows nothing about modding they can still save the plugin and it would correct the records without damaging the mod. The only problem would be when there are ESP files that need to be temporarily flagged as ESM files. Which makes it a reasonably easy solution for the user.

Link to comment
Share on other sites

12 hours ago, Langeston said:

I just thought it would be nice to have the ability to look at load order and install order on the same screen.

A snapshot overlay form with scrollbars of the modlist activated by a button on the status bar or hotkey might not be exactly what you are looking for, albeit an easier alternative for the programmer than a form with controls. The idea being that, as soon as it is clicked on, it goes away.

Link to comment
Share on other sites

22 hours ago, warmfrost85 said:

Note sure whether to post this here or as an issue at github. I'll start here.

WB reads the bash tags from a plugin header record expecting this format: {{BASH:tag,tag}}  WB is looking for "BASH" uppercase, a case sensitive search. The mod Another Sorting Mod has mixed case so the tags are not recognized in the header, e.g. {{Bash:Names,Stats}}. I assume there are other mods like this. Is this behavior intentional? If so, why? I noticed this when using Beermotor's branch with the additional Bash tags enabled.

It's an easy to make it case insensitive by adding 're.I' which I have done in my personal WB repository and now works as I expect.


maBashKeys = re.search(u'{{ *BASH *:([^}]+)}}',description,flags=re.U|re.I)

@UtumnoShould this have been posted as an issue in github instead? Or maybe it's not considered an issue. :cool:

My guess is for it to stand out - for this one I would accept a pull request and discuss there - I would need the Bash tags name detection to remain case sensitive however

21 hours ago, Langeston said:

One of the things I love about WB over other mod managers is the amount of information I can get at a glance without having to go through a bunch of mouse clicks. A thought occurred to me the other day while I was popping back and forth between the installers tab and mods tab to make sure some ESPs were in the right order: would it be possible/feasible to integrate a plugin list in the same tab as the installers? Even if it isn't as fully featured as the mods tab and only allows reordering of plugins I can see it being a huge convenience when negotiating load/install order- especially in cases where you are using a lot of loose files.

Here is a quick MSPaint mock up of what I'm talking about:

 

  Reveal hidden contents

2027212058_WBMockup.thumb.png.192826048f58cfbd4bad0ba12d0ece1a.png

 

I'm sure I'm not the first person to come up with this idea, so if it has already been discussed and rejected for whatever reason, I'm sorry.

If it hasn't been discussed before though, I think it would be a really neat addition.

Best regards,

Langeston

That's not an option anytime soon - it would need a lot of work in the UI code. Maybe in the future - you can jump from a mod to its installer however

Link to comment
Share on other sites

I just want to go on record again that I don't think it's prudent to only emit warnings or errors for records that changed formats between LE and SSE. I've seen it firsthand that ignoring form 43 is bad, and such errors NEED to be emitted for any record in a plugin that's being used in SSE that is still form 43. Not just the supposed 6 which actually changed. We don't know how the engine itself is reacting to all of this without doing things 100% correctly - which can only be done by porting in the CK.

Link to comment
Share on other sites

19 hours ago, Sharlikran said:

I see that you mention that the fields are optional. Where did you get that information?

Thanks @Sharlikranfor your explanation although I'm talking about Beth files, not user created files.

Here is my relevant comment from that commit for easy reference.

Spoiler

This will fix the issue with WATR.DNAM and STAT.DNAM. Since I already have a fork of wyre, I can't fork your fork to create a pull request for you so I'll add the code you need to change at the bottom of this comment.


Skyrim.esm: 
Wrye Bash SSE expects a newer format for STAT.DNAM than found.
Load and save Skyrim.esm with the Skyrim SE CK
STAT.DNAM: Expected size == 12, but got: 8
Error loading 'STAT' record and/or subrecord: 00000E87
  eid = u'LoadScreenMRaltar01'
  subrecord = 'DNAM'
  subrecord size = 8
  file pos = 5006616
Error in Skyrim.esm

The issue is STAT.DNAM and WATR.DNAM have an optional field at the end
of the subrecord. For WATR.DNAM it's 'noisePropertiesFlowmapScale'.
So sometimes the length is 232 and sometimes its 228.

For WATR.DNAM the breakdown is thus:

  • Skyrim.esm: 3 have a length of 232 and 31 have a length of 228
  • Update.esm: 8 with length 232 and 30 with length of 228
  • HearthFirers.esm: has no WATR.DNAM records
  • Dawnguard.esm: all have length of 228
  • Dragonborn.esm: all have length of 228

Same issue for STAT.DNAM but with different lengths and counts.


When creating a bashed patch for these Beermotor's enabled Skryim SE bash tags, WB was complaining that Skyrim.esm has invalid record lengths and must be resaved in the CK. Asking the user the resave in CK is not true in this case.

For STAT.DNAM and WATR.DNAM records it looks like SSE's Skyrim.esm and Update.esm files contains both Skyrim LE and Skyrim SE record definitions. When I say optional field, I mean Skyrim SE's new 'Noise Properties - Flowmap Scale' field at the bottom of the WATR.DNAM definition. I see this in xEdit's wbDefinitionsTES5.pas file with the following line.
        // SSE
        wbFloat('Noise Properties - Flowmap Scale')
    
For STAT.DNAM, the optional record is SE's 'snowflag' and some unused data.
From xEdit SE definition for STAT.DNAM:
        // SSE
        wbInteger('Flags', itU8, wbFlags([
          {0x01} 'Considered Snow'
        ])),
        wbByteArray('Unused', 3, cpIgnore)
    
I know you're well aware of these definitions in xEdit and WB, so I'm only showing them here to explain my interpretation.     

My change to WB for SSE only, is to allow the SSE patchers to accept both LE and SE definitions in the Bethesda files.

I use the record length to determine if it's an LE or SE record. Example: If the STAT.DNAM record length is 8, I assume it's an LE record. If the length is 12, I assume it's a SE record. Any other length is an assumed error. I then alter the python format pattern to match the expected record structure if an LE record is detected. I don't add or ignore any data in the file.

If my interpretation is correct, is my solution a valid in this SSE only case? If not, how do you recommend this be approached?
    
Thanks.

Link to comment
Share on other sites

10 hours ago, Arthmoor said:

such errors NEED to be emitted for any record in a plugin that's being used in SSE that is still form 43.

@Arthmoor I'm talking about the record definitions in the Beth files, so this case is not a form 43 vs form 44 issue. BTW: I wrote an xEdit script that scans my load order looking for non form 44s in all records anywhere not just the header record. Absolutely amazing how many non form 44s I find in SSE mods.

I've created a Bashed Patch for my current load order of about 120 mods, all have form 44s (I've verified they're clean), but yet the resulting Bashed Patch's leveled list has form 40s and the tweak to double my jump height has a form 30. The patcher definitely has issues that are not related to bad forms in the source mods. Since I have a good test case, out of curiosity I'll probably look at the patcher code, coming up for air eventually. This "bad" Bashed Patch could explain some of my random CTD when play testing this new character.

Edit: Of course I can re-save the Bashed Patch in the CK which fixes it.

Link to comment
Share on other sites

Yes, I've mentioned the issue about the patch itself generating records in the wrong version format. Other people insist it need not be done, but you can find Reddit littered with old posts of people who found the patch being the cause of problems related to incorrect form versions on SSE.

SSE is something of a pain in the ass as far as this goes, but it can't be ignored either. Something needs to be done to correct for it or getting more patchers working will only make things worse.

Link to comment
Share on other sites

3 hours ago, warmfrost85 said:

WB was complaining that Skyrim.esm has invalid record lengths and must be resaved in the CK. Asking the user the resave in CK is not true in this case.

how do you recommend this be approached?
    
Thanks.

The code you are looking at doesn't detect anything and therefore mute the error, it forces the record to be updated to the current definition. There isn't a way to make it update the record for only the DLC and not ESP files. That's one of the drawbacks of Wrye Bash. It is an all or nothing kind of process. For xEdit it writes only the bytes it finds. Wrye Bash writes the total amount of bytes for the record according to the definition. Everything in Wrye Bash is required so to speak. Making something optional requires extra routines.

If it has to happen to keep it from displaying an error for the DLC then that means the error will never prevent records with the incorrect size from being updated. Default values would have to be added to the definition and you would need to unpack the data and properly assign the default values and unused data that in effect shifts the bytes as Bethesda did for their changes.

I had asked Utumno a while back to see if there was a way to prevent the error from displaying when it was the official DLC. I don't think he has had time to look into that.

Link to comment
Share on other sites

Compromise: I can't always keep users from messing things up. I can't keep authors from not using the CK. I didn't want ESL files to be patched automatically by xEdit because the game engine handles them already. It more or less merges all of them into FE even if you have 50 or more. There are a few people with 300 plugins so far using the newest pre-release of xEdit. I don't see why people want to patch what the game engine patches already.

In the end, it doesn't matter whether or not I want to prevent issues.  I objected to Elminster adding ESL support to the Merge Patch but he gave his reasons why that made no sense so it's going to happen.  I guess my point is that wanting to prevent certain things won't matter. There is zEdit and xEdit scripts. In reality making other patchers function is more important.

Do you have enough experience with Python to help update the remaining patchers for FO3 and FNV?  The reason I ask is Oblivion, FO3, FNV, all have the same records and requirements basically. Finishing those would mean full support for three games. You would have some experience in the patcher code and therefore better understanding for how the patchers might be able to be altered for Skyrim/SSE/FO4. Are you interested in getting the FO3/FNV patchers working and then seeing what else can be enabled for the other games? Also do you think you could tackle making custom unpack routines for the remaining Skyrim records? PERK, PACK, RACE, SCEN need to be finished, LAND not so much it's too complex.

My python knowledge is limited. I can port the records for some reason fairly easily having done so much decoding for xEdit. Like xEdit though, I can't really make the backend code.

Link to comment
Share on other sites

Just curious to know how this poster got the GUI so small! (NVM my input there- yet another S % M (Senior % Moment)
Adjusted the borders on this rig (1360 X 768) but couldn't get the form any smaller than around 480 X 380.

One way to redress it might be to implement a message yes/no warning box in the window size event to the effect 

Quote

The window positions have been moved to less than <TOL> Do you really want this?
(with, of course the ever popular don't_show_me_this_again checkbox for advanced users)


 

Link to comment
Share on other sites

@warmfrost85 the best way to understand the patcher is to follow a patch in Pycharm's debugger. Adding some technical comments would be a very welcome contribution. Can you link me to the commit with your changes?

 

Link to comment
Share on other sites

307.201807251609

Contains the fixes I referred to before (cp65001 and save file init) and also, more importantly, the fix for restore settings. Bash should be able now to correctly restore settings - you are lucky I had a holiday guys, this was tough

Give it a whirl

 

EDIT: the actual code is on top of utumno wip in https://github.com/wrye-bash/wrye-bash/tree/390-broken branch

Edited by Utumno
Link to comment
Share on other sites

Hello everyone. I want to report a bug while trying to use Wrye Bash, for it would not even open. I am trying to get into a modded Skyrim once again, and I need Wrye Bash to make bashed patches. But after installinf it and trying to open it, only the logo woild succesfully appear before an error message pops up. What am I doing wrong? I just want to play the game, modded as I did years ago.

 

This is the complete message, nothing is left aside:

 

Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://www.afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

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 4023, in InitData
  File "bash\bosh\__init__.pyo", line 1545, in __init__
  File "bash\bosh\__init__.pyo", line 1555, in ini
  File "bash\bosh\__init__.pyo", line 941, in BestIniFile
  File "bash\bosh\ini_files.pyo", line 61, in formatMatch
AttributeError: 'NoneType' object has no attribute 'open'

Link to comment
Share on other sites

8 hours ago, Utumno said:

307.201807251609

Contains the fixes I referred to before (cp65001 and save file init) and also, more importantly, the fix for restore settings. Bash should be able now to correctly restore settings - you are lucky I had a holiday guys, this was tough

Give it a whirl

Giving it a whirl - First run after installing, installed for SSE and FO4, ran it in Debug mode for both of them and the initial Backup settings

I think this part is no problem apart from the fact that it still saves the backup zip in the same location for both SSE Wrye Bash Standalone, and FO4 Wrye Bash Standalone

See line 20 in both BashBugDump.logs spoilered - Even though they are completely separate installations of WB Standalone, each with their own Gamename \ Mopy \

They both save backup files into the SSE location ..

BACKUP BASH SETTINGS: D:\Steam\steamapps\Common\Skyrim Special Edition Mods\Bash Mod Data\

FO4 Wrye Bash should be saving into ..

BACKUP BASH SETTINGS: D:\Steam\steamapps\Common\Fallout4 mods\Bash Mod Data\

But instead it saves into the SSE bash mod data location.

Going to try restoring settings next after deleting the in play bashsettings.dat .. Fingers crossed :)

 

Wrye Bash starting
Using Wrye Bash Version 307.201807251609 (Standalone)
OS info: Windows-10-10.0.17134
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Skyrim Special Edition\\Mopy\\Wrye Bash.exe', '-d']
Using scandir 1.5
bash.pyo  398 _import_bush_and_set_game: Searching for game to manage:
bush.pyo   86 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   88 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   88 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  146 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  152 _detectGames: Set game mode to Skyrim Special Edition found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo  167 __setGame:  Using Skyrim Special Edition game: D:\Steam\steamapps\common\Skyrim Special Edition
mods_metadata.pyo  230 __init__: Using LOOT API version: 0.13.2
testing UAC
barb.pyo  147 backup_settings: 
barb.pyo  148 backup_settings: BACKUP BASH SETTINGS: D:\Steam\steamapps\Common\Skyrim Special Edition Mods\Bash Mod Data\Backup Bash Settings Skyrim Special Edition (2018-07-25 22.25.36) v307.201807040057-307.201807251609.7z
barb.pyo  160 _backup_settings: My Games\Skyrim Special Edition\Saves\Bash\Table.dat.bak <-- D:\Documents\My Games\Skyrim Special Edition\Saves\Bash\Table.dat.bak
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\Russian.txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Russian.txt
barb.pyo  160 _backup_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Installers.dat <-- D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Installers.dat
barb.pyo  160 _backup_settings: Skyrim Special Edition Mods\Bash Mod Data\Table.dat <-- D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Mod Data\Table.dat
barb.pyo  160 _backup_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat.bak <-- D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat.bak
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\Japanese.txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Japanese.txt
barb.pyo  160 _backup_settings: My Games\Skyrim Special Edition\Saves\Bash\Table.dat <-- D:\Documents\My Games\Skyrim Special Edition\Saves\Bash\Table.dat
barb.pyo  160 _backup_settings: My Games\Skyrim Special Edition\BashSettings.dat <-- D:\Documents\My Games\Skyrim Special Edition\BashSettings.dat
barb.pyo  160 _backup_settings: My Games\Skyrim Special Edition\BashLoadOrders.dat <-- D:\Documents\My Games\Skyrim Special Edition\BashLoadOrders.dat
barb.pyo  160 _backup_settings: My Games\Skyrim Special Edition\BashSettings.dat.bak <-- D:\Documents\My Games\Skyrim Special Edition\BashSettings.dat.bak
barb.pyo  160 _backup_settings: My Games\Skyrim Special Edition\BashLoadOrders.dat.bak <-- D:\Documents\My Games\Skyrim Special Edition\BashLoadOrders.dat.bak
barb.pyo  160 _backup_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Installers.dat.bak <-- D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Installers.dat.bak
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\pt_opt.txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\pt_opt.txt
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\Italian.txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Italian.txt
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\de.txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\de.txt
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\Chinese (Simplified).txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Chinese (Simplified).txt
barb.pyo  160 _backup_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat <-- D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat
barb.pyo  160 _backup_settings: Skyrim Special Edition\Mopy\bash\l10n\Chinese (Traditional).txt <-- D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Chinese (Traditional).txt
barb.pyo  160 _backup_settings: Skyrim Special Edition Mods\Bash Mod Data\Table.dat.bak <-- D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Mod Data\Table.dat.bak
 

-------------------------------

Wrye Bash starting
Using Wrye Bash Version 307.201807251609 (Standalone)
OS info: Windows-10-10.0.17134
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Fallout 4\\Mopy\\Wrye Bash.exe', '-d']
Using scandir 1.5
bash.pyo  398 _import_bush_and_set_game: Searching for game to manage:
bush.pyo   86 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   88 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   88 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  146 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  152 _detectGames: Set game mode to Fallout4 found in parent directory of Mopy:  D:\Steam\steamapps\common\Fallout 4
bush.pyo  167 __setGame:  Using Fallout4 game: D:\Steam\steamapps\common\Fallout 4
mods_metadata.pyo  230 __init__: Using LOOT API version: 0.13.2
testing UAC
barb.pyo  147 backup_settings: 
barb.pyo  148 backup_settings: BACKUP BASH SETTINGS: D:\Steam\steamapps\Common\Skyrim Special Edition Mods\Bash Mod Data\Backup Bash Settings Fallout4 (2018-07-25 22.21.58) v307.201807040057-307.201807251609.7z
barb.pyo  160 _backup_settings: My Games\Fallout4\BashSettings.dat <-- D:\Documents\My Games\Fallout4\BashSettings.dat
barb.pyo  160 _backup_settings: My Games\Fallout4\BashSettings.dat.bak <-- D:\Documents\My Games\Fallout4\BashSettings.dat.bak
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\Italian.txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Italian.txt
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Installers\Bash\Converters.dat.bak <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Converters.dat.bak
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Mod Data\INI Data\Table.dat.bak <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\INI Data\Table.dat.bak
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\Japanese.txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Japanese.txt
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\Russian.txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Russian.txt
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\Chinese (Simplified).txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Chinese (Simplified).txt
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Installers\Bash\Converters.dat <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Converters.dat
barb.pyo  160 _backup_settings: My Games\Fallout4\Saves\Bash\Table.dat <-- D:\Documents\My Games\Fallout4\Saves\Bash\Table.dat
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Mod Data\Table.dat.bak <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\Table.dat.bak
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Installers\Bash\Installers.dat.bak <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Installers.dat.bak
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\Chinese (Traditional).txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Chinese (Traditional).txt
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\pt_opt.txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\pt_opt.txt
barb.pyo  160 _backup_settings: My Games\Fallout4\BashLoadOrders.dat <-- D:\Documents\My Games\Fallout4\BashLoadOrders.dat
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Mod Data\INI Data\Table.dat <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\INI Data\Table.dat
barb.pyo  160 _backup_settings: Fallout4\Mopy\bash\l10n\de.txt <-- D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\de.txt
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Mod Data\Table.dat <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\Table.dat
barb.pyo  160 _backup_settings: Fallout4 Mods\Bash Installers\Bash\Installers.dat <-- D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Installers.dat
barb.pyo  160 _backup_settings: My Games\Fallout4\BashLoadOrders.dat.bak <-- D:\Documents\My Games\Fallout4\BashLoadOrders.dat.bak
barb.pyo  160 _backup_settings: My Games\Fallout4\Saves\Bash\Table.dat.bak <-- D:\Documents\My Games\Fallout4\Saves\Bash\Table.dat.bak
 

lrimRe6.png

Link to comment
Share on other sites

@Utumno - The work was (as far as I can tell so far) a bit of a remarkable success (only a bit though, wouldn't want the moral to be raised too much) :D

Window positions, info boxes, toolbar Icon size, menu preferences such as Dont allow skipping of bethsoft content = All restored after previously deleting bashsettings.dat in my documents.

After deleting the bashsettings.dat file, I launched again in debug mode hoping to grab a bashbugdump.log afterwards, and even though it does a restart of Wrye Bash as part of the process, I got one (just for SSE so far, going to try FO4 next), but I think its partial, as you exit Wrye Bash after it has restored and come back up the bashbugdump.log ends with what looks like an unfinished line? so the following is all that could be grabbed ..

 

Wrye Bash starting
Using Wrye Bash Version 307.201807251609 (Standalone)
OS info: Windows-10-10.0.17134
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Skyrim Special Edition\\Mopy\\Wrye Bash.exe', '--debug', '--restore', '--filename', 'c:\\users\\m0l3y\\appdata\\local\\temp\\RestoreSettingsWryeBash__2nkpl', '--no-uac']
Using scandir 1.5
bash.pyo  398 _import_bush_and_set_game: Searching for game to manage:
bush.pyo   86 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   88 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   88 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  146 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  152 _detectGames: Set game mode to Skyrim Special Edition found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo  167 __setGame:  Using Skyrim Special Edition game: D:\Steam\steamapps\common\Skyrim Special Edition
barb.pyo  309 _restore_settings: 
barb.pyo  310 _restore_settings: RESTORE BASH SETTINGS: c:\users\m0l3y\appdata\local\temp\RestoreSettingsWryeBash__2nkpl
barb.pyo  318 _restore_settings: My Games\Skyrim Special Edition\BashLoadOrders.dat --> D:\Documents\My Games\Skyrim Special Edition\BashLoadOrders.dat
barb.pyo  318 _restore_settings: My Games\Skyrim Special Edition\BashLoadOrders.dat.bak --> D:\Documents\My Games\Skyrim Special Edition\BashLoadOrders.dat.bak
barb.pyo  318 _restore_settings: My Games\Skyrim Special Edition\BashSettings.dat --> D:\Documents\My Games\Skyrim Special Edition\BashSettings.dat
barb.pyo  318 _restore_settings: My Games\Skyrim Special Edition\BashSettings.dat.bak --> D:\Documents\My Games\Skyrim Special Edition\BashSettings.dat.bak
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\Chinese (Simplified).txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Chinese (Simplified).txt
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\Chinese (Traditional).txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Chinese (Traditional).txt
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\de.txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\de.txt
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\Italian.txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Italian.txt
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\Japanese.txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Japanese.txt
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\pt_opt.txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\pt_opt.txt
barb.pyo  318 _restore_settings: Skyrim Special Edition\Mopy\bash\l10n\Russian.txt --> D:\Steam\steamapps\common\Skyrim Special Edition\Mopy\bash\l10n\Russian.txt
barb.pyo  318 _restore_settings: Skyrim Special Edition Mods\Bash Mod Data\Table.dat --> D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Mod Data\Table.dat
barb.pyo  318 _restore_settings: Skyrim Special Edition Mods\Bash Mod Data\Table.dat.bak --> D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Mod Data\Table.dat.bak
barb.pyo  318 _restore_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat --> D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat
barb.pyo  318 _restore_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat.bak --> D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Converters.dat.bak
barb.pyo  318 _restore_settings: Skyrim Special Edition Mods\Bash Installers\Bash\Installers.dat --> D:\Steam\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Bash\Installers.dat
barb.pyo  318 

Link to comment
Share on other sites

Controversially Fallout 4 when you issue the Restore Settings command, opens a browse dialogue where you would expect, in ..

D:\Steam\steamapps\Common\Fallout4 mods\Bash Mod Data\

So you have to browse to the SSE Location instead to go find the last saved ..

Link to comment
Share on other sites

.. But the actual restoration and restart, tickles my happy bone :) I have never seen that all work as it should before.

The bashbugdump.log (same as SSE) seems not quite finished :

 

Wrye Bash starting
Using Wrye Bash Version 307.201807251609 (Standalone)
OS info: Windows-10-10.0.17134
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Fallout 4\\Mopy\\Wrye Bash.exe', '--debug', '--restore', '--filename', 'c:\\users\\m0l3y\\appdata\\local\\temp\\RestoreSettingsWryeBash_4ejqg0', '--no-uac']
Using scandir 1.5
bash.pyo  398 _import_bush_and_set_game: Searching for game to manage:
bush.pyo   86 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   88 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   88 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  146 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  152 _detectGames: Set game mode to Fallout4 found in parent directory of Mopy:  D:\Steam\steamapps\common\Fallout 4
bush.pyo  167 __setGame:  Using Fallout4 game: D:\Steam\steamapps\common\Fallout 4
barb.pyo  309 _restore_settings: 
barb.pyo  310 _restore_settings: RESTORE BASH SETTINGS: c:\users\m0l3y\appdata\local\temp\RestoreSettingsWryeBash_4ejqg0
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\Chinese (Simplified).txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Chinese (Simplified).txt
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\Chinese (Traditional).txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Chinese (Traditional).txt
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\de.txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\de.txt
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\Italian.txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Italian.txt
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\Japanese.txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Japanese.txt
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\pt_opt.txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\pt_opt.txt
barb.pyo  318 _restore_settings: Fallout4\Mopy\bash\l10n\Russian.txt --> D:\Steam\steamapps\common\Fallout 4\Mopy\bash\l10n\Russian.txt
barb.pyo  318 _restore_settings: My Games\Fallout4\BashLoadOrders.dat --> D:\Documents\My Games\Fallout4\BashLoadOrders.dat
barb.pyo  318 _restore_settings: My Games\Fallout4\BashLoadOrders.dat.bak --> D:\Documents\My Games\Fallout4\BashLoadOrders.dat.bak
barb.pyo  318 _restore_settings: My Games\Fallout4\BashSettings.dat --> D:\Documents\My Games\Fallout4\BashSettings.dat
barb.pyo  318 _restore_settings: My Games\Fallout4\BashSettings.dat.bak --> D:\Documents\My Games\Fallout4\BashSettings.dat.bak
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Mod Data\Table.dat --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\Table.dat
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Mod Data\Table.dat.bak --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\Table.dat.bak
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Installers\Bash\Converters.dat --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Converters.dat
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Installers\Bash\Converters.dat.bak --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Converters.dat.bak
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Installers\Bash\Installers.dat --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Installers.dat
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Installers\Bash\Installers.dat.bak --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Installers\Bash\Installers.dat.bak
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Mod Data\INI Data\Table.dat --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\INI Data\Table.dat
barb.pyo  318 _restore_settings: Fallout4 Mods\Bash Mod Data\INI Data\Table.dat.bak --> D:\Steam\steamapps\common\Fallout4 Mods\Bash Mod Data\INI Data\Table.dat.bak
barb.pyo  329 _restore_settin

Link to comment
Share on other sites

6 hours ago, Desesperado said:

Hello everyone. I want to report a bug while trying to use Wrye Bash, for it would not even open. I am trying to get into a modded Skyrim once again, and I need Wrye Bash to make bashed patches. But after installing it and trying to open it, only the logo would successfully appear before an error message pops up. What am I doing wrong? I just want to play the game, modded as I did years ago.

 

The error message says to post, which you did thank you. You're question is simple, why doesn't it launch? However, that log doesn't tell me what version you have, or other information from the log file. Please provide that by following this link. I can't tell you why it doesn't start just from that message. On the nexus there is also a sticky post with some spoiler tags in it. You could try the first spoiler also. I wish there was a simpler step by step guide with screen shots for you. With that said before someone says it, no I don't have the time. I work with xEdit and have too much to do right now with all the updates.

Link to comment
Share on other sites

20 hours ago, Desesperado said:

Hello everyone. I want to report a bug while trying to use Wrye Bash, for it would not even open. I am trying to get into a modded Skyrim once again, and I need Wrye Bash to make bashed patches. But after installinf it and trying to open it, only the logo woild succesfully appear before an error message pops up. What am I doing wrong? I just want to play the game, modded as I did years ago.

 

This is the complete message, nothing is left aside:

 

Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://www.afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

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 4023, in InitData
  File "bash\bosh\__init__.pyo", line 1545, in __init__
  File "bash\bosh\__init__.pyo", line 1555, in ini
  File "bash\bosh\__init__.pyo", line 941, in BestIniFile
  File "bash\bosh\ini_files.pyo", line 61, in formatMatch
AttributeError: 'NoneType' object has no attribute 'open'

This has come up again and it's a bit spurious - please provide me the rest of info as @Sharlikran said - can you use the python version / If yes please use this one: https://github.com/wrye-bash/wrye-bash/archive/xxx-debug-ini.zip and start wrye in debug mode

-----

Thanks @alt3rn1ty - Bash will restart with debug on if it was started with debug on. Don't know why the bashdump is unfinished - did you shutdown normally and then opened it? The dump will flush in disk once every 4000 chars but should flush all contents on a normal shutdown. As per the directory - my guess is you once saved settings from Fallout4 into SSE folder - try saving (using the Backup Settings menu) into the Fallout folder (or a random one). This sets the dir on settings

Link to comment
Share on other sites

2 hours ago, Utumno said:

Don't know why the bashdump is unfinished - did you shutdown normally and then opened it?

Wrye Bash shuts down and restarts automatically as part of the Restore settings process

I have the BashBugDump.log open in Notepad++ while its all happening, and notepad++ auto reloads the BashBugDump when it detects changes, so the unfinished bug dumps are the last loaded just after the Wrye Bash auto-restart happens during the restore settings.

Will try manually saving in FO4, but as far as I remember I have always let Bash do its selection of settings locations automatically. Although, SSE was installed way before FO4, and FO4 installation of Wrye Bash was installed on top of a previous installation which was just for SSE, so maybe it has adopted the SSE settings save location ? .. Anyway will try a few things in due course (back on shifts again just now)

Link to comment
Share on other sites

On 7/26/2018 at 3:42 AM, Sharlikran said:

The error message says to post, which you did thank you. You're question is simple, why doesn't it launch? However, that log doesn't tell me what version you have, or other information from the log file. Please provide that by following this link. I can't tell you why it doesn't start just from that message. On the nexus there is also a sticky post with some spoiler tags in it. You could try the first spoiler also. I wish there was a simpler step by step guide with screen shots for you. With that said before someone says it, no I don't have the time. I work with xEdit and have too much to do right now with all the updates.

 

On 7/26/2018 at 12:52 PM, Utumno said:

This has come up again and it's a bit spurious - please provide me the rest of info as @Sharlikran said - can you use the python version / If yes please use this one: https://github.com/wrye-bash/wrye-bash/archive/xxx-debug-ini.zip and start wrye in debug mode

Alright, acording to the GitHub link Sharlikran posted before, here is what I managed to get (sadly, not everything, sorry):

Bug description: the only thing I tried to do was to open the recently installed Wrye Bash (Wrye Bash 307 Beta3 - Installer, from Nexus Mods) in order to see if it works. It is for a reinstaled Skyrim in Windows 7, outside Program files x86, no mods have been even downloaded yet. But as soon as the Wrye Bash logo appears on screen, a window pops up, showing this message, the same as I posted before:

----

Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://www.afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

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 4023, in InitData
  File "bash\bosh\__init__.pyo", line 1545, in __init__
  File "bash\bosh\__init__.pyo", line 1555, in ini
  File "bash\bosh\__init__.pyo", line 941, in BestIniFile
  File "bash\bosh\ini_files.pyo", line 61, in formatMatch
AttributeError: 'NoneType' object has no attribute 'open'

----

And this is what is inside the BashBugDump.log:

----

Wrye Bash starting
Using Wrye Bash Version 307.201807040057 (Standalone)
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('es_ES', 'cp1252')
filesystem encoding: mbcs
command line: ['C:\\Steam Library 2, para Skyrim\\steamapps\\common\\Skyrim\\Mopy\\Wrye Bash.exe', '-d']
Using scandir 1.5
bash.pyo  286 _main: Searching for game to manage:
bush.pyo   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   82 _supportedGames:  Skyrim: C:\Steam Library 2, para Skyrim\steamapps\common\Skyrim
bush.pyo   82 _supportedGames:  Fallout4: C:\Program Files (x86)\Steam\steamapps\common\Fallout 4
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to Skyrim found in parent directory of Mopy:  C:\Steam Library 2, para Skyrim\steamapps\common\Skyrim
bush.pyo  161 __setGame:  Using Skyrim game: C:\Steam Library 2, para Skyrim\steamapps\common\Skyrim
testing UAC
mods_metadata.pyo  230 __init__: Using LOOT API version: 0.13.2
Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://www.afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

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 4023, in InitData
  File "bash\bosh\__init__.pyo", line 1545, in __init__
  File "bash\bosh\__init__.pyo", line 1555, in ini
  File "bash\bosh\__init__.pyo", line 941, in BestIniFile
  File "bash\bosh\ini_files.pyo", line 61, in formatMatch
AttributeError: 'NoneType' object has no attribute 'open'

----

Shall I try to use the Standalone executable found in the Wrye Bash nexus page? perhaps, in the humble opinion from this non-informatics-skilled peasant, the problem is in the Python version that I have, or around it. I am not planning in modding the game, just play with mods and pake a bashed patch for leveled lists in game. Also, I don't know how to install the Wrye Bash xxx Debug that Utumo provided me. Iidentified the Mopy folder as the one that must be placed in the Skryrim game directory, but I don't know what to do with the other things, the scrip folder and the other files.

I hope that this bug is nothing too serious and I am sorry if I didn' manage to write down in this post everything that is needed to solve it. Thanks in advance for your time, anyway.

BashBugDump.log

Link to comment
Share on other sites

@Desesperado please use:

307.201807281453

and post me the bugdump - I need to get to the bottom of this one

Link for these "nightly" builds is always in the second post here

Link to comment
Share on other sites

1 hour ago, Utumno said:

@Desesperado please use:


307.201807281453

and post me the bugdump - I need to get to the bottom of this one

Link for these "nightly" builds is always in the second post here

Where do I get that version (307.201807281453)? It is not in the Nexus page, only the 307.Beta3. If it is somewhere else, please tell me where do I get that Wrye Bash version. Also, if yoy want the bugdump.log, I already posted it in my previous post; if it is the bugdump of the version you ask, well, I need the place to download it.

 

19 hours ago, Desesperado said:

 

And this is what is inside the BashBugDump.log:

----

Wrye Bash starting
Using Wrye Bash Version 307.201807040057 (Standalone)
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('es_ES', 'cp1252')
filesystem encoding: mbcs
command line: ['C:\\Steam Library 2, para Skyrim\\steamapps\\common\\Skyrim\\Mopy\\Wrye Bash.exe', '-d']
Using scandir 1.5
bash.pyo  286 _main: Searching for game to manage:
bush.pyo   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   82 _supportedGames:  Skyrim: C:\Steam Library 2, para Skyrim\steamapps\common\Skyrim
bush.pyo   82 _supportedGames:  Fallout4: C:\Program Files (x86)\Steam\steamapps\common\Fallout 4
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to Skyrim found in parent directory of Mopy:  C:\Steam Library 2, para Skyrim\steamapps\common\Skyrim
bush.pyo  161 __setGame:  Using Skyrim game: C:\Steam Library 2, para Skyrim\steamapps\common\Skyrim
testing UAC
mods_metadata.pyo  230 __init__: Using LOOT API version: 0.13.2
Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://www.afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

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 4023, in InitData
  File "bash\bosh\__init__.pyo", line 1545, in __init__
  File "bash\bosh\__init__.pyo", line 1555, in ini
  File "bash\bosh\__init__.pyo", line 941, in BestIniFile
  File "bash\bosh\ini_files.pyo", line 61, in formatMatch
AttributeError: 'NoneType' object has no attribute 'open'

 

BashBugDump.log

 

And what do you mean with "Link for these "nightly" builds is always in the second post here"? I really don't know.

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