Wrye bash выдает ошибку при запуске

Привет всем.
ребят, Играл в скайрим с кучей модов(налаженых, без конфликтов) около 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 «bashbash», line 467, in main
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xc2 in position 9: ordinal not in range(128)

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

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

Error! Unable to start Wrye Bash.

Please ensure Wrye Bash is correctly installed.

Traceback (most recent call last):

File «bashbash», line 362, in main

File «bashbosh», line 31116, in initBosh

File «bashbosh», line 30857, in initDirs

File «bashbosh», line 30775, in getPersonalPath

File «bashbosh», 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:steamsteamappscommonskyrimMopy

для облы: E:_spielesOblivionMopy

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

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

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

Wrye Bash won’t start.

#11

Traceback (most recent call last):
File «Wrye Bash Launcher.pyw», line 32, in
File «zipextimporter.pyo», line 92, in load_module
File «bashbash.pyo», line 40, in
File «zipextimporter.pyo», line 92, in load_module
File «bashbolt.pyo», line 292, in
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe5 in position 15: ordinal not in range(128)

I checked the Wrye Bash Documentation for «If it won’t start», but it says nothing of this issue.
Help would be massively appreciated.

#12

Internet Addict :^P

Traceback (most recent call last):
File «Wrye Bash Launcher.pyw», line 32, in
File «zipextimporter.pyo», line 92, in load_module
File «bashbash.pyo», line 40, in
File «zipextimporter.pyo», line 92, in load_module
File «bashbolt.pyo», line 292, in
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe5 in position 15: ordinal not in range(128)

I checked the Wrye Bash Documentation for «If it won’t start», but it says nothing of this issue.
Help would be massively appreciated.

This should be fixed with r2586, but we need someone to test it that’s actually getting the error, as it’s a locale-specific bug, and I can’t seem to trigger it by changing windows settings.

Same problem. Seems like i fixed it by starting WryeBash from the command line, and with the arguments «-L English».
D:SpillSteamsteamappscommonskyrimMopy>»Wrye Bash.exe» -L English

bluesky: I’ll try, but whenever I try to reproduce this error, it doesn’t give me problems. I had mentioned earlier that it *may* be a Standalone problem (with how it’s built) if the error is showing up in only the Standalone build. This is because the library needed to access the user profile info in unicode mode is pywin32, which also has some very big issues being included in the Standalone version correctly. I know *most* of it at least is getting included, because the program does run, but it could be missing one of the file needed to get the user profile correctly. As such, Bash would fall back to a backup method, but unfortunately, that method doesn’t return unicode, it returns encoded data. A mess to say the least.

I know I’ve tried before by changing my username to something with russian characters in it, and Bash had no problem finding my data. I’ll try again, but I think it’s a Standalone problem like I said, so it may take quite a while to overcome, simply because it’s really hard to get the Standalone to include all of pywin32’s stuff.

Edit: As a temporary solution, I’d recommend having them switch to the Python build. It should alleviate their problems until I can figure it out.

Edit 2: Ok, just confirmed it’s definitely a Standalone problem. Somewhere in the build process those sneaky pywin32 files aren’t all getting included. You and anyone else experiencing this issue an swap to the Python build and everything should work right.

Now to beat py2exe into shape, make it do its job right (which will be tricky, since I’m running x64 Python. py2exe isn’t quite as capable on x64. Should still do the job though).

Edited by Lojack, 12 November 2012 — 12:12 PM.

A lot of stuff above. The only new info I see is that if the version of Python you have installed is building the moduals improperly then you can have this problem? a complete reinstall of the Mopy folder and making sure to use the latest version of Wrye Python 08

Wrye Bash — Skyrim Modding — Dark Creations
#13
You’d want to install Wrye Python 8 (which I didn’t even know we had yet) and then follow the instructions in the OP on the official Wrye Bash thread to download and use the SVN version.

Edited by Apprentice Harper, 27 December 2012 — 04:38 pm.

Источник

Wrye Bash и Skyrim

#21 Siegrun

Отправлено 18 февраля 2012 — 12:59

Тема для вопросов и ответов. Кто использует сам — помогите другим.

Кроме верной установки Питона (для Облы) и верного выбора версии для вашей системы:

МОДЫ и архивы, устанавливаемые с wrye bash, должны иметь написание названия и пути НА ЛАТИНИЦЕ.
ВАШ аккаунт на компе (имя пользователя) должен иметь написание и пути НА ЛАТИНИЦЕ.

Да я тоже тебя люблю (пока его тут нет). © Монгол
Я трудный человек, но если вы рядом со мной, то и вы не простые люди.

• Авторизуйтесь для ответа в теме

#22 Unheath

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

#23 Umbakano Jr

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

Угу,но опять же,я установил ту же версию,что и до этого..переименовал все моды — получилось,единственное..пока не могу найти как всё это дело в башед патч запихать..)

#24 Джигаллаг

Отправлено 21 мая 2012 — 10:47

#25 Umbakano Jr

Отправлено 21 мая 2012 — 13:13

При установке не предлагает мне выбрать Скайрим, только лишь Обливион, видимо это из-за установленного Врая на Обливион, но как быть? теперь мне не поиграть в Скайрим, пока не снесу Обливион?

#26 Джигаллаг

Отправлено 21 мая 2012 — 13:31

#27 Umbakano Jr

Отправлено 21 мая 2012 — 14:16

Скайрим лицензионный. Ладно будем пробовать без баша, просто с модами очень удобно работать через него.

Да, привычка — страшная сила, сам без него не могу.

Если сильно хочется, попробуй активировать галочку «Install to extra locations». станет доступна строка и кнопка выбора произвольной папки, в которой и укажи папку со Скайримом. И если не хочешь заменить версию для Обливиона при этом, то сними все флажки для него.

#28 Джигаллаг

Отправлено 21 мая 2012 — 14:50

#29 Lina Invers

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

Всё установила но вот что выбивает.Это на Wrye Bash

Error! Unable to start Wrye Bash.

Please ensure Wrye Bash is correctly installed.

Traceback (most recent call last):
File «bashbash», line 347, in main
File «bashbosh», line 30478, in initBosh
File «bashbosh», line 30230, in initDirs
File «bashbosh», line 30152, in getPersonalPath
File «bashbosh», line 30152, in
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xc2 in position 9: ordinal not in range(128)

А на Wrye Bash Launcher

Имя пользователя перевела на английский,но всё равно выдает эту ошибку((((
Плиззз помогите
Заранее спасибо

Хатя я всё скачала и установила.

#30 Umbakano Jr

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

Там, к сожалению, качается «неправильная» для русских систем библиотека.

Скачайте и установите wxPython2.8-win32-unicode-2.8.12.0-py27.exe, а тот что сейчас установлен (имя тоже, только приставка ansi) деинсталируйте из системы.

#31 Alchemist

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

сегодня зашел в wrye bash и вот такая там фиготень

Update.esm: Unexpected subrecord: ‘TES4.INCC’
Error loading ‘TES4’ record and/or subrecord: 00000000
eid = u’ >’
subrecord = ‘INCC’
subrecord size = 4
Update.esm: Unexpected subrecord: ‘TES4.INCC’
Error loading ‘TES4’ record and/or subrecord: 00000000
eid = u’ >’
subrecord = ‘INCC’
subrecord size = 4

может связано с недавним багованным патчем?

#32 Umbakano Jr

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

может связано с недавним багованным патчем?

#33 Alchemist

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

#34 Umbakano Jr

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

Обнова патча произошла, но bash лагает по прежнему. Что делать?

У меня была та же ошибка, но я откатывался на предыдущую версию игры и потом прошла стандартная обнова. врай баш показывает, что все нормально .

Проблема в самом Wrye Bash! Скачайте последнюю 297.1 версию с нексуса. там все работает!

Сообщение отредактировал Umbakano Jr: 13 июня 2012 — 22:19

Источник

Wrye bash error occurred

Hello there! To get to the point, my Wrye Bash seems to be unable to detect my Mod Organizer’s mods for my Skyrim. For some reason, it’s trying to read Fallout 4, but all my directories aim towards Skyrim, which is odd.

If your Wrye Bash works, perhaps we can compare directories or something? Any other ideas are appreciated. Thanks.

You are running Wrye Bash via Mod Organizer right?

From MO2 Discord.
Programs can’t see the mods:
1) First thing is that programs like the game and LOOT that you want to be able to see the mods need to be launched from Mo2 to be hooked by the MO2 Virtual File System (USVFS) so you need to be doing that.
2) You should check whether USVFS is actually running and is not blocked for some reason, to do that you should check if the USVFS logs in the MO2 logs folder are empty (write !get logs on this channel for info on how to get the logs). Best way to check is to delete all the logs there, run MO2, run the program not seeing the mods, close both and check if the usvfs logs contain something.
If the logs result empty write !get blanklogs in this channel to see reasons and solutions for that case.
3) If the logs are not empty you should upload them on discord so we can see what is going on, best if you follow the instructions provided by !get debuglogs to set them to debug level information.
One possibility though is that the program that you are starting through MO2 is not looking at the same game installation that is being managed, thus not seeing the mods, please check that isn’t the case.
4) If you have issues with SKSE not seeing SKSE plugins and you are using a Steamless game executable then you should add the -forcesteamloader argument to the SKSE executable.

Источник

Wrye Bash и Skyrim

#21 Siegrun

Отправлено 18 февраля 2012 — 12:59

Тема для вопросов и ответов. Кто использует сам — помогите другим.

Кроме верной установки Питона (для Облы) и верного выбора версии для вашей системы:

МОДЫ и архивы, устанавливаемые с wrye bash, должны иметь написание названия и пути НА ЛАТИНИЦЕ.
ВАШ аккаунт на компе (имя пользователя) должен иметь написание и пути НА ЛАТИНИЦЕ.

Да я тоже тебя люблю (пока его тут нет). © Монгол
Я трудный человек, но если вы рядом со мной, то и вы не простые люди.

• Авторизуйтесь для ответа в теме

#22 Unheath

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

#23 Umbakano Jr

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

Угу,но опять же,я установил ту же версию,что и до этого..переименовал все моды — получилось,единственное..пока не могу найти как всё это дело в башед патч запихать..)

#24 Джигаллаг

Отправлено 21 мая 2012 — 10:47

#25 Umbakano Jr

Отправлено 21 мая 2012 — 13:13

При установке не предлагает мне выбрать Скайрим, только лишь Обливион, видимо это из-за установленного Врая на Обливион, но как быть? теперь мне не поиграть в Скайрим, пока не снесу Обливион?

#26 Джигаллаг

Отправлено 21 мая 2012 — 13:31

#27 Umbakano Jr

Отправлено 21 мая 2012 — 14:16

Скайрим лицензионный. Ладно будем пробовать без баша, просто с модами очень удобно работать через него.

Да, привычка — страшная сила, сам без него не могу.

Если сильно хочется, попробуй активировать галочку «Install to extra locations». станет доступна строка и кнопка выбора произвольной папки, в которой и укажи папку со Скайримом. И если не хочешь заменить версию для Обливиона при этом, то сними все флажки для него.

#28 Джигаллаг

Отправлено 21 мая 2012 — 14:50

#29 Lina Invers

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

Всё установила но вот что выбивает.Это на Wrye Bash

Error! Unable to start Wrye Bash.

Please ensure Wrye Bash is correctly installed.

Traceback (most recent call last):
File «bashbash», line 347, in main
File «bashbosh», line 30478, in initBosh
File «bashbosh», line 30230, in initDirs
File «bashbosh», line 30152, in getPersonalPath
File «bashbosh», line 30152, in
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xc2 in position 9: ordinal not in range(128)

А на Wrye Bash Launcher

Имя пользователя перевела на английский,но всё равно выдает эту ошибку((((
Плиззз помогите
Заранее спасибо

Хатя я всё скачала и установила.

#30 Umbakano Jr

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

Там, к сожалению, качается «неправильная» для русских систем библиотека.

Скачайте и установите wxPython2.8-win32-unicode-2.8.12.0-py27.exe, а тот что сейчас установлен (имя тоже, только приставка ansi) деинсталируйте из системы.

#31 Alchemist

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

сегодня зашел в wrye bash и вот такая там фиготень

Update.esm: Unexpected subrecord: ‘TES4.INCC’
Error loading ‘TES4’ record and/or subrecord: 00000000
eid = u’ >’
subrecord = ‘INCC’
subrecord size = 4
Update.esm: Unexpected subrecord: ‘TES4.INCC’
Error loading ‘TES4’ record and/or subrecord: 00000000
eid = u’ >’
subrecord = ‘INCC’
subrecord size = 4

может связано с недавним багованным патчем?

#32 Umbakano Jr

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

может связано с недавним багованным патчем?

#33 Alchemist

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

#34 Umbakano Jr

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

Обнова патча произошла, но bash лагает по прежнему. Что делать?

У меня была та же ошибка, но я откатывался на предыдущую версию игры и потом прошла стандартная обнова. врай баш показывает, что все нормально .

Проблема в самом Wrye Bash! Скачайте последнюю 297.1 версию с нексуса. там все работает!

Сообщение отредактировал Umbakano Jr: 13 июня 2012 — 22:19

Источник

Hello,
I was trying to install Wrye Bash v 306 Stand alone version for the fist time on my computer, but it seems to crash at launch with following error

testing UAC
Traceback (most recent call last):
File «Wrye Bash Launcher.pyw», line 88, in
bash.main()
File «bashbash.pyo», line 382, in main
File «bashbash.pyo», line 364, in main
File «bashbosh.pyo», line 10441, in initBosh
File «bashbosh.pyo», line 10240, in initDirs
File «bashbosh.pyo», line 5247, in init
File «bashbosh.pyo», line 5278, in refreshBashTags
File «bashloot.pyo», line 334, in Load
File «bashloot.pyo», line 231, in LootErrorCheck
bash.bolt.BoltError: An error occurred while parsing taglist.yaml with the LOOT API: LootError: loot_error_parse_fail:’utf8′ codec can’t decode byte 0xd1 in position 21: invalid continuation byte

The system version is Win 7 x64 . I installed Wrye Bash through installer and intended to use it for Oblivion (retail copy). I belive that i installed it correctly because i was following the installation guide step by step. Also i use LOOT v 0.10.1. All programs are installed in D:/Oblivion directory as was reccomended in guides and at forums.
I tried to look for similar errors in the web but could find the one that maches mine. Can somebody help me to understand what can possibly cause the erorr? Thanks in advance.

Hello,
I was trying to install Wrye Bash v 306 Stand alone version for the fist time on my computer, but it seems to crash at launch with following error

testing UAC
Traceback (most recent call last):
File «Wrye Bash Launcher.pyw», line 88, in
bash.main()
File «bashbash.pyo», line 382, in main
File «bashbash.pyo», line 364, in main
File «bashbosh.pyo», line 10441, in initBosh
File «bashbosh.pyo», line 10240, in initDirs
File «bashbosh.pyo», line 5247, in init
File «bashbosh.pyo», line 5278, in refreshBashTags
File «bashloot.pyo», line 334, in Load
File «bashloot.pyo», line 231, in LootErrorCheck
bash.bolt.BoltError: An error occurred while parsing taglist.yaml with the LOOT API: LootError: loot_error_parse_fail:’utf8′ codec can’t decode byte 0xd1 in position 21: invalid continuation byte

The system version is Win 7 x64 . I installed Wrye Bash through installer and intended to use it for Oblivion (retail copy). I belive that i installed it correctly because i was following the installation guide step by step. Also i use LOOT v 0.10.1. All programs are installed in D:/Oblivion directory as was reccomended in guides and at forums.
I tried to look for similar errors in the web but could find the one that maches mine. Can somebody help me to understand what can possibly cause the erorr? Thanks in advance.

Comments

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.

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.

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.

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:

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)

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

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.