Wrye Bash - All Games

[Sharlikran]

Just keep in mind while I agree with Arthmoor that not making a Bash Patch when the Form Version isn't 44 should occur, it's simply not possible. What users will do is just not use the new version because the Bash Patch will never build. There are two reasons for this.

1) Some people use Skyrim mods that have not been converted to Skyrim SE. I'm pretty sure many authors no longer even visit the Nexus let alone look at their mods. Also some mods on the SE Nexus require old Skyrim mods because the author doesn't have permission to host the assets such as the textures or meshes because the author can't be reached.

2) Mod authors feel it's up to them how they manage their mod.  Some know that the old plugin style is recognized and will work with Skyrim SE.

Mod authors should do as Arthmoor says, but forcing this upon them will (not maybe) will cause discontent and I can pretty much guarantee it. I can guarantee it because authors do not even wish to use Framework mods such as SKE for Fallout 4 or use scripted menus if they don't want to.  If Wrye Bash prevents or restricts the ability to build a Bash Patch causing users to complain to the author then the author will simply state he doesn't care and tell people not to comment on it.  Try it if you want, but I really doubt it will matter. I even offered Trainwiz an updated mod and he didn't want it. I even asked before offering it, but he never used it.

Skyrim SE can use oldrim files because it is made to recognize them. If a file is converted from Skyrim to SkyrimSE and contains records that changed, then the Form Version matters, and the state of the plugin matters. The state meaning that the author has verified it with SSEEdit and made sure FormIDs from records that changed were shifted to their new location properly by the SE CK.

[zilav]

The thing is, the vast majority of records in vanilla files (Skyrim.esm and DLCs) are NOT form version 44. Don't quote me, but I think that the problem with existing plugins and bashed patch comes from:

1) They always must have version 44 in TES4 header because all vanilla files do.

2) Don't override records having newer version by records with older ones because vanilla files don't do that.

That's why I already said before: make bashed patch have version 44 in the TES4 header and for other records use the version from the current winning override when bashing or forcefully convert all of them to 44 to ensure that they are always newer.

[Sharlikran]

Just now, zilav said:

 

or forcefully convert all of them to 44 to ensure that they are always newer.

This is what Wrye Bash always does. It never reads the old format and saves the old format.  Lojack even told me to always use the current record format.  Wrye Bash always reads the record and writes it in the current format.

[Arthmoor]

6 hours ago, Sharlikran said:

Do you actually have a crash when you have the Bash Patch active Arthmoor? For oldrim, gromulos said when he loads two mods, Cerwiden and Skyrim Redone that 307 will cause a crash. I went through it with him and could not reproduce the error. Which is why I would like to have people that actually have this issue contact me. Because if I can't reproduce it with the mods they suggest, then it's not happening because of Bash it's happening for other reasons.

No, the game does not crash, but things go very wonky. AI packs don't engage properly, stuff comes up with weird errors in the displays (and no, it's not an SKSE or SkyUI bug), NPCs will go outright missing, parts of certain areas will not render correctly, and so on. CTDs are possible, sure, but they haven't been an issue whenever I've built a patch. The issues also all go away immediately upon removing the patch, so this isn't some random speculation as you hinted at. Honestly, if it isn't enough that I am relaying their reports to be dealt with, then I'm going to question why I bother to bring these things up and all and begin to wonder if the community simply wishes to remain in ignorance about these issues. It certainly comes across as obstructionist when you refuse to accept there's even a problem just because nobody is personally reporting it directly to you.

3 hours ago, RavenMind said:

Good info Arthmoor & Sharlikran! So, correct me if I'm wrong, we do know that building a bashed patch with an improperly converted mod will, or likely will, cause unexpected behavior and possible corruption. Right? If this is the case then I think the most pressing concern would be to alert people on Nexus and perhaps the other download locations. We don't want people blaming Bash for problems caused by poor modding practices. Then, or concurrently, you coding gurus can have at the technical aspect of the Form versions and the patcher.

 

Just the act of building the patch alone is enough. The patch itself is the source of the issue when it exists, even when all other mods in the load order are form 44. Things only get worse when there are unported mods thrown into the mix.

3 hours ago, Sharlikran said:

Just keep in mind while I agree with Arthmoor that not making a Bash Patch when the Form Version isn't 44 should occur, it's simply not possible. What users will do is just not use the new version because the Bash Patch will never build. There are two reasons for this.

1) Some people use Skyrim mods that have not been converted to Skyrim SE. I'm pretty sure many authors no longer even visit the Nexus let alone look at their mods. Also some mods on the SE Nexus require old Skyrim mods because the author doesn't have permission to host the assets such as the textures or meshes because the author can't be reached.

2) Mod authors feel it's up to them how they manage their mod.  Some know that the old plugin style is recognized and will work with Skyrim SE.

Mod authors should do as Arthmoor says, but forcing this upon them will (not maybe) will cause discontent and I can pretty much guarantee it. I can guarantee it because authors do not even wish to use Framework mods such as SKE for Fallout 4 or use scripted menus if they don't want to.  If Wrye Bash prevents or restricts the ability to build a Bash Patch causing users to complain to the author then the author will simply state he doesn't care and tell people not to comment on it.  Try it if you want, but I really doubt it will matter. I even offered Trainwiz an updated mod and he didn't want it. I even asked before offering it, but he never used it.

Skyrim SE can use oldrim files because it is made to recognize them. If a file is converted from Skyrim to SkyrimSE and contains records that changed, then the Form Version matters, and the state of the plugin matters. The state meaning that the author has verified it with SSEEdit and made sure FormIDs from records that changed were shifted to their new location properly by the SE CK.

Ignoring the problem because people insist on using improperly ported mods is no excuse. If users are truly this hell bent on playing with corruption as a matter of routine, then let them, but don't contribute to the problem either.

Mod authors felt it was up to them to decide how to handle using Snip too. Should we have simply accepted it when they openly lied about that? They insisted then that there was no damage being done and that it was a smear campaign against the tool. Those same people are the ones now claiming there is no issue with Form 43 being used in SSE, but they are as wrong now as they were with Snip. The game simply does not treat it properly and that's pretty damned simple to validate. Grab a bunch of LE mods, install them into SSE, and go see the results for yourself. You don't need runtime debugging logs and video backup evidence to prove to yourself it happens. Just play. When your game shits itself, and it will, then you'll know.

2 hours ago, Sharlikran said:

This is what Wrye Bash always does. It never reads the old format and saves the old format.  Lojack even told me to always use the current record format.  Wrye Bash always reads the record and writes it in the current format.

If this is true, then the bashed patch would not be the source of problems in SSE because it would always be writing properly formatted Form 44 records into the patch. This isn't what's happening though. The SSE bashed patch I have right here in my folder right now is taking form versions from Skyrim.esm and using them in every record it contains, even if something in between Skyrim.esm and the patch has a more recent form version. So it's definitely NOT a sound thing to be doing. Which is why this either needs to be corrected properly, with proper warnings against broken mods, or the build process needs to be entirely disabled for SSE so that no patch can be generated until such time as someone fixes the problem.

[RavenMind]

Thanks Arthmoor. I learned more in that one post than in 3 hours of reading! I hope it doesn't come to telling SSE users to not build Bashed Patches entirely, but something probably ought to be posted soon. Yeesh, glad I've been sticking to helping Oblivion players!

Well, it's past my bedtime. Have a good night.

[Sharlikran]

1 hour ago, Arthmoor said:

You don't need runtime debugging logs and video backup evidence to prove to yourself it happens. Just play. When your game shits itself, and it will, then you'll know.

 

I have played and I don't have issues.  That wasn't necessary.  I didn't say anything like that to you.

1 hour ago, Arthmoor said:

It certainly comes across as obstructionist when you refuse to accept there's even a problem just because nobody is personally reporting it directly to you.

Those same people are the ones now claiming there is no issue with Form 43 being used in SSE, but they are as wrong 

If this is true, then the bashed patch would not be the source of problems in SSE because it would always be writing properly formatted Form 44 records into the patch. This isn't what's happening though. The SSE bashed patch I have right here in my folder right now is taking form versions from Skyrim.esm and using them in every record it contains, even if something in between Skyrim.esm and the patch has a more recent form version. So it's definitely NOT a sound thing to be doing. Which is why this either needs to be corrected properly, with proper warnings against broken mods, or the build process needs to be entirely disabled for SSE so that no patch can be generated until such time as someone fixes the problem.

Arthmoor that's not what I mean. I mean how it's written, the size of the record, it's contents, not the value of the Form Version field. 

Anyway good luck with things, I hope the addition of the Form Version resolves your unexplained issues.  This is not appropriate.  Never mind.  I thought I could discuss this.

[Beermotor]

Thank you everyone for replying with info. That's exactly what I was curious about.  

As @Sharlikran said I'm looking at this from a 10,000 foot view through the eyes of a technical project lead/manager.  I'm not claiming that role with WB but perhaps my perspective is helpful.

Ultimately we would not be having any of this discussion if there was not a problem with the game itself. I believe Bethesda originally intended on SSE to be able to read LE plugins (and to a certain extent saves) without conversion in an attempt to maintain backwards compatibility as much as possible.

I think it is very reasonable to assume that the fact that this v43 thing is even an issue is because it is a bug in SSE and needs to be reported to Bethesda. 

However, before we report it as a bug, we need clear evidence, reproduction steps, and to very accurately define the problem(s). 

To wit:

• We need to define the problem in technical terms.  We should collect all of the things that have been observed and define them as precisely as possible. We need to say "actors do not respect X value while Y script is active" rather than "NPCs act weird". 
• We need do to the above for every separate issue old plugins cause.
• An example plugin or number of plugins that are known and verified to cause problems. I know we have evidence that it can be any Oldrim plugin, but we need to have a exact set of example plugins we can report to Bethesda and say "these plugins when used together cause the problem". This isn't to blame specific plugins, this is so they can reproduce it in their "lab".
• All necessary steps to replicate the problem.
• Any other evidence (save games, videos, screenshots, etc) that capture the behavior. The more the better.

If we can do this the best that can happen is Bethesda fixes the bug and all of this is no longer an issue.  They could also come back and explain exactly (technically) how these plugins and records are handled by the SSE engine.

Worst-case scenario they ignore it, however I think if the general SSE player base knew about it and saw proof of it happening, there would be a fairly nasty stink raised over it.

 

 

[lmstearn]

The engine handles form versions of record types differently. In LE there's dialog issues and issues with ambushes in that thread. It's certainly something that comes through working with the CK more so than with the game.

It will be be looked into this thread to a certain degree, but suffice to say- in modding SSE it would be best to avoid importing a subset of older mods unless the versioning issue has been resolved.

[Utumno]

7 hours ago, zilav said:

The thing is, the vast majority of records in vanilla files (Skyrim.esm and DLCs) are NOT form version 44. Don't quote me, but I think that the problem with existing plugins and bashed patch comes from:

1) They always must have version 44 in TES4 header because all vanilla files do.

2) Don't override records having newer version by records with older ones because vanilla files don't do that.

That's why I already said before: make bashed patch have version 44 in the TES4 header and for other records use the version from the current winning override when bashing or forcefully convert all of them to 44 to ensure that they are always newer.

So writing the damn 44 into the TES4 record would suffice ?

Technically  that code is pre yours truly - aka pre refactored - aka a mess. That's what makes stuff difficult to patch.

I can't go through walls of posts @ everybody, so if I missed something technical please post it to the issue 342 - short, sweet and technical please.

[darksynth0]

I have a very nasty problem. 
Nothing helps.

Symptoms:

I moved to Windows 10 since I brought Skylake CPU and it requires Win10 to work as intended.
So I reinstalled skyrim SSE, downloaded latest version of wrye (tried 307), installed into SSE, launched through MO, nothing.

bash crashes (not even splash windows appear) with:

testing uac
or folder wryebash_*random letters and numbers" (in appdata local temp) is in use by someone else
or when writing some _temp file in SSE directory; it can't be overwritten.

also tried:
306, wip 307, standalone, python, installing to MO, installing into SSE directory.

Tried all from forcing UAC off via registry, windows file control via registry, setting non-read only folders and giving admin privileges to ALL of executable related, nothing ever helps.
Tried python, standalone, non-standalone, all methods..

it all comes down to the damn temp folder in APP DATA (temp).

launches outside of MO FINE!!!!

testing UAC
Traceback (most recent call last):
File "Wrye Bash Launcher.pyw", line 88, in <module>
File "bash\bash.pyo", line 370, in main
File "bash\env.pyo", line 563, in testUAC
File "bash\bolt.pyo", line 897, in rmtree
File "shutil.pyo", line 256, in rmtree
File "shutil.pyo", line 254, in rmtree
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'c:\\users\\lan-ri~1\\appdata\\local\\temp\\WryeBash_nbnqsf'
report posted @ 19:30, 25 Oct 2017 Reply | Edit
 
I turned off windows defender, don't havy any other AV, UAC turned off, all privelegies given..
seriously F*&**K windows 10..

it worked flawlessly in Windows 7
https://imgur.com/a/OzlyF

tried both methods:

https://github.com/wrye-bash/wrye-bash/issues/387
http://forum.step-project.com/topic/12328-wryes-bash-wont-run-from-inside-mo2/page-4#entry209686

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-10-10.0.16299
Python version: 2.7.14
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252'
filesystem encoding: mbcs
bash.py 316 _main: Searching for game to manage:
bush.py 76 _supportedGames: Detected the following supported games via Windows Registry:
bush.py 78 _supportedGames: Skyrim Special Edition: M:\SteamLibraryMODS\steamapps\common\Skyrim Special Edition
bush.py 136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py 142 _detectGames: Set game mode to Skyrim Special Edition found in parent directory of Mopy: M:\SteamLibraryMODS\steamapps\common\Skyrim Special Edition
bush.py 156 __setGame: Using Skyrim Special Edition game: M:\SteamLibraryMODS\steamapps\common\Skyrim Special Edition
mods_metadata.py 40 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC

UAC is totally destroyed:
https://imgur.com/a/b8xUQ

also tried to apply registry tweak... but to no avail

hope someone can help..

[Sharlikran]

We don't use MO.  It's posted on the Nexus that's it's not supported with MO or MO2. That doesn't mean you can get it to work but we wouldn't know how to do that. Just trying to be as polite as possible, but how could we suggest to you what to set up or change when we have never used the program?

For just MO with old Skyrim I'd ask here.

For MO2 with Skyrim SE I'd ask here.

[Arthmoor]

3 hours ago, Utumno said:

So writing the damn 44 into the TES4 record would suffice ?

Technically  that code is pre yours truly - aka pre refactored - aka a mess. That's what makes stuff difficult to patch.

I can't go through walls of posts @ everybody, so if I missed something technical please post it to the issue 342 - short, sweet and technical please.

No, it would not be sufficient to just write the header with a 44 in the slot. The records also have to be the correct version 44 format or it means nothing. That means the TES4 header AND all of the records the patch is creating must be of the correct version and format to match that version.

[Sharlikran]

Just now, Arthmoor said:

No, it would not be sufficient to just write the header with a 44 in the slot. The records also have to be the correct version 44 format or it means nothing. That means the TES4 header AND all of the records the patch is creating must be of the correct version and format to match that version.

The records always write out the current format and size according to TES5Edit source. The only thing that has ever been missing is simply the Form Version number, that's it. It's just never been assigned the the proper variable to be written to the file.

[Sharlikran]

Do you use the Python source code or the EXE?

[Arthmoor]

22 minutes ago, Sharlikran said:

The records always write out the current format and size according to TES5Edit source. The only thing that has ever been missing is simply the Form Version number, that's it. It's just never been assigned the the proper variable to be written to the file.

If that's the case it would certainly explain why the bashed patch causes problems so much faster than the opposite where form 43 mods lead to the same results.

15 minutes ago, Sharlikran said:

Do you use the Python source code or the EXE?

If you're asking me this, I'm using the bleeding edge code from the second post. Source code.

[Sharlikran]

Yes I was asking you.  If you would like to test this, it will do what you are asking. That is what I had submitted previously. Utumno had some concerns and opted not to use the code as it was presented. That also includes support for the change to AMMO because Bethesda added weight, and SPGD because Bethesda finally fixed SPGD so the CK now saves it correctly.

[alt3rn1ty]

Well its Utumno's baby who has not commented with regards to my questions on whether to put an advisory note up on nexus .. So I will refrain from doing so.

I wont be around for a couple of weeks, my better half and I are off for a bit of fun in the sun to celebrate our anniversay 

Hope you all behave while I'm away .

[Sharlikran]

Yes enjoy your anniversary. Mine is this month as well but my wife and I have different schedules and haven't found a good alternate date that fits our complicated schedules.

[Utumno]

8 minutes ago, alt3rn1ty said:

Well its Utumno's baby who has not commented with regards to my questions on whether to put an advisory note up on nexus .. So I will refrain from doing so.

I wont be around for a couple of weeks, my better half and I are off for a bit of fun in the sun to celebrate our anniversary

Hope you all behave while I'm away .

And a happy anniversary from the baby - I missed what you talk about nexus ?

[Sharlikran]

@Beermotor You can test that code I made for @Arthmoor  also if you want to test it. I don't know what tests to do because I don't have the issues. The only thing you can't do is you can't merge the old Skyrim format for the records that Bethesda changed unless they are already the proper format for Skyrim SE. I added error checking at the beginning even during the testing phase for my pre-alpha. So you won't be able to merge LTEX, MATO, MOVT, STAT, WATR, WEAP, WTHR.  That error checking was added Nov 3 2016, in this commit. So it's been that way for a while. I think you noticed that error already though.

Now to clarify, you can merge those if they have been saved with the Skyrim SE CK first.

[RavenMind]

@Utumno This info is what alt3rn1ty was refering to about Nexus. Basically issuing a PR statement/warning about building Bashed Patches for SSE with Form 43 records &/or improperly ported mods. I tried to just post the most relevant info for you to keep it as short a read as possible. Still wound up long, but at least it's in one spot. Full posts are linked to.

alt3rn1ty: Full Post

On 10/24/2017 at 2:59 PM, alt3rn1ty said:

The effects of this issue are quite bad from what I have read. And yet we have a Bashed Patch that once it has been rebuilt, is coming up with the wrong form version aswell adding to the issues?...

So shouldn't we be more up front about this, considering its likely to take a while before it is resolved in Wrye Bash, a small note on Skyrim SE nexus (and Fallout 4 aswell ?? or is it just SSE) along the lines of :

Quote

"Advisory Note - All users of Skyrim SE Wrye Bash, are advised not to use the Bashed Patch until further notice (De-select it and do not rebuild it). There is an issue whereby plugins with a form version in the plugin header of 43 is Old Skyrim form version, and if not ported properly to Skyrim SE using the newer CK will not be converted to form version 44, which it should be. Wrye Bash is producing a Bashed Patch after rebuilding, with incorrect form versioning (which it has never had to cope with before this games changes to plugin headers came along) .. Which along with improperly converted mods, we believe will in the long term cause corruption to start occurring in your ongoing game, which may well reject your saves at some point.

Aswell as ceasing to use the Bashed Patch until Skyrim SE Wrye Bash has been programmed to take care of this emerging issue - Take a look at all of your mods plugins with SSEEdit 3.2.1, expand the header, and look for form version 44. If its 43 instead the mod needs converting properly to Skyrim SE and the mod author should be notified the plugin is not fit for use in SSE.

We regret that a new game start would be also well advised, but could not have anticipated this problem."

 

@Utumno, @Arthmoor, @zilav, @WrinklyNinja, @Sharlikran - Do you think the above is an appropriate course of action currently ?. Or have I blown this a bit out of proportion. As far as I have seen, it seems to me that the bashed patch is potentially contributing to a lot of peoples problems currently. I realise we should also be advising that everyone affected should also start a new game entirely, to ensure they get rid of baked in save problems this may have also caused. So its a bit of a bad situation for many...

Arthmoor: Post 1, Post 2

On 10/24/2017 at 3:06 PM, Arthmoor said:

I don't think you've blown this out of proportion at all and IMO we need to do an update on Nexus with a version that's current that either disables the patch function entirely or fixes the form version issue. The longer we let this go, the more people are going to get bit by it because they won't use dev versions. If ever there was a blocker, this bug is it.

It's only needed on SSE btw. Fallout 4 has only ever had one form version and there's been no evidence that patches built for that game are causing problems.

{and}

As for the verbiage of the warning, I don't think anyone could ever have reasonably expected Bash to fix the issue, so I'm not sure we need to specify that we aren't responsible for doing so...  ...So I'd simply mention that there is sufficient evidence to confirm that improperly ported mods will cause problems and that mod authors need to be responsible for fixing the issue the correct way. Bash should then abort and refuse to build the patch because IMO it would be bad for us to continue past such a warning and contribute to the very problem we seek to solve.

Beermotor: Post 1, Post 2

On 10/24/2017 at 7:38 PM, Beermotor said:

I agree with @Arthmoor that you're not blowing this out of proportion but I think we need more information before we make any move. Don't worry though, I'll help get the information.

Quote

From RavenMind:  I assume if it were as simple as WB recognizing a plugin with Form Version 43 in the header, then refusing to build a patch, perhaps with an error stating why, that it would already have been considered/implemented? Guessing there's something preventing that from happening?

That's actually a great idea and I'm all for it. Yes Bash needs the patcher updated, but lazy mod authors is the absolute root cause of the issue.

{and}

So regarding outreach Ok how about this verbiage for the outreach:

Quote

Due to the way the Bashed Patcher functions, any unconverted or improperly ported Skyrim plugins could potentially have their old form version 43 records copied into the Bashed Patch.  For those who are not aware, there is a growing corpus of evidence showing a correlation between unexpected behavior and/or corruption and improperly ported Skyrim (2011) plugins when used in Skyrim Special Edition.

It is not the responsibility of the Bashed Patcher to do on-the-fly conversions of unconverted mods. If you choose to play with invalid plugins, you assume all risk incurred as a result of this decision. Please be aware that the Wrye Bash team cannot and will not support the use of SSE Bashed Patches created with Skyrim LE plugins.

 

RavenMind: Full Post

19 hours ago, RavenMind said:

As for the warning...

...I would also remove mention of Form versions. People don't need to know exactly what the problem is, just that they shouldn't Bash Patch LE mods or bad conversions. Those that do want to know exactly what the problem is can easily find their way here. This is what I would say:

Quote

Warning: There is mounting evidence showing that improperly ported/converted Skyrim LE (2011) plugins may lead to unexpected behavior and/or corruption. Bashed Patches should not be built with these mods. It is the mod author's responsibility to ensure that their mods are correctly converted for use with SSE. Please check with the author if you have any doubts.  If you choose to play with invalid plugins, you assume all risk incurred as a result of this decision. Please be aware that the Wrye Bash team cannot and will not support the use of SSE Bashed Patches created with Skyrim LE plugins.

I think this helps push the responsibility of properly porting mods squarely back on the shoulders of the authors that release them, and encourages users to inquire about their mods from the correct people. Plus Beermotor's wording eschews the WB team of responsibility for resulting corruption without making it look like you've got something to hide, and his last sentence brings to light that LE mods shouldn't be incorporated into the Bashed Patch. Something I think some (or many) people may not be aware of. Hopefully it's short enough people might actually read it.

{My apologies to everyone for cutting up your posts. This was done in an attempt at brevity. I linked to the originals, and if you feel I've removed anything important, please let me know.)

[RavenMind]

On 10/25/2017 at 1:16 PM, alt3rn1ty said:

Well its Utumno's baby who has not commented with regards to my questions on whether to put an advisory note up on nexus .. So I will refrain from doing so.

LOL, Utumno, I think he meant that WB is your "baby", not that YOU are a baby.

 

On 10/25/2017 at 1:16 PM, alt3rn1ty said:

I wont be around for a couple of weeks, my better half and I are off for a bit of fun in the sun to celebrate our anniversay 

Hope you all behave while I'm away .

 

@alt3rn1ty Happy Anniversary! I hope you two have a great time! And you should definitely MISbehave.

[Supierce]

Utumno, the latest WIP works fine with FO4, but when I try to open it for Oblivion, I get the following traceback:

	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.py", line 260, in main
    _main(opts)
  File "bash\bash.py", line 425, in _main
    app.Init() # Link.Frame is set here !
  File "bash\basher\__init__.py", line 3996, in Init
    self.InitData(progress)
  File "bash\basher\__init__.py", line 4034, in InitData
    bosh.modInfos = bosh.ModInfos()
  File "bash\bosh\__init__.py", line 1783, in __init__
    FileInfos.__init__(self, dirs['mods'], ModInfo)
  File "bash\bosh\__init__.py", line 1310, in __init__
    self._initDB(dir_)
  File "bash\bosh\__init__.py", line 1391, in _initDB
    super(FileInfos, self)._initDB(dir_)
  File "bash\bosh\__init__.py", line 1305, in _initDB
    bolt.PickleDict(self.bash_dir.join(u'Table.dat')))
  File "bash\bolt.py", line 1702, in __init__
    dictFile.load()
  File "bash\bolt.py", line 1498, in load
    with path.open('rb') as ins:
  File "bash\bolt.py", line 909, in open
    return open(self._s,*args,**kwdargs)
IOError: [Errno 13] Permission denied: u'C:\\Bethesda Softworks\\Oblivion Mods\\Bash Mod Data\\Table.dat'

At that point, WB laundhes a window that says, 'Initializing ModInfos', which can't be closed without rebooting my computer.

As always, let me know what you  need. Thank you! 

[RavenMind]

@Supierce Hmm, I'm not getting that behavior. I've used both the "nightly" v307.201710222147 Python Source, and the "WIP" wrye-bash-utumno-wip.zip, folder CRC= 40F0F2EE. Launched in Debug Mode with just Oblivion.esm currently installed. Used WB to install all the DLC, Unofficial Patches, and some OBSE mods. I installed/uninstalled a couple mods with wizards, and rebuilt my BP with CBash & PBash with various options. Launched OB through WB just fine. Nothing of significance in my BashBugDump. I also was able to launch via Wrye Bash Launcher.pyw without trouble. When installing the WIP, I deleted everything out of my Mopy folder (as you kindly suggested previously), and then readded my Apps folder, bash.ini & LOOT. I did not delete any Table.dat's, or anything from \Oblivion Mods. *shrug*

[Leonardo]

If I may chime in here, @RavenMind do you have FO4 installed?  If not then maybe that's why @Supierce get an error when launching WB.