Wrye-bash: Bashed Patch: Game startup issues related to problematic plugins

Created on 31 Dec 2017  路  13Comments  路  Source: wrye-bash/wrye-bash

There have been numerous user reports of issues starting Skyrim and Skyrim Special Edition after updating to Wrye Bash 307 Beta 2. The typical issue experienced is the game will launch but will not progress past the logo on the startup screen. No menus are shown and the game becomes completely unresponsive.

After iterative interrogation to find the cause of the startup issues, several example plugins were identified to be associated with the startup failures.

These plugins were all created by different authors but have the following attributes in common:

  • All were created by copying records from Skyrim.esm into a new plugin.
  • None had been saved in the appropriate Creation Kit.
  • None had masters other than Skyrim.esm.
  • All contained MODL records with MODT texture file hashes.

The issue manifested when these plugins were found to be mergeable by Bash and subsequently merged into the Bashed Patch.

When these plugins were saved in the appropriate Creation Kit for the intended game and merged into the Bashed Patch, the game started as normal.

Additional findings below.

Forum reference posts:

C-regression A-records
Source
picture BeermotorWB

Most helpful comment

For future reference the list of subrecords which hold texture hashes.
For all records: MODT, MO2T, MO3T, MO4T, MO5T, DMDT
Unique to particular records: NAM2 in PROJ, NAM5 in BPTD

picture zilav on 2 Jan 2018
👍2

All 13 comments

Findings from RCA testing:

The main issue identified is that some records in Skyrim.esm are not in their final form and are missing some record attributes that are replaced or amended in Update.esm. It is also possible certain attributes are not set (or cleared) in a manner the game engine expects.

If when making a plugin a mod author copies these records out of Skyrim.esm into a new plugin, the records in the plugin are also missing the final versions of the records and are in effect overriding Update.esm.

Most records in Skyrim.esm do not fit this criteria and present no issues when used in the game despite them being different than Update.esm. Likewise most of plugins created using this method are not mergeable so their records do not normally appear in the Bashed Patch unless they "win" conflict resolution. This requires a combination of a specific subset of Skyrim.esm records and those records must be merged into the Bashed Patch before the issue will occur.

This can be mitigated by:

  • Resaving the plugins in the appropriate CK after plugin creation.
  • Educating mod authors to use the CK for creating plugins
BeermotorWB picture BeermotorWB on 31 Dec 2017
👍1

Changes made by the CK during saving of the identified plugins
Since the plugins in question were all modifications to either furniture, grass, or tree records, all had MODL records with MODT texture file hashes associated with them.

The information below (with difference files) will explain the specific issues corrected by re-saving the plugins in the appropriate Creation Kit for the target game.

Identified Plugins:

Size Does Matter _Skyrim LE_

Enhanced Vanilla Trees _Skyrim LE_

Insignificant Object Remover _Skyrim Special Edition_

BeermotorWB picture BeermotorWB on 31 Dec 2017

Took a closer look at texture hashes data and it definitely has a different format depending on form version. All records with form version less than 40 has old format, and the ones >=40 use a completely different new format. Considering that the first UInt32 value in new format is a counter value for subsequent structures, I can easily see why it locks up the game when it tries to read the old data as new after WB simply changed form version from <=39 to 44 in records that contain hashes data.

The problem is that plugins using old version (made by xEdit) is not really an issue, they are absolutely correct for the game and the reason why they do work fine standalone unless merged.

So what I propose - when WB updates a record form version in a bashed patch from <=39 to 44, it should simply remove all hashes subrecords since they are optional. There are a lot of vanilla records without hashes in the game master file, those hashes are just a minor optimization data for the game to preload textures before the model is loaded and avoid recalculation of hashes used for lookup in BSA/BA2 archives.

Also those records AMMO, MATO, STAT, WATR and WEAP need additional treatment since they are binary different when the form version is 44 and WB should properly serialize them.

zilav picture zilav on 1 Jan 2018
👍1

Thanks @zilav - @wrye-bash/devs - can anyone take this up ? We may be able to get away with just the change in my wip branch

Utumno picture Utumno on 2 Jan 2018

For future reference the list of subrecords which hold texture hashes.
For all records: MODT, MO2T, MO3T, MO4T, MO5T, DMDT
Unique to particular records: NAM2 in PROJ, NAM5 in BPTD

zilav picture zilav on 2 Jan 2018
👍2

More on records being copied with old format: https://afkmods.com/index.php?/topic/4966-wrye-bash-all-games/&do=findComment&comment=171210

Utumno picture Utumno on 5 Jan 2018

Is this being worked on? The new check on the Bash Patch is still causing a lot of headache for mod authors who provide patches created in xEdit. There's no need to run them through the CK as the check is telling us. Zilav's solution above is far better!

TechAngel85 picture TechAngel85 on 26 Jan 2018

If they have not been saved in the SSE CK then they really should get run through that at least once. xEdit is not meant to replace the use of the CK and has never been touted as such a thing. I don't think it serves the community to encourage the circumvention of the proper tools by trying to programmatically sidestep these issues.

Arthmoor picture Arthmoor on 26 Jan 2018

This really isn't the best place for ongoing discussion, but I guess I'm failing to see the major issue here.

I understand that the records are updated via the CK to the latest header and version numbers...with correct hashes, however, I am failing to see how this causes any issues with the game in regards to patches created solely in xEdit. This has been a common practice in the community for years; never running them through the CK. Even Zilav is saying they shouldn't be an issue unless they're merged and that's on the users to know the rules around merging, not the authors.

I agree that xEdit is not a replacement for the CK. I'm strictly talking about users creating conflict resolution patches between two or more mods. Are you saying users doing this should now always run said patches through the CK?

My issue with having to do this is that some plugins when ran through the CK will be killed unless corrected...again, with xEdit. By killing, I mean leaving all sorts of errors on records which the CK plugged in. Those records should have been filled with a forwarded record. This forces users to have to reopen xEdit to fix these errors. This is quite common with patches and is why it's a huge hassle to to run these through the CK. Most of the time you end up redoing 30-40% of the patch work because the CK stripped out the data (even when the masters and other mods are loaded alongside the patch).

I don't know if you guys are aware, but I've been hearing a lot of talk of users trying to figure out Mator Smash to simply dump the Bashed Patch due to all the headache it's causing them right now with this new check it's doing. Personally, I'd like to see a more elegant solution implemented for the Bashed Patch, which is why I inquired about it here.

TechAngel85 picture TechAngel85 on 27 Jan 2018

It was a common practice before SSE came along and threw a wrench into things. Prior to SSE it was not an issue for things to be not quite right, but the form 44 issue is real and it does cause problems when things are not done correctly. Yes, even in patches.

Conflict resolution patches for SSE must ensure that they are always resolving conflicts with properly ported form 44 records or they will be invalid. The game, for whatever reason it was done, will not self correct old records up to the new formats. That's why Bethesda explicitly said all mods need to be resaved in the new CK in order to work correctly. This means that the mods being resolved in this manner must also have been correctly ported or they too will be forwarding invalid records.

Mator Smash is not going to solve the problem since Mator is also not addressing the issue in the proper manner, and his past behavior indicates he never will because he refuses to accept that anything is wrong to begin with despite all of the evidence.

The check currently being done was implemented so that people won't wreck their saves on bad patches, mods, etc. You are in effect asking to have a required safety check removed for the sake of user convenience that will inevitably result in bogus bug reports being filed on mod author's pages in the future. This is literally no different than users burying their heads in the sand when confronted with bad ports of the parent mods.

Arthmoor picture Arthmoor on 27 Jan 2018
👍1

regression issues I think should be left out of the changelog as they simply refer to regressions in the dev branch

Utumno picture Utumno on 27 Sep 2019

Does the script already do that? Otherwise, we should add regression to the list of labels it skips.

Infernio picture Infernio on 27 Sep 2019

This script is outdated - needs new labels added for sure

Utumno picture Utumno on 27 Sep 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

SuperSandro2000 picture SuperSandro2000  路  7Comments
Utumno picture Utumno  路  15Comments
GandaG picture GandaG  路  15Comments
Utumno picture Utumno  路  12Comments
Utumno picture Utumno  路  13Comments