Jump to content

Recommended Posts

Same problem when I try and run it from the Python Source package. Standalone and the installer package work fine.

Share this post


Link to post
Share on other sites

I normally use DOS scripts to run the python commands, but was running them from a powershell prompt as an example.  I get the same output in either.  From git bash (MINGW64) or cygwin64 I get a segmentation fault running any pipenv commands.  Even without options, it faults after showing the usage help.

Share this post


Link to post
Share on other sites

Here is the access violation error from the windows log.  The faulting module in the windows system32 folder is 32-bit, so possibly the problem?

 

Spoiler

Faulting application name: python.exe, version: 0.0.0.0, time stamp: 0x5dab79df
Faulting module name: python27.dll, version: 2.7.17150.1013, time stamp: 0x5dab79d8
Exception code: 0xc0000005
Fault offset: 0x000000000004d4a0
Faulting process id: 0x48c8
Faulting application start time: 0x01d5d581b19f25fe
Faulting application path: c:\python27\python.exe
Faulting module path: C:\WINDOWS\SYSTEM32\python27.dll
Report Id: 3b7521d0-a3dc-402f-823b-89ec28b7dbe0
Faulting package full name: 
Faulting package-relative application ID: 

 

Share this post


Link to post
Share on other sites

Getting the following error message when trying to start up wrye bash:

 

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 997, in readHeader
  File "bash\bosh\save_headers.pyo", line 63, in __init__
  File "bash\bosh\save_headers.pyo", line 80, in load_header
  File "bash\bosh\save_headers.pyo", line 244, in load_masters
  File "bash\bosh\save_headers.pyo", line 273, in _decompress_masters_sse_zlib
TypeError: decompress() takes no keyword arguments

 


full bashbugdump.log


here was a full bashbugdump, but when sending out the post, the forum software decided to delete half my post, so..yeah, anyways....


OS: Windows 10
install directory: not default and not protected
wrye bash standalone

action prior to error: messed with my savegame files. changed compression from lz4 to zlib and uncompressed via uicompression=(2,1,0) setting in skyrim.ini
result: wrye bash crashes at startup

action taken afterwards: deleted my savegame files
result: wrye bash starts without error


What's with all those modding tools having trouble with other compression types for savegame files?
Is there a setting for wrye bash to make it work with zlib or uncompressed?
 

 

Share this post


Link to post
Share on other sites

@Gemma_Kat Try the latest WIP build (see second post in this thread for the link), that's a bug in the Nexus version that is fixed in the WIP build. Wrye Bash supports all three types of save compression (LZ4, zlib, uncompressed).

Share this post


Link to post
Share on other sites
3 hours ago, Infernio said:

@Gemma_Kat Try the latest WIP build (see second post in this thread for the link), that's a bug in the Nexus version that is fixed in the WIP build. Wrye Bash supports all three types of save compression (LZ4, zlib, uncompressed).

awesome. thanks

Share this post


Link to post
Share on other sites

Is it possible to prevent Wrye Bash from trying to integrate deactivated plugins? I got many deactivated plugins for various reasons (mainly because i merged them), but don't want to remove them from the Data folder and it would be easier if I didn't have to go over all the plugins to remove them from the bashed patch creation.

Share this post


Link to post
Share on other sites
On 2/4/2020 at 2:46 PM, Gemma_Kat said:

Is it possible to prevent Wrye Bash from trying to integrate deactivated plugins? I got many deactivated plugins for various reasons (mainly because i merged them), but don't want to remove them from the Data folder and it would be easier if I didn't have to go over all the plugins to remove them from the bashed patch creation.

It would also already suffice if deactivated plugins would sport an asterisk or so, when building/updating the bashed patch, so i could immediatly spot and remove them from the build. ...like that would be reeeeeally handy.

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