Wrye Bash - All Games

[Beermotor]

1 hour ago, Arthmoor said:

What "very latest" WIP are we talking about here?

Utumno released a new WIP build overnight/early this morning US time that fixed the issue for me on both my laptop and desktop machine.

The version producing the bugcheck was dated 10/4 and this one is dated 10/6.

[RavenMind]

I haven't braved the Python version since an utterly failed attempt with Wrye Mash years ago. If I were to try the nightly "wrye-bash-utmno-wip.zip", is that something I need to first use a Python compiler on? Sorry if this is a stupid question, my only programming experience is limited to Intro to Java at the good ol' community college..

Edit: Okay, I got the Python version of 307.201709160706 working. I tried copying the contents of the \Mopy folder from "wrye-bash-utmno-wip.zip" over the existing Python install. It launches fine, but the version number at the top just says 307, and it's not able to import settings from the previous version. I have no idea what to do with the .md, .gitattributes files in the root directory, or the contents of the scripts directory. Does this need to be 'built' somehow? I've looked all over for documentation, but can't seem to find anything. Sorry I'm not as up-to-speed as you guys.

[Beermotor]

5 hours ago, RavenMind said:

I haven't braved the Python version since an utterly failed attempt with Wrye Mash years ago. If I were to try the nightly "wrye-bash-utmno-wip.zip", is that something I need to first use a Python compiler on? Sorry if this is a stupid question, my only programming experience is limited to Intro to Java at the good ol' community college..

Edit: Okay, I got the Python version of 307.201709160706 working. I tried copying the contents of the \Mopy folder from "wrye-bash-utmno-wip.zip" over the existing Python install. It launches fine, but the version number at the top just says 307, and it's not able to import settings from the previous version. I have no idea what to do with the .md, .gitattributes files in the root directory, or the contents of the scripts directory. Does this need to be 'built' somehow? I've looked all over for documentation, but can't seem to find anything. Sorry I'm not as up-to-speed as you guys.

No those aren't used for regular use in the Python version. They are part of the GitHub repository, specifically Utumno's branch, and are used to build new releases. You did the right thing by copying the Mopy folder in that one over your existing Mopy folder, although I'm not sure why you can't restore settings.

[Supierce]

7 hours ago, RavenMind said:

Edit: Okay, I got the Python version of 307.201709160706 working. I tried copying the contents of the \Mopy folder from "wrye-bash-utmno-wip.zip" over the existing Python install. It launches fine, but the version number at the top just says 307, and it's not able to import settings from the previous version. I have no idea what to do with the .md, .gitattributes files in the root directory, or the contents of the scripts directory. Does this need to be 'built' somehow? I've looked all over for documentation, but can't seem to find anything. Sorry I'm not as up-to-speed as you guys.

Instead of copying the new Mopy folder over the old one, you should delete or empty the old one first, to clear out whatever's not in the new version.

[RavenMind]

Thanks to you both. I cleared out the old Mopy folder & copied the new one in. Started up with the Debug.bat, and am still showing version 307 (as opposed to the normal 307.2017xxx..), and still getting errors trying to restore settings from 307.201709160706. Here's a link to screenshots of the errors, if it's in any way useful. I'll post the bugdump in a spoiler below. The only things that I'm noticing there are "Using Wrye Bash Version 307", "OS info: Windows-8-6.2.9200" (I'm on Win10), and "Failed to import the loot_api module: (No module named loot_api)"

Sorry to take up peoples time here with this. I know it's not an official release, so I'm not expecting support, and am happy to wait for it to get packed into the Dropbox link if need be. Thanks again!

Spoiler

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-8-6.2.9200
Python version: 2.7.10
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
bash.py  324 main: Searching for game to manage:
bush.py   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   78 _supportedGames:  Oblivion: c:\users\chuck\games\oblivion
bush.py  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  142 _detectGames: Set game mode to Oblivion found in parent directory of Mopy:  C:\Users\Chuck\Games\Oblivion
bush.py  156 __setGame:  Using Oblivion game: C:\Users\Chuck\Games\Oblivion
mods_metadata.py   40 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC

 

As a side note, I noticed with the Python version that I'm unable to run it as Administrator. When I was in the registry to change the default icon for Wrye Bash Launcher.pyw to use  bash.ico, I noticed .py, .pyc, .pyo, & .pyw files are listed in a key called FileLaunchElevationBlockList under HKLM. I assume this is a Windows attempt to keep malware from getting elevated permissions, but is this normal behavior?

Edit: Just added the loot_api.dll & loot_api.pyd files from the 307.201709160706 archive, and now it's loading the loot_api module fine.

[Beermotor]

17 minutes ago, RavenMind said:

Thanks to you both. I cleared out the old Mopy folder & copied the new one in. Started up with the Debug.bat, and am still showing version 307 (as opposed to the normal 307.2017xxx..), and still getting errors trying to restore settings from 307.201709160706. Here's a link to screenshots of the errors, if it's in any way useful. I'll post the bugdump in a spoiler below. The only things that I'm noticing there are "Using Wrye Bash Version 307", "OS info: Windows-8-6.2.9200" (I'm on Win10), and "Failed to import the loot_api module: (No module named loot_api)"

Sorry to take up peoples time here with this. I know it's not an official release, so I'm not expecting support, and am happy to wait for it to get packed into the Dropbox link if need be. Thanks again!

  Reveal hidden contents

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-8-6.2.9200
Python version: 2.7.10
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
bash.py  324 main: Searching for game to manage:
bush.py   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   78 _supportedGames:  Oblivion: c:\users\chuck\games\oblivion
bush.py  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  142 _detectGames: Set game mode to Oblivion found in parent directory of Mopy:  C:\Users\Chuck\Games\Oblivion
bush.py  156 __setGame:  Using Oblivion game: C:\Users\Chuck\Games\Oblivion
mods_metadata.py   40 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC

 

As a side note, I noticed with the Python version that I'm unable to run it as Administrator. When I was in the registry to change the default icon for Wrye Bash Launcher.pyw to use  bash.ico, I noticed .py, .pyc, .pyo, & .pyw files are listed in a key called FileLaunchElevationBlockList under HKLM. I assume this is a Windows attempt to keep malware from getting elevated permissions, but is this normal behavior?

I'm glad you posted that because I ran into that exact same error the other day when I was testing. How I ended up fixing it was to install the Sept 16 build from Dropbox, restored the backup, then installed the latest Python version on top of it. 

The reason you are seeing the LOOT API error is probably because 'loot_api.dll" and"loot_api.pyd" may be missing from your Mopy folder. Those two files are not updated as often as the rest of the files (they are actually from December 2016) so you should be good to keep them around between updates until the LOOT API update is completed after Beta 2.

Hopefully that's helpful and if I missed anything hopefully someone will correct me.

[RavenMind]

Yes, very helpful, thank you!

Is yours saying "Wrye Bash 307, CBash..." in the title bar as well? I thought since it's not displaying a longer version number that I did something wrong. If it's just a display thing, that's fine, I'll just run under the assumption that it's the latest nightly.

[Sharlikran]

Spoiler

unbound method loadData() must be called with MelStructs instance as first argument (got MreWthr instance instead)
Error loading 'WTHR' record and/or subrecord: 02029E89
  eid = u'CoTClear_5_TU'
  subrecord = 'DALC'
  subrecord size = 32
  file pos = 2843
Error in Vividian - Weather Patch CoT.esp
parsers.py 4015 load:  
Traceback (most recent call last):
  File "bash\parsers.py", line 4009, in load
    self.tops[label].load(ins, unpack and (topClass != MobBase))
  File "bash\record_groups.py", line 70, in load
    ins.tell() + self.size - self.header.__class__.size)
  File "bash\record_groups.py", line 172, in loadData
    record = recClass(header,ins,True)
  File "bash\brec.py", line 1615, in __init__
    self.__class__.melSet.initRecord(self,header,ins,unpack)
  File "bash\brec.py", line 1160, in initRecord
    MreRecord.__init__(record,header,ins,unpack)
  File "bash\brec.py", line 1410, in __init__
    if ins: self.load(ins,unpack)
  File "bash\brec.py", line 1473, in load
    self.loadData(ins,inPos+self.size)
  File "bash\brec.py", line 1624, in loadData
    self.__class__.melSet.loadData(self, ins, endPos)
  File "bash\brec.py", line 1189, in loadData
    loaders[Type].loadData(record, ins, Type, size, readId)
  File "bash\game\skyrim\records.py", line 6883, in loadData
    MelStructs.loadData(record, ins, sub_type, size_, readId)
TypeError: unbound method loadData() must be called with MelStructs instance as first argument (got MreWthr instance instead)

Okay Beermotor, now I have your error. Someone on the Nexus was reporting an error with a mod and I installed what they suggested. Now I get the issue.  Utumno made some changes and doesn't have mods installed that effect things so he doesn't see what the changes did is all. I don't have time to troubleshoot the Python code and figure it out. It might be simple might not. It's related to his changes to the code where he as "size_" now instead of "size". I assume it's to control the scope but I don't see the point really.

I cannot reproduce the users issue. However, if you are wondering they stated that after installing the two mods listed in the post, once you opened up the map that the game would crash.

[RavenMind]

Wrye Bash does not appear to be accepting 7-Zip switches specified in bash.ini, other than -ms. It's not clear by looking at the ini if s7zExtraCompressionArguments is set up to handle anything other than -ms. Thread from Nexus:

Spoiler

 

EvilMV wrote: Hi,

Does anyone knows how to get Wrye Bash working with custom 7zip keys? It seems that it completely ignores s7zExtraCompressionArguments INI setting.
For example, I have s7zExtraCompressionArguments=-mx=7 -m0=LZMA2:d=32m -mmt=7

When compressing a project to archive or for release by Wrye 7z process has the following command line:

"e:\Games\Bethesda Softworks\Oblivion\Mopy\bash\compiled\7z.exe" a "c:\users\xx\appdata\local\temp\WryeBash_temp\bash_temp_nonunicode_name.tmp.tmp" -t"7z" -ms=off -y -r -o"e:\Games\Bethesda Softworks\Oblivion Mods\Bash Installers" -i!"e:\Games\Bethesda Softworks\Oblivion Mods\Bash Installers\220 - Graphics Improvement Project-43496-v5.1\*" -x@c:\users\xx\appdata\local\temp\WryeBash_InstallerTempList.txt -scsUTF-8 -sccUTF-8

No compression level and multithreading flags. Maybe I am wrong somewhere?
P.S. This is 307.beta1 standalone, Win10 Pro. INI settings are the same in both default and localized INI.

 

RavenMind wrote:

I have no idea. I spent the last 2 hours getting myself up to speed on 7-Zip switches & playing around with different configurations. Even upgraded the bundled v16.4 7z.exe & .dll with v17.01 (which works). I can't get it to take ANYTHING other than -ms, not even the simplest of switches. Are you able to get a Project packed to Archive at all? I can not, and running WB in debug mode produces a "System ERROR: The parameter is incorrect." in BashBugDump_startup.log, and a "Compression failed: 7z.exe return value: 2" error in BashBugDump.log. I'm even on the latest nightly Python build.

 

 

My BashBugDump.log & BashBugDump_startup.log:

Spoiler

BashBugDump_startup.log:
 

 

Found Python at 'C:\Python27\pythonw.exe'
Launching Wrye Bash 307 in debug mode

System ERROR:
The parameter is incorrect.

======================================

 

BashBugDump.log:

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-8-6.2.9200
Python version: 2.7.10
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
bash.py  324 main: Searching for game to manage:
bush.py   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   78 _supportedGames:  Oblivion: c:\users\chuck\games\oblivion
bush.py  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  142 _detectGames: Set game mode to Oblivion found in parent directory of Mopy:  C:\Users\Chuck\Games\Oblivion
bush.py  156 __setGame:  Using Oblivion game: C:\Users\Chuck\Games\Oblivion
testing UAC
mods_metadata.py  228 __init__: Using LOOT API version: 0.10.2
Traceback (most recent call last):
  File "bash\balt.py", line 2495, in __Execute
    self.Execute()
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\basher\installer_links.py", line 1009, in Execute
    release=self.__class__.release)
  File "bash\basher\installer_links.py", line 106, in _pack
    release=release)
  File "bash\bosh\bain.py", line 1430, in packToArchive
    compress7z(command, outDir, outFile.tail, projectDir, progress)
  File "bash\archives.py", line 75, in compress7z
    u'7z.exe return value: ' + str(returncode) + u'\n' + errorLine)
bash.exception.StateError: bash_temp_nonunicode_name.tmp: Compression failed:
7z.exe return value: 2

 

[Beermotor]

9 hours ago, Sharlikran said:

  Reveal hidden contents

unbound method loadData() must be called with MelStructs instance as first argument (got MreWthr instance instead)
Error loading 'WTHR' record and/or subrecord: 02029E89
  eid = u'CoTClear_5_TU'
  subrecord = 'DALC'
  subrecord size = 32
  file pos = 2843
Error in Vividian - Weather Patch CoT.esp
parsers.py 4015 load:  
Traceback (most recent call last):
  File "bash\parsers.py", line 4009, in load
    self.tops[label].load(ins, unpack and (topClass != MobBase))
  File "bash\record_groups.py", line 70, in load
    ins.tell() + self.size - self.header.__class__.size)
  File "bash\record_groups.py", line 172, in loadData
    record = recClass(header,ins,True)
  File "bash\brec.py", line 1615, in __init__
    self.__class__.melSet.initRecord(self,header,ins,unpack)
  File "bash\brec.py", line 1160, in initRecord
    MreRecord.__init__(record,header,ins,unpack)
  File "bash\brec.py", line 1410, in __init__
    if ins: self.load(ins,unpack)
  File "bash\brec.py", line 1473, in load
    self.loadData(ins,inPos+self.size)
  File "bash\brec.py", line 1624, in loadData
    self.__class__.melSet.loadData(self, ins, endPos)
  File "bash\brec.py", line 1189, in loadData
    loaders[Type].loadData(record, ins, Type, size, readId)
  File "bash\game\skyrim\records.py", line 6883, in loadData
    MelStructs.loadData(record, ins, sub_type, size_, readId)
TypeError: unbound method loadData() must be called with MelStructs instance as first argument (got MreWthr instance instead)

Okay Beermotor, now I have your error. Someone on the Nexus was reporting an error with a mod and I installed what they suggested. Now I get the issue.  Utumno made some changes and doesn't have mods installed that effect things so he doesn't see what the changes did is all. I don't have time to troubleshoot the Python code and figure it out. It might be simple might not. It's related to his changes to the code where he as "size_" now instead of "size". I assume it's to control the scope but I don't see the point really.

I cannot reproduce the users issue. However, if you are wondering they stated that after installing the two mods listed in the post, once you opened up the map that the game would crash.

Yes I think it is also related to one or more of the Bashed Patch patchers that are enabled for Skyrim LE but not for SSE. For example when I enabled SoundsPatcher or StatsPatcher on the SSE side I was able to reproduce the exact same error you posted in your spoiler. 

It is also important to mention that I get the error on Bashed Patch build in Skyrim LE with just the stock masters (no mods) installed. Hopefully this is helpful in narrowing things down a bit. 

 

[Utumno]

I see @Sharlikran moved his Wrye Bash related work (after he deleted all commits we have been collaborating on) from his python-musings organization to a Wrye-Bashers organization with Wrye's avatar as the organization picture.

https://github.com/Wrye-Bashers

Sharlikran, this is an abuse of names and intellectual property - you are not the Wrye-Bashers team nor Wrye. Please take this down immediately.

[Sharlikran]

@Utumno First of all you are not a lawyer, and you are not Wrye himself so lets not take this in a direction that it doesn't need to go in. Have a little equanimity please.  I have permission to work on Wrye Mash from Wrye himself and call it whatever I want, although it's not required I call it anything different. While he and I were discussing Wrye Mash, all versions of Wrye are based off his work and under GNU as he mentions.

I don't appreciate the comment in any way.  Normally you and I are just arguing in general but your recent request is just unprecedented.  I have never been tolerant of how you have treated me over the years. I think most people just let you do, say, and act however you want because they don't want to upset you and have you stop working on Wrye Bash.  While I don't wouldn't want to upset you and have you stop improving a program I am very passionate about, if you did react that way it really wouldn't be my fault and would be solely your decision and a reflection of your character, not mine.  Because of your work on Wrye Bash and the amount of time you have worked on it, you have earned my gratitude but that's about all you have earned.

So with this request I'll go ahead and link the post and contact the previous authors for their input and reaction. Since Wrye can be contacted on UESP I'll see if he is willing to respond but I have no idea when or if he respond.  Until others respond I'm going to leave it the way it is.  I don't really have the time or the money to pay for a lawyer to ask if I have really done what you are saying but I have contacted my local legal referral service. They require a $35 consultation fee so I'll have to look around a bit to see if I can find one willing to wave that and just answer a few questions.

I don't feel any of this is necessary, but since you are taking this in a legal direction, and telling me to take it down immediately in bold letters, then you need to understand you started it, and I don't take that lightly.

I will also ask to see what @WrinklyNinja thinks as I look up to him, but he may not want to be involved in all this drama.  Which I would understand.

[Arthmoor]

My unsolicited interpretation here:

The code is under GPL so there's no legal issue with forking it and resuming development. That's the whole point of being GPL. Also one of the reasons the license is a lousy choice if there's any desire to restrict control in any way.

That does not extend to the naming and reuse of imagery though. GPL generally won't be sufficient to cover that so it would likely be up to Wrye if he's ok with the reuse of his monkey image. The naming is also suspect and IMO done in a way as to create confusion. I think if you had stuck to just working on Mash it wouldn't have raised anyone's hackles over it.

[WrinklyNinja]

40 minutes ago, Sharlikran said:

I will also ask to see what @WrinklyNinja thinks as I look up to him, but he may not want to be involved in all this drama.  Which I would understand.

Oh boy, drama. IANAL, but it looks like Sharlikran's got pretty clear-cut permission to use the "brand" - perhaps more than Utumno despite all his work, unless Utumno can also dig out a statement from Wrye.  So long as he abides by the terms of the license, he can also build off Utumno's work.

That said, it is a bit disingenuous not to have privately discussed this previously and to have chosen a name that's potentially confusing: the fork Utumno maintains has the most claim to being the "official" Wrye Bash, and I don't think Wrye-Bashers is sufficiently distinct not to confuse people looking for Utumno's fork (though the repositories are all marked as forks on GitHub). It looks like a hostile fork to me, and that kind of thing is generally looked down on for good reason.

[Sharlikran]

Thanks for your input Wrinkly and Arthmoor. I defiantly didn't intend it to be disingenuous, hostile, or confusing.  I chose a name that was relevant to what I put in the organization.  In spite of the fact that I would prefer to wait for Wrye to respond, since you gave some valid reasons in a respectful way and didn't lash out at me I'll remove the icon and make a new organization and move the forks.  Then I'll wait for more input.

Also I made that years ago, not recently. I am not sure when I made it maybe 2014 or 2015 when I added Valda's Wrye Flash versions to it. Nobody was upset, nobody knew it was there, so nobody cared.

This all just demonstrates human nature. How people treat others has just declined since my youth. It's disheartening. The name chosen wasn't intended to do anything wrong. When people don't have an agenda and when nobody is angry or upset, they usually don't care.  Once it matters then people say something.  People expect others to pay attention what they have to say and meet their demands.  Yet they have little to no inclination of extending the same courtesy to others.

Just goes to show there is a benefit to personal enrichment, even in spite of adversity.  Vigilance rewards the prepared.

[lmstearn]

It's just a little odd using a name that way-but if Wrye doesn't mind, sure, go ahead. There's surely no problem with the name Wrye-Bashers- just  the avatar.

What if I started to call myself ArthmoorX or WrinklyNinjaX or SharlikranX - or even Todd HowardX adopting their avatars and to credit them with any of my creations and vice versa?

But there are so many other names available on that theme anyhow. Here are just a few:

Spoiler

BarbedWrye
FlyWrye
WryeBashful
WyredForMods
WryeTonBro
And one for Tannin: NowryeMOreason

 

[RavenMind]

NoWryeMOreason took me a minute, then I about fell out of my chair!

[Sharlikran]

Wrye-Bash-er-s, because it's plural. Containing Wrye Mash/Flash/Bash etc. It's just simply plural. As for the avatar the icon comes with Wrye Mash and it's part of his code. It just belongs to the program. For example if I compile Wrye Mash it ends up with his icon for the EXE.  If I could even get a hold of him I highly doubt I would have to be specific and ask him if I can use the icon he already packaged with his program. Which I have permission to continue his work, although as he mentions it's already under GNU.  GNU because I just checked his version 84 and while only balt.py and bolt.py have the proper license header, it still shows GNU. Which if I understand correctly means version 3.

[Leonardo]

19 minutes ago, Sharlikran said:

As for the avatar the icon comes with Wrye Mash and it's part of his code.

That's correct.  IIRC it was someone who suggested that in Yacoby's Fork thread on BSF.  But the green "OK - checked" symbol are still the original icon for Wrye Mash while the Wrye Monkey icon is new and I like the new icon.

[Sharlikran]

I had to dig for it, it looks like it was added in this commit.

[Leonardo]

7 minutes ago, Sharlikran said:

I had to dig for it, it looks like it was added in this commit.

So Yacoby made the decision to use the Wrye Monkey icon for Wrye Mash over 6 years ago.

[Nayu37]

Hello!

I am using Wrye Bash to install mods for Oblivion, but every time that I rebuild the patch (CBash Beta), a strange window pops up:

https://imgur.com/fmqiMKt

This looks like an error notification.

I know that this is caused by the fact that I'm using a French version of Oblivion. I tested it on an English version with the same manipulations and this didn't occur.

Is this a problem or can I safely ignore it?

Thank you very much for your assistance.

[Sharlikran]

Are you using the 307 Beta from the Nexus? Older versions are not going to have enough changes to work very well.  When you use 307 Beta1, install the Standalone EXE.  It will add an icon to your windows menu.  After you have that version installed make the Bash Patch.  If you still have the error do the following.

• Go to your windows start icon, All programs
• Look for the Wrye bash entry
• Click the entry "Wrye Bash - Oblivion (Debug Log)"

That will make a BashBugDump.log. Please post the log here. If the log is really long, then post just the upper portion of it. and only one of the errors.
The upper portion looks like this, only yours will show the French locale information that is needed to see if there is a possible fix for your issue.

Spoiler

 

Wrye Bash starting
Using Wrye Bash Version 307.201709250447
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs 
bash.py  324 main: Searching for game to manage:
bush.py   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   78 _supportedGames:  Fallout3: C:\Games\steamapps\common\Fallout 3 goty
bush.py   78 _supportedGames:  Fallout4: C:\Games\steamapps\common\Fallout 4
bush.py   78 _supportedGames:  FalloutNV: C:\Games\steamapps\common\Fallout New Vegas
bush.py   78 _supportedGames:  Oblivion: G:\Games\steamapps\common\Oblivion
bush.py   78 _supportedGames:  Skyrim Special Edition: F:\Games\steamapps\common\Skyrim Special Edition
bush.py   78 _supportedGames:  Skyrim: F:\Games\steamapps\common\Skyrim
bush.py  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  142 _detectGames: Set game mode to Skyrim found in parent directory of Mopy:  F:\Games\steamapps\common\Skyrim
bush.py  156 __setGame:  Using Skyrim game: F:\Games\steamapps\common\Skyrim
testing UAC
mods_metadata.py  228 __init__: Using LOOT API version: 0.10.2

 

 

 

Also may I have a link to that file please? I'd like to see if it has Unicode chars in it from a French version of the CK. If it does that would make fixing this a bit more difficult.  I encountered one for Wrye Mash for Morrowind recently that was in Russian and I was able to fix it. Wrye Bash should already have the needed changes but if not there are things to try and fix it.

[Nayu37]

Thank you Sharlikran. Yes I'm using the 307 Beta from the Nexus.

I tried with both the Installer version and the Standalone executable version, the error pops up with both.

I'm sorry but I don't see any Wrye Bash entry in my Windows apps (even though I did tick "Add to Start menu" during the installation...).

Alright nevermind, here is the log:

Spoiler

Wrye Bash starting
Using Wrye Bash Version 307.201612302300 (Standalone)
OS info: Windows-10-10.0.15063
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('fr_FR', 'cp1252')
filesystem encoding: mbcs
Searching for game to manage:
bush.pyo   71 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   73 _supportedGames:  oblivion: C:\Games\Steam\steamapps\common\Oblivion
bush.pyo  131 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  137 _detectGames: Set game mode to oblivion found in parent directory of Mopy:  C:\Games\Steam\steamapps\common\Oblivion
bush.pyo  172 setGame: No preferred game specified.
bush.pyo  152 __setGame:  Using oblivion game: C:\Games\Steam\steamapps\common\Oblivion
testing UAC
mods_metadata.pyo  224 __init__: Using LOOT API version: 0.10.2
Only one instance of Wrye Bash can run.

 

I attached the error file to this post. I copy-pasted from the error window to notepad++ and saved as a.txt.

Wrye Bash error.txt

[DylanJames]

Hey guys. I don't know if this issue has been addressed or brought up in this topic (I tried looking but couldn't find anything). On any of the Wyre Bash builds I've tried that support ESLs for SSE, none of them seem to understand that ESLs don't have the same load order prefixes as standard plugins (or, probably to be more accurate, it's counting ESLs towards your 255 plugin limit). Example, I've attached an error image I get when trying to activate a (blank) ESL in a full load order (with other ESL files).

Probably an oversight. Is there any way to bypass this restriction outside editing the code?

Thanks for the development you're putting into Wyre Bash.