Jump to content

Recommended Posts

@sombrero Yeah, the colors might not be great for visually impaired people - right now they're just images we display, so you *could* open them with an image editor (they're in Mopy/bash/images, look for checkbox_*.png) and change the colors yourself. Hopefully we'll be able to draw them via code in the future, which would mean you could just configure their colors via the Colors dialog.

Edit: opened an issue so it doesn't get forgotten: https://github.com/wrye-bash/wrye-bash/issues/511

@gurglegurgle You're using wxPython 3, but we're already on wxPython 4. You can also just run

pip install -r requirements.txt

while in the WB folder that has the requirements.txt file. That should install the right versions of everything you need.

Share this post


Link to post
Share on other sites

imp = imported into the Bashed Patch (i.e. a plugin is deactivated, but some of its data has been imported)
inc = merged (stands for 'included' I guess?) into the Bashed Patch
off = inactive plugin, uninstalled package, etc.
on = active plugin, installed package, etc.
The _wiz variations are for packages with BAIN wizards.

Also, if you do change these, make sure to keep copies of the altered images in a safe place. The WB download includes the original versions, so if you use the installer or just unzip and overwrite, that would overwrite your changed files again.

Share this post


Link to post
Share on other sites

In that folder, I count 8 checkbox colors, each with many variations.  I'm not sure how even somebody with normal color vision could remember it all.  I recommend a different way to let users know the status of mods.

I really only want to know 2 things

1) if some files have failed to be installed, I want to be told and I want to know which ones.

2) If a zip fails integrity check, I want WB to refuse to install it and tell me why.

Share this post


Link to post
Share on other sites

They're not all used for the same thing, e.g. masters use purple, blue, green, orange and red, while mods only use green, yellow, orange and red (with increasing severity of the problem in that order). Also, the status bar at the bottom will tell you what any of the 'problematic' colors (i.e. yellow, orange and red) mean (except on the Installers tab, where we don't have that yet).

Share this post


Link to post
Share on other sites
On 6/9/2020 at 8:05 AM, Infernio said:

@sombrero Yeah, the colors might not be great for visually impaired people - right now they're just images we display, so you *could* open them with an image editor (they're in Mopy/bash/images, look for checkbox_*.png) and change the colors yourself. Hopefully we'll be able to draw them via code in the future, which would mean you could just configure their colors via the Colors dialog.

Edit: opened an issue so it doesn't get forgotten: https://github.com/wrye-bash/wrye-bash/issues/511

@gurglegurgle You're using wxPython 3, but we're already on wxPython 4. You can also just run


pip install -r requirements.txt

while in the WB folder that has the requirements.txt file. That should install the right versions of everything you need.

Looks like the Advanced Readme hosted on the github.io page is misleading. Thank you for clarifying the installation process.
Anyways, I've traded one error for another.  I completely deleted my Python27 directory, just to be sure no strays remained in the site-packages. CBash.dll is, in fact, in the wrye-bash/bash/compiled dir as cint.py expects it to be (going off what I've read in the script)
 

Spoiler

localize.py   98 setup_locale: Set wx locale to 'English' (en_US)
localize.py  106 setup_locale: Set Wrye Bash locale to 'English'
bash.py  179 dump_environment: Using Wrye Bash Version 307
bash.py  179 dump_environment: OS info: Windows-10-10.0.18362, running on AMD64 Family 23 Model 1 Stepping 1, AuthenticAMD
bash.py  179 dump_environment: Python version: 2.7.16 (v2.7.16:413a49145e, Mar  4 2019, 01:30:55) [MSC v.1500 32 bit (Intel)]
bash.py  179 dump_environment: wxPython version: 4.1.0 msw (phoenix) wxWidgets 3.1.4
bash.py  179 dump_environment: python-lz4 version: 2.2.1; bundled LZ4 version: 1.9.2
bash.py  179 dump_environment: pyyaml version: 5.3.1
bash.py  179 dump_environment: Input encoding: UTF8; output encoding: None
bash.py  179 dump_environment: Filesystem encoding: mbcs
bash.py  179 dump_environment: Command line: ['Wrye Bash Launcher.pyw', '-d']
bash.py  179 dump_environment: Using scandir v1.10.0
bash.py  401 _import_bush_and_set_game: Searching for game to manage:
bush.py   85 _supportedGames: The following games are supported by this version of Wrye Bash:
bush.py   88 _supportedGames:  Enderal, Fallout 3, Fallout 4, Fallout 4 VR, Fallout New Vegas,
bush.py   88 _supportedGames:  Morrowind, Oblivion, Skyrim, Skyrim Special Edition, Skyrim VR
bush.py   90 _supportedGames: The following installed games were found via Windows Registry:
bush.py   92 _supportedGames:  Oblivion: C:\Games\Oblivion
bush.py  149 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  159 _detectGames: No known game in parent directory of Mopy: C:\Games\wrye-bash
bush.py  170 __setGame: Single game found [Oblivion]: C:\Games\Oblivion
cint.py  168 <module>: Failed to import CBash.
Traceback (most recent call last):
  File "bash\cint.py", line 165, in <module>
    _CBash = CDLL(cb_path)
  File "C:\Python27\lib\ctypes\__init__.py", line 366, in __init__
    self._handle = _dlopen(self._name, mode)
WindowsError: [Error 193] %1 is not a valid Win32 application

loot_parser.py   46 <module>: Using LibYAML-based parser
mods_metadata.py   48 __init__: Initialized loot_parser, compatible with libloot v0.15.x
__init__.py 3320 initBosh: Looking for main game INI at C:\Users\Popot\Documents\My Games\Oblivion\Oblivion.ini
testing UAC

 

 

Share this post


Link to post
Share on other sites

Yeah, the online advanced readme doesn't get updated very often. I've gone ahead and synced it again, but the only guaranteed up-to-date docs are the ones that come with the Wrye Bash download.
Regarding your error: are you on the nightly branch? That branch needs a 64 bit python, while the dev branch is still on 32 bit.

Share this post


Link to post
Share on other sites
On 6/7/2020 at 7:01 PM, Infernio said:

Click on the gear icon at the bottom, then click 'Save Settings'. That will save your settings & data immediately.
Doing it every time a mod is installed would be difficult, because we'd be asking BAIN to save its data while it's still changing its internal data (due to the mod installation). Plus it might not be a feature some people want so it would have to be opt-in - and we don't have a great settings menu right now (which will be coming, but isn't there yet).

This is a great option. Didn't see it mentioned, so thank you for the hint.

Share this post


Link to post
Share on other sites
On 6/9/2020 at 2:05 PM, Infernio said:

@sombrero Yeah, the colors might not be great for visually impaired people - right now they're just images we display, so you *could* open them with an image editor (they're in Mopy/bash/images, look for checkbox_*.png) and change the colors yourself. Hopefully we'll be able to draw them via code in the future, which would mean you could just configure their colors via the Colors dialog.

 

1) I have seen the import / export options for color. Is there some place where people have uploaded their own color adaptions ? Or can we share some in a place like this ?

For me I mainly need a dark background and less bright text color if I work a longer time (my eyes tend to fatigue more quickly since windows and/or LEDs were made bright (blue).). Only few apps support it unfortunately.

I have done this manually for several apps, it's always a slow process to adapt every single color, so my nice to have wish: A possibility to Apply All colors across sections as far as they are identical (text and background obviously)

Spoiler

NnDk0nq.png

2) Regarding the icon color itself, I have no problem to differentiate. My main problem is to recognize the "+" symbol making me miss uninstalled mods or plugins (weak contrast). With impaired people in mind it's hard to choose a good color option for this.

If I choose a dark "theme" then it's easier when the background is dark and foreground is bright interestingly for my eyes. There are color contrast pages for testing such things ("color contrrast finder"). I use "Dark Reader" with "Filter" option to test it in the webbrowser (firefox) on dark mode.

3) Unrelated: I always forget that the header has a different context menu as well. Maybe a tooltip would be helpful ("Press right/context menu button to open ...")

4) Not all colors can be changed.

Share this post


Link to post
Share on other sites

Hello,

Reporting a bug and asking for help:

I've basically been on a mod installing rampage since I found Oblivion on sale for seven dollars on GOG games. This happened after I installed a mod (Universal Skeleton Mod,) tested it out in game and then exited the game. Started up Wrye bash and received thsi error:

Operating System is Windows 10: 

localize.pyo   89 setup_locale: Set wx locale to 'Japanese' (ja_JP)
localize.pyo  127 setup_locale: Error loading translation file:
Traceback (most recent call last):
  File "bash\localize.pyo", line 124, in setup_locale
  File "gettext.pyo", line 255, in __init__
  File "gettext.pyo", line 413, in _parse
  File "encodings\utf_8.pyo", line 16, in decode
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 90-91: invalid continuation byte
bash.pyo  179 dump_environment: Using Wrye Bash Version 307.202005031206 (Standalone)
bash.pyo  179 dump_environment: OS info: Windows-10-10.0.15063, running on AMD64 Family 21 Model 112 Stepping 0, AuthenticAMD
bash.pyo  179 dump_environment: Python version: 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC v.1500 32 bit (Intel)]
bash.pyo  179 dump_environment: wxPython version: 4.0.7.post2 msw (phoenix) wxWidgets 3.0.5
bash.pyo  179 dump_environment: python-lz4 version: 2.2.1; bundled LZ4 version: 1.9.2
bash.pyo  179 dump_environment: pyyaml version: 5.3.1
bash.pyo  179 dump_environment: Input encoding: None; output encoding: None
bash.pyo  179 dump_environment: Filesystem encoding: mbcs
bash.pyo  179 dump_environment: Command line: ['C:\\Program Files (x86)\\GOG Galaxy\\Games\\Oblivion\\Mopy\\Wrye Bash.exe', '-d']
bash.pyo  179 dump_environment: Using scandir v1.10.0
bash.pyo  401 _import_bush_and_set_game: Searching for game to manage:
bush.pyo   85 _supportedGames: The following games are supported by this version of Wrye Bash:
bush.pyo   88 _supportedGames:  Enderal, Fallout 3, Fallout 4, Fallout 4 VR, Fallout New Vegas,
bush.pyo   88 _supportedGames:  Morrowind, Oblivion, Skyrim, Skyrim Special Edition, Skyrim VR
bush.pyo   90 _supportedGames: The following installed games were found via Windows Registry:
bush.pyo   92 _supportedGames:  Oblivion: C:\Program Files (x86)\GOG Galaxy\Games\Oblivion
bush.pyo  149 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  155 _detectGames: Set game mode to Oblivion found in parent directory of Mopy:  C:\Program Files (x86)\GOG Galaxy\Games\Oblivion
bush.pyo  170 __setGame:  Using Oblivion game: C:\Program Files (x86)\GOG Galaxy\Games\Oblivion
loot_parser.pyo   46 <module>: Using LibYAML-based parser
mods_metadata.pyo   48 __init__: Initialized loot_parser, compatible with libloot v0.15.x
__init__.pyo 3313 initBosh: Looking for main game INI at C:\Users\rober\OneDrive\Documents\My Games\Oblivion\Oblivion.ini
testing UAC
__init__.pyo 1262 _initDB: Initializing BSAInfos
__init__.pyo 1263 _initDB:  store_dir: C:\Program Files (x86)\GOG Galaxy\Games\Oblivion\Data
__init__.pyo 1264 _initDB:  bash_dir: C:\Program Files (x86)\GOG Galaxy\Games\Oblivion Mods\Bash Mod Data\BSA Data
__init__.pyo 1271 _initDB:  Successfully initialized BSAInfos
Wrye Bash encountered an error.
Please post the information below to the official thread at
https://afkmods.com/index.php?/topic/4966-wrye-bash-all-games
or to the Wrye Bash Discord at
https://discord.gg/NwWvAFR

Traceback (most recent call last):
  File "bash\bash.pyo", line 202, in main
  File "bash\bash.pyo", line 365, in _main
  File "bash\basher\__init__.pyo", line 4214, in Init
  File "bash\basher\__init__.pyo", line 4247, in InitData
  File "bash\bosh\__init__.pyo", line 1400, in refresh
  File "bash\bosh\__init__.pyo", line 2994, in new_info
  File "bash\bosh\bsa_files.pyo", line 437, in inspect_version
  File "bash\bosh\bsa_files.pyo", line 157, in load_header
  File "bash\bosh\bsa_files.pyo", line 130, in load_header
error: unpack requires a string argument of length 4

Share this post


Link to post
Share on other sites

This is an older known issue:

https://forum.step-project.com/topic/13543-wrye-bash-log-errors/

I remember having something like that in a mod that included language files. I removed the language file and afterwards I could install the modified archive.

If you have this case and need the translation you would need to install it manually (I needed to do this for some executables).

 

Share this post


Link to post
Share on other sites

@Synel00 That error is caused by an invalid BSA file you have somewhere. Try again with the latest WIP version (link is in the second post in this thread) and make another BashBugDump, which will tell you what BSA file is affected.

Share this post


Link to post
Share on other sites

Hi,

My Wrye Bash for SSE was working perfectly fine yesterday but today when I tried to load it and received this log:

Traceback (most recent call last):
  File "bash\bash.pyo", line 206, in main
  File "bash\bash.pyo", line 369, in _main
  File "bash\basher\__init__.pyo", line 4075, in Init
  File "bash\basher\__init__.pyo", line 4116, in InitData
  File "bash\bosh\__init__.pyo", line 2753, in refresh
  File "bash\bosh\__init__.pyo", line 1337, in refresh
  File "bash\bosh\__init__.pyo", line 1313, in new_info
  File "bash\bosh\__init__.pyo", line 1232, in new_info
  File "bash\bosh\__init__.pyo", line 219, in __init__
  File "bash\bosh\__init__.pyo", line 116, in __init__
  File "bash\bosh\__init__.pyo", line 231, in _reset_cache
  File "bash\bosh\__init__.pyo", line 1000, in readHeader
  File "bash\bosh\__init__.pyo", line 223, in _reset_masters
  File "bash\bosh\__init__.pyo", line 1114, in get_masters
  File "bash\bosh\cosaves.pyo", line 1384, in has_accurate_master_list
  File "bash\bosh\cosaves.pyo", line 1219, in read_cosave
  File "bash\bosh\cosaves.pyo", line 1234, in _read_cosave_header
  File "bash\bosh\cosaves.pyo", line 148, in __init__
  File "bash\bosh\cosaves.pyo", line 123, in __init__
  File "bash\bolt.pyo", line 1466, in unpack_string
IOError: [Errno 22] Invalid argument
 

This has never happened before so any help would be appreciated.

Share this post


Link to post
Share on other sites

I know this isn't the main intention behind the de-wx'ing issue but, once the work is done, how much work do you think it would take for someone to remove wxPython entirely in favour of, say, Tkinter?

The reason I ask is because for the last few years, I have wanted to try run WB through PyPy. However, the main roadblock towards doing so is that wxPython doesn't work with PyPy. There were some efforts to try fix that a number of years ago but they didn't seem to go anywhere.

Share this post


Link to post
Share on other sites

We wouldn't accept a patch to remove it (because Tkinter looks way worse than wxPython), but we might work towards allowing multiple GUI backends. If we do that, then you could implement a Tkinter backend (and we'd probably accept the patch).

Share this post


Link to post
Share on other sites

Thanks for the reply. When I said remove, I only did so under the assumption that there wouldn't be any interest in having two different GUI methods. Since that isn't the case, TK can be inserted instead.

You didn't answer my question though. How much effort would it take to change WB so that it can use TK instead of WX? Once the de-wx'ing work is done, is it true that all of the wx code will be in the GUI folder? That the code in that folder is all that will need to be modified to add TK support?

Also, can you please quantify "Tkinter looks way worse than wxPython"? Thanks.

Share this post


Link to post
Share on other sites
Quote

there wouldn't be any interest in having two different GUI methods. Since that isn't the case, TK can be inserted instead.

I wouldn't say we're interested in having two different GUI backends, just that it's possible GUI refactoring could eventually make such an API possible.

Quote

How much effort would it take to change WB so that it can use TK instead of WX?

Honestly? I'm not sure. You would have to reimplement all GUI components we use right now, which is no problem for e.g. dialogs, but I can imagine that UIList (the class we use to display the mods/saves/installers/etc. files on the left side of each tab) would be much harder to implement.

Quote

Also, can you please quantify "Tkinter looks way worse than wxPython"

I'm not sure how much I can quantify a subjective feeling, I just think Tkinter looks much uglier than wxPython :P

Share this post


Link to post
Share on other sites

hi, from install, reporting as requested

property sheet
filename: Wrye Bash 307 Beta 6.1 - Installer-6837-307-beta6-1-1588509460.exe
description: Installer for Wrye Bash 307.202005031206

Wrye Bash encountered an error.
Traceback (most recent call last):
File "bash\bash.pyo", line 202, in main
File "bash\bash.pyo", line 267, in _main
File "bash\bash.pyo", line 390, in _detect_game
File "bash\initialization.pyo", line 143, in init_dirs
File "bash\initialization.pyo", line 54, in getPersonalPath
File "bash\env.pyo", line 131, in get_personal_path
File "bash\env.pyo", line 919, in get_known_path
RuntimeError: Failed to retrieve known folder path 'UUID('fdd39ad0-238f-46af-adb4-6c85480369c7')'

Share this post


Link to post
Share on other sites

Translation: Windows couldn't find your "Documents" folder.

So make sure it exists on your computer?  It's a required system folder, so it'd take something catastrophic for it to go missing.

Share this post


Link to post
Share on other sites

okay, second attempt, i've uninstalled, i've downloaded the installer again, run the installer, followed the instructions on screen and i get this when i go to run it. what have i done wrong and how do i fix it?

Traceback (most recent call last):
  File "bash\bash.pyo", line 202, in main
  File "bash\bash.pyo", line 267, in _main
  File "bash\bash.pyo", line 390, in _detect_game
  File "bash\initialization.pyo", line 143, in init_dirs
  File "bash\initialization.pyo", line 54, in getPersonalPath
  File "bash\env.pyo", line 131, in get_personal_path
  File "bash\env.pyo", line 919, in get_known_path
RuntimeError: Failed to retrieve known folder path 'UUID('fdd39ad0-238f-46af-adb4-6c85480369c7')'
 

Share this post


Link to post
Share on other sites

I'm sure it's come up before, but can we please have the option of some kind of "Big Boy Mode" that doesn't silently skip over files? The 'Has Extra Directories' and 'Override Skips' options still leave important bits out of more complicated mods. It seems like unnecessary nannying now that plugins and third party tools are nothing unusual in mod packages.

It sometimes even skips files that aren't supposedly blacklisted. For example, SSE Fixes is a simple package with a Data/DLLPlugins folder containing a dll and ini file. With both 'Has Extra Directories' and 'Override Skips' enabled, it nevertheless skips the dll and dumps the ini into the main Data folder incorrectly.

Wrye Smash 307.202005031206 Standalone running in Windows 8.1, for reference.

Share this post


Link to post
Share on other sites

@Geist, absolutely.  Files should never be skipped when installing a mod.  At least not without offering the user a choice in the matter.  This has been my beef with mod managers since forever.  I should never have to discover the hard way that necessary files have been skipped and install them manually.  Otherwise, why use a mod manager?  If there is something wrong with an archive that all files cannot be extracted, exit the installation and tell me what the problem was.  There should be no other logic path in the software code for this situation.

Share this post


Link to post
Share on other sites

The only things that are silently skipped with no way to change it are executables (DLLs and EXEs), except for xSE (SKSE, OBSE, etc.) plugins. This is by design, for security reasons. I've submitted an issue a while ago because I personally don't think this argument holds much water: https://github.com/wrye-bash/wrye-bash/issues/501
But people feel strongly on this, and without some sort of consensus from the rest of the team I can't just make a change like that.

Share this post


Link to post
Share on other sites

@inferno, feel strongly, yes.    As Geist says, for example, SSE Fixes is a simple package with a Data/DLLPlugins folder containing a dll and ini file.  Rather than try to decide, Bash should either install the whole mod as defined or install none of it.  It is aggravating when Bash pretends to install something but doesn't.  There is no excuse for that.  

Beyond that, I recently encountered a situation where Bash did not install the esp from Alchemist's Journal.  That mod includes a skse dll which did get installed.  It might be that there was something wrong with the archive.  Although zip.exe does not detect a problem.  Bash should be able to detect situations like that and refuse to install the mod.  No question.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Support us on Patreon!

Patreon
×
×
  • Create New...