Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

Got to go to work ASAP but managed to get a quick bug dump

Wrye Bash starting
Using Wrye Bash Version 307.201710221607 (Standalone)
OS info: Windows-10-10.0.15063
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
Using scandir 1.5
bash.pyo  316 _main: Searching for game to manage:
bush.pyo   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   78 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   78 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   78 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  142 _detectGames: Set game mode to Oblivion found in parent directory of Mopy:  E:\Oblivion
bush.pyo  156 __setGame:  Using Oblivion game: E:\Oblivion
testing UAC
mods_metadata.pyo  228 __init__: Using LOOT API version: 0.10.1
barb.pyo  180 Apply: 
barb.pyo  181 Apply: BACKUP BASH SETTINGS: D:\Steam\steamapps\Common\Skyrim Special Edition Mods\Bash Mod Data\Backup Bash Settings Oblivion (2017-10-22 14.29.51) v307.201710141454-307.201710221607.7z
barb.pyo  193 _backup_settings: Oblivion Mods\Bash Installers\Bash\Converters.dat.bak <-- E:\Oblivion Mods\Bash Installers\Bash\Converters.dat.bak
barb.pyo  193 _backup_settings: Oblivion Mods\Bash Mod Data\Table.dat.bak <-- E:\Oblivion Mods\Bash Mod Data\Table.dat.bak
barb.pyo  193 _backup_settings: Oblivion\Mopy\bash\l10n\Russian.txt <-- E:\Oblivion\Mopy\bash\l10n\Russian.txt
barb.pyo  193 _backup_settings: Oblivion\Mopy\bash\l10n\Italian.txt <-- E:\Oblivion\Mopy\bash\l10n\Italian.txt
barb.pyo  193 _backup_settings: Oblivion Mods\Bash Mod Data\Table.dat <-- E:\Oblivion Mods\Bash Mod Data\Table.dat
barb.pyo  193 _backup_settings: Oblivion\Mopy\bash\l10n\Chinese (Simplified).txt <-- E:\Oblivion\Mopy\bash\l10n\Chinese (Simplified).txt
barb.pyo  193 _backup_settings: Oblivion Mods\Bash Installers\Bash\Installers.dat <-- E:\Oblivion Mods\Bash Installers\Bash\Installers.dat
barb.pyo  193 _backup_settings: My Games\Oblivion\BashLoadOrders.dat.bak <-- D:\Documents\My Games\Oblivion\BashLoadOrders.dat.bak
barb.pyo  193 _backup_settings: Oblivion Mods\Bash Installers\Bash\Installers.dat.bak <-- E:\Oblivion Mods\Bash Installers\Bash\Installers.dat.bak
barb.pyo  193 _backup_settings: My Games\Oblivion\Saves\Bash\Table.dat.bak <-- D:\Documents\My Games\Oblivion\Saves\Bash\Table.dat.bak
barb.pyo  193 _backup_settings: My Games\Oblivion\BashSettings.dat.bak <-- D:\Documents\My Games\Oblivion\BashSettings.dat.bak
barb.pyo  193 _backup_settings: Oblivion\Mopy\bash\l10n\de.txt <-- E:\Oblivion\Mopy\bash\l10n\de.txt
barb.pyo  193 _backup_settings: Oblivion\Mopy\bash\l10n\Chinese (Traditional).txt <-- E:\Oblivion\Mopy\bash\l10n\Chinese (Traditional).txt
barb.pyo  193 _backup_settings: My Games\Oblivion\BashLoadOrders.dat <-- D:\Documents\My Games\Oblivion\BashLoadOrders.dat
barb.pyo  193 _backup_settings: Oblivion\Mopy\bash\l10n\pt_opt.txt <-- E:\Oblivion\Mopy\bash\l10n\pt_opt.txt
barb.pyo  193 _backup_settings: Oblivion Mods\Bash Installers\Bash\Converters.dat <-- E:\Oblivion Mods\Bash Installers\Bash\Converters.dat
barb.pyo  193 _backup_settings: My Games\Oblivion\Saves\Bash\Table.dat <-- D:\Documents\My Games\Oblivion\Saves\Bash\Table.dat
barb.pyo  193 _backup_settings: My Games\Oblivion\BashSettings.dat <-- D:\Documents\My Games\Oblivion\BashSettings.dat
 

And a succesfull OMOD extraction into a project folder :D - The Sensual walks omod now gets extracted with Drag n Drop

Link to comment
Share on other sites

I'm getting a new error now when trying to activate any mod (ESL/esp/esm):

Traceback (most recent call last):
  File "bash\basher\__init__.py", line 959, in OnKeyUp
    self._toggle_active_state(*selected)
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\basher\__init__.py", line 1027, in _toggle_active_state
    activated = self.data_store.lo_activate(inact, doSave=False)
  File "bash\bosh\__init__.py", line 2314, in lo_activate
    if fileName[-3:] != u'esl': # don't check limit if we try to activate an esl
TypeError: 'Path' object has no attribute '__getitem__'

Link to comment
Share on other sites

Hello,

I'm interested in Wrye Bash and its ability to detect conflicts with BSA content, but it doesn't seem to work with me (Skyrim SE).
I'm new with it and I just reinstalled Windows (everything else was on another drive) and updated Wrye Bash from the Nexus' Skyrim SE mod page, so it's probably an error on my end, so I thought I'd try my luck here instead of filing a bug report.

  • Tested with SkyUI vs SkyUI - show armor slots - updated - SE and NAT - Natural and Atmospheric Tamriel v4.1 vs v4.2, both as uninstalled and installed packages or projects.
  • The "Show BSA conflicts" feature is activated in the "Installers" tab. The "Conflicts" tab gets added 2 empty section titled "BSA Conflicts" and "Loose File Conflicts".
  • The 2 versions of NAT still show the conflicts for the BSAs themselves, and the SkyUI addon files still show as missing (SkyUI has BSA, the addon has replacing loose files).
  • No error message. No bash.ini file.
  • WB version 307.2017.1022.2147 StandAlone for SSE (updated from NexusMods' SSE version).
  • Windows 10 (freshly-ish reinstalled), Fall Creator Update.
  • Game installed on an other HDD (D:\JEUX\- STEAM -\steamapps\common\Skyrim Special Edition\), with Wrye Bash in a subfolder "Mopy" and a folder "Skyrim Special Edition Mods" at the same level as the game folder.
  • Apart from that, mod installation works as expected, I think.

Can anyone help?
Thanks in advance.

Link to comment
Share on other sites

10 hours ago, Tastou said:

Hello,

I'm interested in Wrye Bash and its ability to detect conflicts with BSA content, but it doesn't seem to work with me (Skyrim SE).
I'm new with it and I just reinstalled Windows (everything else was on another drive) and updated Wrye Bash from the Nexus' Skyrim SE mod page, so it's probably an error on my end, so I thought I'd try my luck here instead of filing a bug report.

  • Tested with SkyUI vs SkyUI - show armor slots - updated - SE and NAT - Natural and Atmospheric Tamriel v4.1 vs v4.2, both as uninstalled and installed packages or projects.
  • The "Show BSA conflicts" feature is activated in the "Installers" tab. The "Conflicts" tab gets added 2 empty section titled "BSA Conflicts" and "Loose File Conflicts".
  • The 2 versions of NAT still show the conflicts for the BSAs themselves, and the SkyUI addon files still show as missing (SkyUI has BSA, the addon has replacing loose files).
  • No error message. No bash.ini file.
  • WB version 307.2017.1022.2147 StandAlone for SSE (updated from NexusMods' SSE version).
  • Windows 10 (freshly-ish reinstalled), Fall Creator Update.
  • Game installed on an other HDD (D:\JEUX\- STEAM -\steamapps\common\Skyrim Special Edition\), with Wrye Bash in a subfolder "Mopy" and a folder "Skyrim Special Edition Mods" at the same level as the game folder.
  • Apart from that, mod installation works as expected, I think.

Can anyone help?
Thanks in advance.

I don't quite get what's the problem ? Thanks for using wip version - that's the most up to date. Please always post a bugdump

Link to comment
Share on other sites

22 hours ago, Utumno said:

So I will need help doing this, as in real help. Roll up your sleeves ?

I have no Python coding skills, so I'm not sure I'd be "real" help, but I have FO3 & FNV and am at your service.

Link to comment
Share on other sites

5 hours ago, Utumno said:

I don't quite get what's the problem ? Thanks for using wip version - that's the most up to date. Please always post a bugdump

Well, unless I'm mistaken, I should see a list of conflicting files in the "Conflicts" tab between SkyUI and its addon (its loose files overwrite some files in the SkyUI BSA), and between both versions of NAT (both BSAs) ; but I don't.

BugDump (sorry for the omission, I thought it was only for error messages):

Wrye Bash starting
Using Wrye Bash Version 307.201710222147 (Standalone)
OS info: Windows-10-10.0.16299
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('fr_FR', 'cp1252')
filesystem encoding: mbcs
Using scandir 1.5
bash.pyo  316 _main: Searching for game to manage:
bush.pyo   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   78 _supportedGames:  Skyrim Special Edition: D:\JEUX\- STEAM -\steamapps\common\Skyrim Special Edition
bush.pyo  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  142 _detectGames: Set game mode to Skyrim Special Edition found in parent directory of Mopy:  D:\JEUX\- STEAM -\steamapps\common\Skyrim Special Edition
bush.pyo  156 __setGame:  Using Skyrim Special Edition game: D:\JEUX\- STEAM -\steamapps\common\Skyrim Special Edition
testing UAC
mods_metadata.pyo  228 __init__: Using LOOT API version: 0.10.1
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dragonborn.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Dawnguard.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Skyrim.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for HearthFires.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for Update.esm
__init__.pyo  907 isMissingStrings: Scanning BSAs for string files for ccqdrsse001-survivalmode.esl

Thanks.

Link to comment
Share on other sites

I should remove those debug prints (a bugdump in spoiler tags just gives me a great overview of what's your Bash install). Well unfortunately as discussed here: http://forums.bethsoft.com/topic/1615914-wrye-bash-thread-114/page-3#entry25314192 this conflicts thing is half baked - it won't show conflicts between loose files and bsas. Not trivial to implement (plus with esls etc I have a lot on my plate). In 308 we will hopefully have a bsa tab, if there are enough coding hands.

One of the difficulties is that actually scanning the bsas takes time and memory - not simple to code this nicely.

Link to comment
Share on other sites

There a bug report on Skyrim LE Nexus which I cant reproduce in Skyrim SE ..

I dont think we are going to get a bashbugdump.log for that one though :

Quote

Trying to do a bashed patch gives me an error: Processing error Update.esm: BAD TOP GRUP TYPE: ''VOLI''.

i am using the WIP standalone 307.201710222147 and searched all over the internet and could not find a fix, can someone help me?

 

Link to comment
Share on other sites

1 hour ago, alt3rn1ty said:

There a bug report on Skyrim LE Nexus which I cant reproduce in Skyrim SE ..

I dont think we are going to get a bashbugdump.log for that one though :

 

Trying to do a bashed patch...

Anyway - fallout3/fnv branch: https://github.com/wrye-bash/wrye-bash/archive/feature-sharlikran-valda-fallout.zip

As I said I am looking into this now cause I have to start looking at the records code to fix the formVersion thing for SSE - and because I would then have to reapply everything, well high time we merged this. ALPHA, you've been warned

Link to comment
Share on other sites

12 hours ago, Utumno said:

Trying to do a bashed patch...

Anyway - fallout3/fnv branch: https://github.com/wrye-bash/wrye-bash/archive/feature-sharlikran-valda-fallout.zip

As I said I am looking into this now cause I have to start looking at the records code to fix the formVersion thing for SSE - and because I would then have to reapply everything, well high time we merged this. ALPHA, you've been warned

Reference the guy on Nexus : Forget that issue - Sharlikran has recognised the problem to be probably from a mod author trying to use the same plugin for both Skyrim LE and SE, the VOLI record type is only present in SE, so trying to use that plugin for LE is going to cause issues like this. So not Wrye Bash error, just inexperienced mod author getting things wrong somewhere trying to save time supporting both games, or user trying the wrong plugin for this game.

------------------

Sounds like time to make the most recent Installer my Last Known Good installer :P

I can install FO3 again if needed, I have the GOG version which I uninstalled again a while ago, so at least can test the Installer for that game. But I wont be getting FONV again.

Is there really demand for those two games to be supported with another version of Wrye Flash?.

And is there potential for this merge to affect all the work done so far on getting another beta out for currently supported games?.

 

Edit : Also heads up, IIRC Snip was used a lot during the FO3 era (not sure about NV but it wouldn't surprise me people in their rush for fame and getting the first mods out would have used similar methods), so expect a fair amount of troubleshooting issues to be plugin corruption related. Thats the main reason I am not interested in older Fallouts now, which is a shame because FO3 was quite fun despite all its bugs.

Link to comment
Share on other sites

18 hours ago, Utumno said:

Trying to do a bashed patch...

Anyway - fallout3/fnv branch: https://github.com/wrye-bash/wrye-bash/archive/feature-sharlikran-valda-fallout.zip

 

Second set of eyes on a5c6709, PyCharm isn't perfect, nothing jumped out at me

Skyrim SE CC CK changed two records, suggest using updated code. As previously mentioned MreLens is not mergable when I previously though it was because I didn't notice the duplicate signatures Bethesda put in the record.

Added support for JIP 51.60 to Fallout NV

Link to comment
Share on other sites

OK I have just been looking into the form version issue.

Never experienced it personally, but thats due to me being :

1. Not so adventurous with mods I know have been ported by some clueless pretender to the author seat biting off more than they can chew

2. I check everything has been converted with best known practices and keep to a minimal load order using trusted authors work

 

The effects of this issue are quite bad from what I have read. And yet we have a Bashed Patch that once it has been rebuilt, is coming up with the wrong form version aswell adding to the issues?. I believe this topic is due to this problem.

So shouldn't we be more up front about this, considering its likely to take a while before it is resolved in Wrye Bash, a small note on Skyrim SE nexus (and Fallout 4 aswell ?? or is it just SSE) along the lines of :

 

"Advisory Note - All users of Skyrim SE Wrye Bash, are advised not to use the Bashed Patch until further notice (De-select it and do not rebuild it). There is an issue whereby plugins with a form version in the plugin header of 43 is Old Skyrim form version, and if not ported properly to Skyrim SE using the newer CK will not be converted to form version 44, which it should be. Wrye Bash is producing a Bashed Patch after rebuilding, with incorrect form versioning (which it has never had to cope with before this games changes to plugin headers came along) .. Which along with improperly converted mods, we believe will in the long term cause corruption to start occurring in your ongoing game, which may well reject your saves at some point.

Aswell as ceasing to use the Bashed Patch until Skyrim SE Wrye Bash has been programmed to take care of this emerging issue - Take a look at all of your mods plugins with SSEEdit 3.2.1, expand the header, and look for form version 44. If its 43 instead the mod needs converting properly to Skyrim SE and the mod author should be notified the plugin is not fit for use in SSE.

We regret that a new game start would be also well advised, but could not have anticipated this problem."

 

@Utumno, @Arthmoor, @zilav, @WrinklyNinja, @Sharlikran - Do you think the above is an appropriate course of action currently ?. Or have I blown this a bit out of proportion. As far as I have seen, it seems to me that the bashed patch is potentially contributing to a lot of peoples problems currently. I realise we should also be advising that everyone affected should also start a new game entirely, to ensure they get rid of baked in save problems this may have also caused. So its a bit of a bad situation for many .. Though nobody can be blamed for what we are just realising about bethesdas changes. Maybe the advisory note could be worded a little better .. Advice would be welcome. Just a like of the post would be understood if nothing else.

Link to comment
Share on other sites

I don't think you've blown this out of proportion at all and IMO we need to do an update on Nexus with a version that's current that either disables the patch function entirely or fixes the form version issue. The longer we let this go, the more people are going to get bit by it because they won't use dev versions. If ever there was a blocker, this bug is it.

It's only needed on SSE btw. Fallout 4 has only ever had one form version and there's been no evidence that patches built for that game are causing problems.

Link to comment
Share on other sites

3 hours ago, alt3rn1ty said:

clueless pretender to the author seat biting off more than they can chew

*thumps chest proudly*  LOL  At least I've only ever released one of my mods, a very very minor, low impact patch.

This is probably a stupid question, but here goes anyway. I assume if it were as simple as WB recognizing a plugin using Form Version 43, then refusing to build a patch, perhaps with an error stating why, that it would already have been considered/implemented? Guessing there's something preventing that from happening? *braces for Arthmoor's scathing retort* j/k :)

Link to comment
Share on other sites

lol, scathing retort? No, I'd actually be in favor of seeing such an error be thrown for anything in SSE not set to form 44 because it's a serious problem.

Link to comment
Share on other sites

I agree with @Arthmoor that you're not blowing this out of proportion but I think we need more information before we make any move. Don't worry though, I'll help get the information.

So with regard to the issue, correct me if I'm wrong, but if there are no v43 records anywhere in any plugin in the load order (I'm not counting the weirdness in the Skyrim masters) then there is no issue with the resulting Bashed Patch, correct?

If that's the case then the issue is really with lazy mod authors putting out poorly or not-at-all ported plugins and we need to point out that if you build a bashed patch with one of those poorly ported plugins, you're going to have a bad time.

Or:

1 minute ago, RavenMind said:

*thumps chest proudly*  LOL  At least I've only ever released one of my mods, a very very minor, low impact patch.

This is probably a stupid question, but here goes anyway. I assume if it were as simple as WB recognizing a plugin with Form Version 43 in the header, then refusing to build a patch, perhaps with an error stating why, that it would already have been considered/implemented? Guessing there's something preventing that from happening? *braces for Arthmoor's scathing retort* j/k :)

That's actually a great idea and I'm all for it. Yes Bash needs the patcher updated, but lazy mod authors is the absolute root cause of the issue.

Link to comment
Share on other sites

Plus at least that way people will know that it's a problem with the mod they're using, not with Wrye Bash. In the mean-time, I think alt3rn1ty's proposal to update the description on Nexus is a very good one. That way people aren't unwittingly corrupting their saves & then blaming WB for their having to start over.

Edit: Oops, looks like Beermotor & I posted at the same time. :P

Link to comment
Share on other sites

Bash's problem is compounded by the fact that it's saving the TES4 record in form 0. For whatever reason, only SSE has a problem with this. Even if you were to have all other forms correct, that one header alone will lead to issues as the game will interpret data in the wrong formats and result in subtle errors.

The problem is inherent to how Bash was originally written. Since Oblivion doesn't have form versions, no code support for them was ever provided for. We were lucky that Skyrim LE caused no issued because of it, and are lucky it doesn't cause problems in Fallout 4 either. This is uniquely an SSE issue for whatever reason that is. Yes, lazy authors are a problem and getting properly ported mods is a long term solution, but that's going to take YEARS to get people to quit doing that just like it did with TESVSnip and all the problems that thing caused.

Link to comment
Share on other sites

33 minutes ago, Arthmoor said:

Bash's problem is compounded by the fact that it's saving the TES4 record in form 0. For whatever reason, only SSE has a problem with this. Even if you were to have all other forms correct, that one header alone will lead to issues as the game will interpret data in the wrong formats and result in subtle errors.

The problem is inherent to how Bash was originally written. Since Oblivion doesn't have form versions, no code support for them was ever provided for. We were lucky that Skyrim LE caused no issued because of it, and are lucky it doesn't cause problems in Fallout 4 either. This is uniquely an SSE issue for whatever reason that is. Yes, lazy authors are a problem and getting properly ported mods is a long term solution, but that's going to take YEARS to get people to quit doing that just like it did with TESVSnip and all the problems that thing caused.

From a technical standpoint, how does the game engine treat the Bashed Patch plugin differently than other plugins if all the included records are v44? I apologize if you explained it to me before but I think I focused more on the individual record versions in the plugin and not on the issue of the v0 TES4 header version. :P

What if whenever Bash creates the Bashed Patch,0.esp for SSE, it just makes sure the resulting patch plugin has a TES4 header that is v44? IIRC code may already exist in Bash within the "Create new project" feature to create a form v44 plugin from scratch.

So regarding outreach Ok how about this verbiage for the outreach:

Quote

 

Due to the way the Bashed Patcher functions, any unconverted or improperly ported Skyrim plugins could potentially have their old form version 43 records copied into the Bashed Patch.  For those who are not aware, there is a growing corpus of evidence showing a correlation between unexpected behavior and/or corruption and improperly ported Skyrim (2011) plugins when used in Skyrim Special Edition.

It is not the responsibility of the Bashed Patcher to do on-the-fly conversions of unconverted mods. If you choose to play with invalid plugins, you assume all risk incurred as a result of this decision. Please be aware that the Wrye Bash team cannot and will not support the use of SSE Bashed Patches created with Skyrim LE plugins.

 

 

 

How does that sound?

Link to comment
Share on other sites

It isn't enough to just set the TES4 header either. That, and all records within the patch, MUST be the correct version. This is not something that can be shortcutted, because it's this very shortcutting that people are doing now that's causing all these problems with so-called false corruption. What always gets me is that there are people out there who will refuse to accept that this happens and has been directly observed unless said observers are then able to back it up with runtime debugger logs as proof. That's an impossibly high standard to meet, and if it had been expected with Snip, Skyrim modding would have been dead long before SSE became a thing.

As for the verbiage of the warning, I don't think anyone could ever have reasonably expected Bash to fix the issue, so I'm not sure we need to specify that we aren't responsible for doing so. Much the same way we don't expect xEdit to solve what it can't solve. There are things only the CK can do, and people simply need to accept this. So I'd simply mention that there is sufficient evidence to confirm that improperly ported mods will cause problems and that mod authors need to be responsible for fixing the issue the correct way. Bash should then abort and refuse to build the patch because IMO it would be bad for us to continue past such a warning and contribute to the very problem we seek to solve.

  • Like 2
Link to comment
Share on other sites

I appreciate that Beermotor is trying to test it and look at it from a technical perspective. Which I think is the only way to look at it.  Make a Hypothesis. When the game crashes for no explained reason, and all you have to do is disable the Bash Patch and the crash stops, that it is caused by the fact there is no Form Version.  However, once you establish that as your hypothesis you can't go back on it.  For example, if you have the proper Form Version and the crash still occurs then it's not the Form Version.  If 5 people have the issue and it fixes it for 2 or 3 of the 5 then the Form Version wasn't the solution.

As Zilav mentioned, it's never been added to even the merge patch and it should only matter when the extra data unique to Form Version 44 is used.  If the extra data isn't used it shouldn't matter.  I don't need run time logs, but you did mention that there were three people that were experienced modders. I offered to test it with them and I was turned down. If the Form Version is added and doesn't address the issue then we will have to start over trying to figure it out. I'd rather try to figure it out now as opposed to later.

Do you actually have a crash when you have the Bash Patch active Arthmoor? For oldrim, gromulos said when he loads two mods, Cerwiden and Skyrim Redone that 307 will cause a crash. I went through it with him and could not reproduce the error. Which is why I would like to have people that actually have this issue contact me. Because if I can't reproduce it with the mods they suggest, then it's not happening because of Bash it's happening for other reasons.

Link to comment
Share on other sites

@Beermotor What the Form Version does, as far as we know because we don't have Bethesda's source code, is it tells Skyrim what format the record is. For example Form Version 43 might have 16 bytes in a subrecord and Form Version 44 might have 24.  In version 43 there is a FormID after the first 8 bytes in the record, and for Form Version 44 there is a FormID after the first 16 Bytes. So as you can see, Arthmoor's concern is truly valid. It's nothing to be overlooked. All I feel is that the thread that Alt3rn1ty linked has people with mods that simply have other issues but some people are convinced the only cause has to be the Form Version because they have tried everything they can think of.  Now they have not tried all my tricks, but that's beside the point.  I am not saying that I don't want to add the Form Version, but I will say people are going to be very disappointed if after there is a Form Version that nothing really changes. It may change from some people and not others which will mean testing the hypothesis was inconclusive.

Link to comment
Share on other sites

Good info Arthmoor & Sharlikran! So, correct me if I'm wrong, we do know that building a bashed patch with an improperly converted mod will, or likely will, cause unexpected behavior and possible corruption. Right? If this is the case then I think the most pressing concern would be to alert people on Nexus and perhaps the other download locations. We don't want people blaming Bash for problems caused by poor modding practices. Then, or concurrently, you coding gurus can have at the technical aspect of the Form versions and the patcher.

As for the warning, I agree with Arthmoor about reasonable expectations and not including the "we aren't responsible" part. That kind of language always seems to come across as defensive, (when there's no need to be,) and when I see it I tend to think "Uh oh, there's something there they don't want to take responsibility for."  I would also remove mention of Form versions. People don't need to know exactly what the problem is, just that they shouldn't Bash Patch LE mods or bad conversions. Those that do want to know exactly what the problem is can easily find their way here. This is what I would say:

Quote

Warning: There is mounting evidence showing that improperly ported/converted Skyrim LE (2011) plugins may lead to unexpected behavior and/or corruption. Bashed Patches should not be built with these mods. It is the mod author's responsibility to ensure that their mods are correctly converted for use with SSE. Please check with the author if you have any doubts.  If you choose to play with invalid plugins, you assume all risk incurred as a result of this decision. Please be aware that the Wrye Bash team cannot and will not support the use of SSE Bashed Patches created with Skyrim LE plugins.

I think this helps push the responsibility of properly porting mods squarely back on the shoulders of the authors that release them, and encourages users to inquire about their mods from the correct people. Plus Beermotor's wording eschews the WB team of responsibility for resulting corruption without making it look like you've got something to hide, and his last sentence brings to light that LE mods shouldn't be incorporated into the Bashed Patch. Something I think some (or many) people may not be aware of. Hopefully it's short enough people might actually read it. :)

Link to comment
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
×
×
  • Create New...