Skyrim wrye bash ошибка - TopOshibok.ru - решение и исправление самых разных ошибок

Привет всем.
ребят, Играл в скайрим с кучей модов(налаженых, без конфликтов) около 2х месяцев без багов и прочей херни. юзал горячо Wrye Bash 295 … всё бы ничё…

Решил снести винду ибо начала лагать. Поставил тот же скайрим, всё те же моды и wrye bash. %рен! Не запускается wrye bash! и всё, с того момента мой комп как заколдовало! Всё пробовал! и версии wrye bash разные (в том числе 300) и скачал репак от Fenixx The Elder Scrolls 5.Skyrim.v 1.7.7.0.6 + 1 DLC.(2011).Repack

блин. ещё раз снёс винду. вот только что. поставил wrye bash с чистого листа на голую игруху (без модов). и всё равно не запускается.

вот что выдаёт в логе версия wrye bash 300

An error has occured with Wrye Bash, and could not be displayed.
The following is the error that occured while trying to display the first error:
‘ascii’ codec can’t encode characters in position 0-5: ordinal not in range(128)
The following is the error that could not be displayed:
Traceback (most recent call last):
File «Wrye Bash Launcher.pyw», line 33, in
bash.main()
File «bash\bash», line 467, in main
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xc2 in position 9: ordinal not in range(128)

Люди добрые — что блин делать?

Источник

Comments

Utumno

added
the

C-todo

Category: TODO, specific item that needs to be accomplished in working towards a goal

label

Dec 31, 2017

BeermotorWB

changed the title
Readme.md versions update 20171230

Bashed Patch: Game startup issues related to problematic plugins

Dec 31, 2017

BeermotorWB

added

C-bug

Category: Bug, an acknowledged defect in the program

C-regression

Category: Regression, something that broke between the last release and dev

and removed

C-todo

Category: TODO, specific item that needs to be accomplished in working towards a goal

labels

Dec 31, 2017

This was referenced

Feb 11, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 20, 2018

Sharlikran

added a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Sep 21, 2018

Infernio

pushed a commit
that referenced
this issue

Feb 23, 2019

So there was a discussion in #342 and #403. I asked the current maintainer to suppress the error for the official game files.

https://afkmods.iguanadons.net/index.php?/topic/4966-wrye-bash-all-games/&do=findComment&comment=170862

Commit 589ece6 was submitted instead which is incorrect.

It is incorrect because as I stated many times in 2017 all records for Skyrim SE are written in Form Version 44 format. Only people who do not listen to me or people who do not understand programming continue to needlessly speculate what is and is not happening.

Infernio:
 Removed the one formatting change to line 188/189 to make viewing the
 change easier. Not really necessary, but continuing lines with
 backslashes also goes against PEP 8, so let's not do that.

Infernio

pushed a commit
that referenced
this issue

Feb 23, 2019

So there was a discussion in #342 and #403. I asked the current maintainer to suppress the error for the official game files.

https://afkmods.iguanadons.net/index.php?/topic/4966-wrye-bash-all-games/&do=findComment&comment=170862

Commit 589ece6 was submitted instead which is incorrect.

It is incorrect because as I stated many times in 2017 all records for Skyrim SE are written in Form Version 44 format. Only people who do not listen to me or people who do not understand programming continue to needlessly speculate what is and is not happening.

Infernio:
 Removed the one formatting change to line 188/189 to make viewing the
 change easier. Not really necessary, but continuing lines with
 backslashes also goes against PEP 8, so let's not do that.

Infernio

pushed a commit
that referenced
this issue

Feb 23, 2019

So there was a discussion in #342
and #403. I asked the
current maintainer to suppress the error for the official game files.

https://afkmods.iguanadons.net/index.php?/topic/4966-wrye-bash-all-games/&do=findComment&comment=170862

Commit 589ece6 was submitted instead
which is incorrect.

It is incorrect because as I stated many times in 2017 all records for
Skyrim SE are written in Form Version 44 format. Only people who do
not listen to me or people who do not understand programming continue
to needlessly speculate what is and is not happening.

Infernio:

This fixes a regression on dev.
Commit c076e9f makes Wrye Bash write
out form version 44 records, but not set the form version to 44. This is
obviously unacceptable behavior and could lead to crashes, freezes, etc.

We now have the necessary record definitions to read the earlier form
versions and spit out form version 44, so we should do it.

Infernio

added a commit
that referenced
this issue

Feb 23, 2019

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

Utumno

pushed a commit
that referenced
this issue

Feb 23, 2019

Infernio:

This fixes a regression on dev.
Commit c076e9f makes Wrye Bash write
out form version 44 records, but not set the form version to 44. This is
obviously unacceptable behavior and could lead to crashes, freezes, etc.

We now have the necessary record definitions to read the earlier form
versions and spit out form version 44, so we should do it.

Utumno:

Mopy/bash/exception.py: removed old_skyrim ModSizeError init param, an
earlier attempt to fix this made obsolete by
8662eff.
Comment fixes from parent merge.

This still feels like a monkey patch as it's rather ad hoc - we
should detect such older formVersion records and probably warn.

See (for records that change for SSE):
#403 (comment)
#403 (comment)

Utumno

pushed a commit
that referenced
this issue

Feb 23, 2019

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

Utumno

pushed a commit
that referenced
this issue

Feb 25, 2019

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

Utumno

pushed a commit
that referenced
this issue

Mar 28, 2019

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

Infernio

added a commit
that referenced
this issue

Mar 30, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Infernio

added a commit
that referenced
this issue

Mar 30, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Sharlikran

pushed a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Mar 31, 2019

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] wrye-bash#403 (comment).

Sharlikran

pushed a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Mar 31, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] wrye-bash#403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Sharlikran

pushed a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Apr 7, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] wrye-bash#403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Sharlikran

pushed a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Apr 13, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] wrye-bash#403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Utumno

pushed a commit
that referenced
this issue

Apr 25, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Utumno

pushed a commit
that referenced
this issue

Apr 25, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Infernio

added a commit
that referenced
this issue

Apr 25, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Utumno

pushed a commit
that referenced
this issue

Apr 25, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Utumno

pushed a commit
that referenced
this issue

Apr 25, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Utumno

pushed a commit
that referenced
this issue

Apr 25, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Utumno

pushed a commit
that referenced
this issue

Apr 26, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Infernio

added a commit
that referenced
this issue

Apr 26, 2019

Squashed commit consisting of these 2 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] #403 (comment).

Sharlikran

pushed a commit
to Wrye-Code-Collection/wrye-bash
that referenced
this issue

Apr 27, 2019

Squashed commit consisting of these 3 commits:

1. Drop MelModelHash in favor of MelNull

MelNull already does what we want - the definitions are almost
identical! The only real difference is that MelModelHash also saves the
texture hashes as an attribute of the record. This is obviously totally
unnecessary - we don't want to do anything with those hashes.

To that end, let's just drop those classes and use MelNull.

2. [SSE] Drop PROJ/NAM2 and BPDT/NAM5

These are texture hashes as well! zilav pointed this out [1], but it
looks like this got missed when the texture hash changes were originally
made. I don't know if WB actually patches or writes these, but better
safe than sorry.

[1] wrye-bash#403 (comment).

3. Correct texture hash explanation - TO BE SQUASHED

The actual explanation, as provided by zilav, is that texture hashes are
just an optimization and are totally optional - plenty of records in
Skyrim.esm don't have them.

Infernio

added

A-records

Area: Record Definitions (The brec package, mod_files.py and the game/*/records.py files)

and removed

C-bug

Category: Bug, an acknowledged defect in the program

labels

Apr 4, 2020

Источник

#62

Falcon

Отправлено 23 июля 2012 — 20:42

А. Хм. Не последняя. У меня 295.5, тут на сайте последняя только эта..

…И ветер свеж, и ночь темна,
и нами избран путь — дорога сна…
По дороге сна — лег плащом туман на плечи,
Стал короной иней на челе.
Острием дождя, тенью облаков —
Стали мы с тобою легче, чем перо у сокола в крыле…

Наверх

#63

Falcon

Отправлено 23 июля 2012 — 22:15

Таак. Установил версию 299. Вообще не запускается. Только начинает — и тут же вырубается.

Наверх

#64

Umbakano Jr

Отправлено 23 июля 2012 — 22:33

Таак. Установил версию 299. Вообще не запускается. Только начинает — и тут же вырубается.

Я сейчас проверил, установил и standalone версию и питон-версию… Обе работают! У меня вин7сп1 домашка…

Попробуй деинсталировать все через Панель Управления и установить заново…

Наверх

#65

Falcon

Отправлено 23 июля 2012 — 23:05

Он где-то находит файлы версии 295-5 и хочет сохранить настройки. Что бы я ему не говорил, он вылетает. Ставлю Питон-версию, надеюсь, поможет.

Наверх

#66

Falcon

Отправлено 23 июля 2012 — 23:23

Ничего не помогает. Потер эту гадость вручную при помощи динамита Far’a и кнопки F8. Вычистил отовсюду. Поставил снова. Теперь он не спрашивает, сохранить ли настройки старой версии. Просто вылетает. Потер снова, поставил 295-5. Работает. Потер. Поставил 299. Вылетает. Потер. Поставил 295. Работает. Поставил сверху 299. Вылетает.

Наверх

#67

Umbakano Jr

Отправлено 24 июля 2012 — 10:26

Ничего не помогает.

Вот архив. Выбери версию выше 295-5 и ниже 299…какая-то должна запустится…

Наверх

#68

Falcon

Отправлено 24 июля 2012 — 13:05

Ур-раа! 297.1 пошла! Спасибо огромное.

Наверх

#69

mix73

Отправлено 28 июля 2012 — 09:28

Всем добрый !
Система win7 64bit, игра лицуха.
Использую Wrye Bash с версии 297, ставил обе версии. В данном случае стоит версия Python, всегда выкидывает одну и туже ошибку, открывается окно Microsoft Visual C++ Runtime Library :
Runtime error ! Program:C:\Python27\pythonw.exe
R 6025
pure virtual function call
При этом игра запускается…

Наверх

#70

Umbakano Jr

Отправлено 28 июля 2012 — 10:11

Я посоветовал бы переустановить Wrye_Python, который уже версии 06… и попробовать более старшую версию Wrye Bash…

Наверх

#71

mix73

Отправлено 28 июля 2012 — 10:49

Поставил Wrye Bash 299 — Standalone Executable. При запуске выкидывает окно, откройте файл Wrye Bash.exe.log, для устранения ошибки. Внутри файла следующее :

Microsoft Visual C++ 2008 (x64) стоит. Игра не запускается.

Поставил так же Wrye Bash 299 — Python и пакет Wrye Python 06.exe. Запускаем через Wrye Bash Launcher.pyw или Wrye Bash Debug.bat ? При запуске с помощью Wrye Bash Debug.bat выкидывает «An invalid plugin load order has been corrected», потом окно с поврежденным плигином.
Меня смущает еще два момента :
1) кроме самого окна Wrye Bash, «весит» окно cmd.exe в панели задач, в котором сказано «Launching Wrye Bash debug mod». Если закрыть данное окно закрывается сам WB.
2) если включен авто выход WB, система выкидывает окно : «прекращена работа программы python.exe»
Так и должно быть ?
Далее игра запускается.

Наверх

#72

Umbakano Jr

Отправлено 28 июля 2012 — 13:56

Питон-версию Врай Баш запускать файлом Wrye Bash Launcher.pyw

Одиночную версию Врай Баш запускать файлом Wrye Bash.exe

Оба файла в папке Mopy…

Игра должна запускаться в любом случае, поскольку Врай Баш — это всего лишь менеджер модов…

Если игра не запускается — то проблема именно в модах (неправильная сортировка, конфликты и т.д…)

Наверх

#73

mix73

Отправлено 28 июля 2012 — 14:19

Спасибо огромное за терпение. :wink3:
Очень хочется разобраться в ситуации, так как к проге привык с Облы. Но тогда все работало как часы.
На данный момент ошибка не в модах как я понял, а в Microsoft Visual C++.
Два варианта событий :
1) Не включен авто выход WB
Запускаю файл Wrye Bash Launcher.pyw, а система спрашивает какой программой открыть его ?
Указвыаю pythonw.exe, запускается, ругается на плагин. Это рабочие моменты, WB не нравится внутренние параметры, не суть, идем далее.
Игра запускается.
2) Если включен авто выход WB
Запускаю игру через WB, появляется окно Microsoft Visual C++ Runtime Library с ошибкой :
«Runtime error ! Program:C:\Python27\pythonw.exe
R 6025
pure virtual function call»
Система закрывает WB, игра не запускается, так как операция прервана.
3) И еще вопросик, по программе BOSS
Его нужно кидать в Data, но тогда его не видит WB. Кинув в папку скайрима и запустив из под WB, виснет.
Заранее спасибо за советы.

Наверх

#74

Umbakano Jr

Отправлено 28 июля 2012 — 16:57

Сразу вношу ясность — если установлена одиночная версия (standalone) , то запускать программу нужно/можно только wrye bash.exe Это исполняемый файл… Никакие лаунчеры не нужны, любые ошибки с упоминанием python — сигнал, что у вас все перепутано!

Питон может и не быть в системе, но Врай Баш и тем более игра должны запускаться!

Другое дело, когда смешаны оба варианта.. и питоновский и одиночный… Я ставил их одновременно и запускал соответствующим образом и проблем не было! Они друг другу совсем не мешают…
Но, у меня 32-битная система на Вин7… А проблемы, похоже, у пользователей 64-битной системы…

Если библиотеку MS Visual C++ вы установили правильную (на сайте ссылки и на 32 и на 64 битную), тогда, проблема в самом Врай Баш… именно поэтому советую пробовать ставить все версии, не только самую последнюю…

Вопрос с авто выходом — не критичный… Во-первых можно не закрывать Врай Баш… Во-вторых, (если нужно освободить память), то можно не открывать Врай Баш! Он нужен только при установке/удалении модов и создании башед патча… В остальное время игру можно запускать стандартно или через лаунчер обсе…

Про БОСС так сразу ничего не скажу… надо почитать ридми, куда его ложить, чтобы он корректно работал… А запускать его через пиктограммку — можно настроить через ини файл… просто «повесив» на любую пустую…

Наверх

#75

mix73

Отправлено 28 июля 2012 — 17:20

Standalone версия вообще не запускается, так что остановился на Python, описывал ситуацию выше именно с ним.
То, что касается MS Visual C++, стоят именно по этой ссылке, притом и за 2005, 2008, 2010 года не пойму что WB не нравится.
С авто выходом согласен, ресурсов компа хватает.
Спасибо еще раз, поиграюсь может совсем исправлю ситуацию.

Наверх

#76

ZiZiTOP

ZiZiTOP

Новенький
1 сообщений

Отправлено 30 июля 2012 — 19:49

Здравствуйте! У меня такая проблема: после того как я перекинул все моды и запуска.В Wrye bash, у меня вылазит такое вот окно -Wrye Bash не смог определить игру для управления. Испоьзуйте аргумент командной строки -о для задания папки с игрой.- Хоть запускал через pyson, хоть просто, ничего.

Наверх

#77

Umbakano Jr

Отправлено 30 июля 2012 — 21:05

Здравствуйте! У меня такая проблема: после того как я перекинул все моды и запуска.В Wrye bash, у меня вылазит такое вот окно -Wrye Bash не смог определить игру для управления. Испоьзуйте аргумент командной строки -о для задания папки с игрой.- Хоть запускал через pyson, хоть просто, ничего.

Установите Врай Баш прямиком в папку с игрой… Это делается в момент выбора игры для установки!

DigmaRus это нравится

Наверх

#78

Vara

Vara

Новенький
7 сообщений

Отправлено 09 августа 2012 — 12:21

Здравствуйте! Пишу вам с проблемой установки Wrye bash. Скажу сразу, что в установках подобного опыт не имею, посему выскакивают ошибки.
Распишу проблему подробно и надеюсь получить подробный ответ, иначе буду доставать постами-вопросами, ведь могу не понять что-либо. Конечно, можете с такими заявлениями, типа «надеюсь получить подробный ответ», послать куда подальше, но очень буду благодарен, если поможете.
Итак, Skyrim у меня лицензионный, стимовский. Сам сижу с ноутбука и играю с него же.

Скачиваю файл Wrye_Bash_299.7z (19.5 МБ) (Архив скачал на Рабочий Стол), скачиваю «Microsoft Visual C++ 2008» х86 (Скачал на Рабочий Стол) и сразу устанавливаю, все, вроде бы, нормально. Далее начинаю устанавливать Wrye Bash:
1) Открываю архив Wrye bash;
2) Запускаю Wrye bash 299 — Installer.exe;
3) Выскакивает окно установки. Все на англ. яз, «кликаю Next». Попадаю на окно, которое установит Wrye bash в определенный путь. Задаю путь c:\program files (x86)\steam\steamapps\common\skyrim\, ставлю галочку на Install for Skyrim, уже поставлена галочка на Wrye bash [Standalone], снимаю галочку с Wrye bash [Python], на Install to extra locations окошечко пустует (галочку не ставил. Вот скриншот: http://i5.pixs.ru:/s…509_5476007.jpg ). Кликаю «Next»;
4) Выскакивает следующее окно: http://i5.pixs.ru:/s…792_5476015.jpg . Кликаю «Next»;
5) http://i5.pixs.ru:/s…113_5476020.jpg . Кликаю «Next»;
6) http://i5.pixs.ru:/s…130_5476027.jpg — тут автоматически уже поставлены две галочки. Кликаю на «Install»;
7) Происходит установка ( http://i5.pixs.ru:/s…563_5476030.jpg ), кликаю Next;
Финиш. Установка завершена, снимаю галочку с View Readme ( http://i5.pixs.ru:/s…732_5476036.jpg ) и кликаю «Close».

В корневой папке Skyrim появляется новая папка «Mopy» ( http://pixs.ru/showi…574_5476120.jpg ). Захожу в эту папку, вижу следующие файлы: http://pixs.ru/showi…916_5476142.jpg . Жму на файл Wrye Bash.exe для запуска программы, но вместо запуска у меня этот файл в виде txt и открывается блокнотом и вот что написано: http://pixs.ru/showi…164_5476156.jpg . Что мои кривые руки сделали не так?

Пока буду играть, как и играл раньше, без Wrye bash. И, естественно, буду ждать вашей помощи или посыла куда подальше.

С Ув., Дмитрий.

Наверх

#79

Umbakano Jr

Отправлено 09 августа 2012 — 13:31

Ну почему же кривые? Вы все сделали правильно! А недостаток знаний операционной системы Виндовс со временем компенсируется опытом…

Итак, вы пытаетесь запустить программу тестовым файлом! Несмотря на свое название «Wrye Bash.exe» этот файл имеет расширение «log» и является текстовым… в нем описаны ошибки при запуске программы…

Запускать надо файл выше (с красной пиктограммой)… а правильнее запускать через меню «Пуск», там создана группа Wrye Bash и в ней есть пункт «Wrye Bash — Skyrim»…

Но, учитывая версию Врай Баш и ошибку в лог файле, возможно, что программа действительно не запустится! Тогда вам придется установить или более младшую версию Врай Баш или старшую (тестовую)…

И немножко о грустном…
Картинка в пункте 4, сообщает о том, что ваша игра установлена в системную папку «Program Files»… как, собственно, и стим… а это категорически не рекомендуется!

Vara это нравится

Наверх

#80

Vara

Vara

Новенький
7 сообщений

Отправлено 09 августа 2012 — 15:18

Прочитав ваш пост — так и сделал. Через пуск нажал — «Wrye Bash — Skyrim» выдал ошибку и исчез.
Поэтому пришлось лезть в корневую папку, чтобы запустить файл с красной пиктограммой.
Вот скриншот: http://pixs.ru/showi…333_5477335.jpg

Видимо придется устанавливать младшую или старшую версию. Если все сводится к переустановке другой версии — какая лучше? Младшая или Старшая (то, что вы написали, что она тестовая — настораживает).

Почему категорически не рекомендуется устанавливать Steam и Skyrim в «Program Files»?
Расскажите, пожалуйста, поподробнее.
Я сижу с ноутбука. Купил, чтобы не умереть со скуки на отдыхе. Я бы переустановил и Steam и Skyrim, но тут интернет тупит, т.к. живу в деревне и связь с модемом очень плохая. Но, теоретически, я смогу в городе найти определенную точку, где будет хорошо ловить сеть. Кстати, тогда куда устанавливать Steam и Skyrim?
Вот скриншот моих папок на диске С: http://pixs.ru/showi…637_5477436.jpg

С Ув., Дмитрий.

Наверх

#81

Umbakano Jr

Отправлено 09 августа 2012 — 17:46

… Купил, чтобы не умереть со скуки на отдыхе…

Да… красиво жить не запретишь!..

Наверное, проще из тестовой версии скопировать две папки (Data и Mopy) поверх имеющихся… к тому же тестовая версия у меня стоит-работает, а другие младшие версии я не проверял — сразу «переехал» с 295.5

Проблемы из-за системной папки Program Files возникнут, как только захочешь ставить моды или программы ими управляющие… постоянные вопросы UAC прерывают программу — не дают ей работать… даже запустив wrye bash, он не сможет работать с файлами модов, потому что все, что находится в Program Files, ОС расценивает как критически важное и «оберегает» от изменений…

Ставить можно в любую папку которую создашь сам, например, C:\Steam. Почему в примере стим? Потому что туда по-умолчанию встанет игра! Переустанавливать придется и стим и игру…
Но, раз интернет ограничен, то имел бы смысл просто переместить текущую папку стима, и подредактировать все упоминания о стим и игре в реестре ОС… но, тут нужны «продвинутые» знания…

Наверх

Источник

#1

Posted 08 October 2015 — 08:36 am

BinaryMessiah

Fan

Supporter
394 posts

I’ve been using Wrye Bash for 3 years now, and out of nowhere I’m getting the following error upon startup

Traceback (most recent call last):

File «bash\balt.pyo», line 1803, in _conversation_wrapper

File «bash\basher\__init__.pyo», line 4116, in RefreshData

File «bash\basher\__init__.pyo», line 4196, in _corruptedWarns

File «bash\balt.pyo», line 1215, in Display

File «bash\balt.pyo», line 2799, in __init__

File «bash\balt.pyo», line 481, in listBox

File «wx\_controls.pyo», line 1290, in __init__

TypeError: String or Unicode type required

I researched and can’t find out what this means. I have reinstalled Wrye Bash twice and it won’t go away. I’m noticing it was auto refresh anymore when clicking back into the window.

#2

BIGBROHTER369

Posted 09 October 2015 — 03:59 pm

BIGBROHTER369

Newbie

Members
17 posts

im having the same issue , i hope that it will be a fix for this

#3

ironbender800

Posted 09 October 2015 — 09:12 pm

Wrye Bash works just fine for me. I run as executable from within mod organizer. using standalone 306

#4

saurusmaximus

Posted 09 October 2015 — 11:42 pm

saurusmaximus

Faithful poster

Premium Member
1,911 posts

I would try posting this one directly to the Wrye Bash team, if anyone knows it’s them :laugh:

#5

BinaryMessiah

Posted 11 October 2015 — 05:16 am

BinaryMessiah

Fan

Supporter
394 posts

After cleaning a bunch of my Skyrim files the error went away. I had about 15 dirty edits and continued to crash when leaving Riverwood.

#6

CaliburnusPDX

Posted 10 January 2016 — 05:04 am

CaliburnusPDX

Regular

Premium Member
94 posts

I’m new to using Wrye Bash and only installed it recently (Standalone version 306).

Every time I boot it up I get this error:

Traceback (most recent call last):
File «bash\balt.pyo», line 1796, in _conversation_wrapper
File «bash\basher\__init__.pyo», line 4101, in RefreshData
File «bash\basher\__init__.pyo», line 4181, in _corruptedWarns
File «bash\balt.pyo», line 1206, in Display
File «bash\balt.pyo», line 2792, in __init__
File «bash\balt.pyo», line 483, in listBox
File «wx\_controls.pyo», line 1290, in __init__
TypeError: String or Unicode type required

Also, I discovered that any changes made with the Tweak Settings when rebuilding the patch do not take effect in-game. So, naturally, now I don’t trust the patch, even though I get no other errors when using the program.

I don’t have any esp files with dirty edits, but obviously there is a file WB is scanning somewhere it doesn’t like, even though it boots up quickly and seems to be running fine (on the surface) with no other errors. (sigh)

I’m assuming it’s some particular mod that is the culprit and a commonly-used one, apparently, since I’ve seen this complaint from several people so far.

I’ve been working on this build for several weeks and I’m ready to get started (dammit). I thought it was squeaky-clean, but this one glitch is making me afraid to start playing and making saves. Hopefully someone will discover why this is occurring and post it.

#7

Meggan0401

Posted 11 April 2016 — 04:59 pm

Meggan0401

Enthusiast

Premium Member
224 posts

Yeah, same here. I’ve used Wrye Bash for a while now and have not added a different load order. I get that exact same error and I can’t find a solution. Every mod I use has been cleaned, I’ve reinstalled Wrye Bash with NMM the latest versions of both. I still get that error lately. Don’t know why.
I’ve even gone to google and have found lots of recent posts about the same issue but with no solution to it or understanding of the reason behind it.

#8

MyHouseatl

Posted 12 April 2016 — 06:21 am

Yeah, same here. I’ve used Wrye Bash for a while now and have not added a different load order. I get that exact same error and I can’t find a solution. Every mod I use has been cleaned, I’ve reinstalled Wrye Bash with NMM the latest versions of both. I still get that error lately. Don’t know why.
I’ve even gone to google and have found lots of recent posts about the same issue but with no solution to it or understanding of the reason behind it.

I’m having the same issue. I wonder if it has something to do with a Java update. It seems to have started after I updated Java.

#9

Kyndra72

Posted 26 May 2016 — 05:21 pm

Kyndra72

Enthusiast

Supporter
232 posts

Just letting people know I had the same issue, the cause for me was «numenume femalebrows MARO». I uninstalled it and the error went away o-o

#10

nazantia

Posted 25 July 2016 — 09:51 am

nazantia

Newbie

Supporter
10 posts

Just had this error exactly as quoted above. I had downloaded some new mods so I unchecked them all and rechecked them one by one. It was caused by the mod Frostmourne nexus id 6031. My suggestion to anyone with this error is to sort your mods by install date and disable the recent. Then re-enable them one by one and start Wrye Bash until you find the culprit.

Источник

297 ругается так же:

Error! Unable to start Wrye Bash.

Please ensure Wrye Bash is correctly installed.

Traceback (most recent call last):

File «bash\bash», line 362, in main

File «bash\bosh», line 31116, in initBosh

File «bash\bosh», line 30857, in initDirs

File «bash\bosh», line 30775, in getPersonalPath

File «bash\bosh», line 30663, in getShellPath

UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xee in position 9: ordinal not in range(128)

* работа в режимах совместимости не помогает.

открыл файлы, нашёл проблемные строки:

362 bosh.initBosh(opts.personalPath,opts.localAppDataPath,opts.oblivionPath)

31116 initDirs(bashIni,personal,localAppData, oblivionPath)

30857 personal = getPersonalPath(bashIni,personal)

30775 path = getShellPath(‘Personal’)

30663 path = reEnv.sub(subEnv,path)

не понятно.

путь для WB скайрима такой: E:\steam\steamapps\common\skyrim\Mopy

для облы: E:\_spieles\Oblivion\Mopy

Может всё это из-за тго, что имя пользователя windows на русском?

**пробовал шаманить с правами и UAC — не помогло. Google выдаёт по моей проблеме лишь такой же вопрос и ни одного ответа с решением проблемы…

Изменено 10 июня, 2012 пользователем kodex

Источник

Comments

Интересное по теме: