Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

18 hours ago, Utumno said:

Patching the code to examine form versions of each record seems not trivial at all - in fact I have no clue as of now how to go about it. But probably since the BP TES4 record has correct form version the rest will be ok

No, don't expect parity; the Form Version can differ between records. The TES4 header record is really just another record.

I wrote a rough Python script for how to read the Form Version for records in groups: find_form_version.py. It does not iterate through records or groups, so you'll need to implement that yourself however you want to do that in Wrye Bash.

edit: Updated the script to iterate through groups and records, except CELL and WRLD, which I skipped simply because they require a bit more work than I intended to put into this. CELL and WRLD groups contain multiple levels of groups, so the script currently fails to parse those records. On the plus side, the script now logs the Form ID for each record, in addition to the Signature and Form Version, so you can open up a plugin in a hex editor and see the data structures yourself.

edit 2: Wrote a third version that exports record metadata from all ESM/ESP files in a directory to JSON. It also uses struct.unpack and skips DIAL records, too.

https://gist.github.com/fireundubh/af0994cb65ffb26d0810ee213a3b46fb

  • Game: Tested on only SSE plugins
  • Version: Tested on Python 3.6.4
  • Libraries: io, json, os, pathlib, struct, collections.defaultdict

Helpful Resources:

Link to comment
Share on other sites

Thanks @fireundubh - glad to see you around

What I meant is that I have to dig deeeeeeeeeeeply into 20 levels stack frames to see where the record is parsed and raise an error from there if I encounter an old form version also performing ugly if checks to see if this is a master file where this is normal. I am fully aware form versions can differ from record to record - however, in #342 we ended up fixing a very nasty bug by setting all form versions to current one - this turned out to be an even nastier bug so I reverted setting the form version of the TES4 record only - or other records that have no formVersion (it's zero) and that may backfiure as well. As seen in the comments here https://github.com/wrye-bash/wrye-bash/blob/a0ae08c42fdf47688870387a6f6296de0551bfc2/Mopy/bash/brec.py#L108-L126 I believe that cell/world blocks (or whatever it';s called) have this 0 actually

Link to comment
Share on other sites

Also to add to what @Utumno is saying, the BP crash issue was traced back to plugins created with TESSnip or TES5edit that were created by copying records out of the masters into new plugins.

While doing a root cause analysis on the crash, according to the hex editor diffs I reviewed it looks like Skyrim.esm doesn't have the proper/correct/final attributes for some records set (in the cases so far they have been MODT attributes, but I don't have a very large sample size to test with yet)  as they are in Update.esm, so if a MA just copies these records out of skyrim.esm into a new plugin, they don't have the update.esm changes (thanks @zilav for the lead). Normally if a plugin is created in the CK and uses one of those records, update.esm is added as a master and the plugin gets the update.esm version instead of the skyrim.esm version.

If the record-copy plugin is resaved in the CK, it looks like the CK updates those records to the Update.esm version.  The MODT records in the sample plugins I've tested with are filled instead of null.  See this diff to see what I'm talking about.  diff_Size Does Matter_Size Does Matter fixed_Dec-30-2017 09-50.zip

Yes the form versions are uniform after resaving, but I think that's a red herring.

So how does this affect the Bashed Patch?  I think when the patcher merges these skyrim.esm records into the BP, suddenly they're reversing the change made by Update.esm because under normal conditions they wouldn't "win" but now there they are front-and-center. This makes the game try to correct for that (inject the record back in maybe?), which causes the crash or ILS on startup.

Am I a loony noob or am I on to something? What do you guys think?

 

Link to comment
Share on other sites

@Beermotor I think you should hijack #403 and post all that info there as you suggested - even if my monky fix proves enough this is valuable info we need a central place in the github to discuss/collect the info so it is not lost to forum noise. tag it regression and bug please (change title ofc and edit the op)

Thanks!

And have some holiday everybody :P

Link to comment
Share on other sites

5 minutes ago, Utumno said:

@Beermotor I think you should hijack #403 and post all that info there as you suggested - even if my monky fix proves enough this is valuable info we need a central place in the github to discuss/collect the info so it is not lost to forum noise. tag it regression and bug please (change title ofc and edit the op)

And have some holiday everybody :P

Roger on 403. I'll make it happen. 

Happy New Year to you as well! :)

 

Link to comment
Share on other sites

30 minutes ago, Utumno said:

And have some holiday everybody :P

Just about to go for a few festive beverages with Mrs Alt and Daughters :D

Happy New Year to all.

 

But for after the hols note another report on Oblivion nexus, the error report is cut short but possibly the same issue anonymousone had ?

I gave anonymousone a nudge that you had a fix in Utumno WIP, but he's an Installer Standalone user ( same as the most recent bug report by Awedbyaqmen ) so they will probably be shy of doing the full python install to test the fix.

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

Ref Beermotors conclusions = Waaay above my heeaad, especially after a few Nollaig's, (only 800 1l Growler bottles produced per year, the spruce are harvested in the spring for the following year) .. two of them just dissapeared by a real ale troll :)

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

Hope someone can confirm some of the findings over the last couple of pages, and bring the latest head scratchers to a close.

Oldrim users are getting a bit chompy just now, so I put a bit more in the sticky posts to advise not merging / using problem mods for now which cause game freeze on load. <shrugs>

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

Standing by for an upload of beta 3 should it happen. But not tonight :P

Link to comment
Share on other sites

2 hours ago, alt3rn1ty said:

Just about to go for a few festive beverages with Mrs Alt and Daughters :D

Happy New Year to all.

And a Happy New Year to you too, sir!  Thank you for all the help and mentoring this past year! :beer:

2 hours ago, alt3rn1ty said:

Hope someone can confirm some of the findings over the last couple of pages, and bring the latest head scratchers to a close.

I actually found some things while I was updating issue #403 on Github. This will be of interest to @Utumno as well.

Short version: Once i had everything on one page it started making more sense re: the MODT records. I also found this information @Lojack posted regarding handling those records with CBash that may be useful.

Hopefully we can help the Oblivion folks. I'll hop over and take a look shortly.

Link to comment
Share on other sites

Quote
On 12/29/2017 at 12:51 PM, Beermotor said:

My hypothesis for what is happening is that the Bashed Patcher is writing all of the records included in the BP as the appropriate form version for the target game, but since the original records from these "problem" plugins were not in that form version to begin with, the records written in the patch are not actually really the form version claimed in the record. This causes the record to be corrupt perhaps.

Hmmm - could we check this out ?

This is probably not happening. All records are written in the proper format. I won't be around to keep repeating this because I am permanently retiring from all computer related activity so pardon me if I sound rude. I'll read things on occasion of course.

The records will write with or without the form version exactly as they should according to xEdit source code. They have always written in the current format from xEdit since the beginning when I started porting them. For skyrim if the record is truncated it is written in the proper format and default values are assigned.  The only thing that ever changes is when I make a minor mistake and have to correct it. With that said the patcher does sometimes not carry over certain values as in the records that Arthmoor has added to the issue tracker.

Please refer to my previous post and do as I suggested by having a Bashed Patch with or without masters that causes the issue but set any ESP masters to have the ESM flag and then load it in the CK.  What if anything changes?  I don't really see the point in looking at the WB source code until you see what the CK would do to the Bash Patch. Do this with both a patch form 307 beta1 and beta2.  Because the CK will add those Form Versions.  The question is what does it do to the BP and will the BP cause the issue after loading it in the CK.

Also if loading a plugin with injected records crashes the CK then resolve them with the xEdit script that comes with xEdt to change the FormID prefix. I forget what it's called though.  It will set all the formIDs from say 01xxxxxx to 05xxxxxx. Just make sure you only use it on new records and make sure all related plugins for the mod are loaded so you know the injected records are not used by the mod in some way. The CK can't handle too many of them without crashing because it will try to clamp the FormID to the plugin if it's a new record and not an override of a record from a master.

Link to comment
Share on other sites

9 hours ago, Utumno said:

I believe that cell/world blocks (or whatever it';s called) have this 0 actually

Hmm, I ran some quick tests in xEdit on SSE and FO4 ESMs. From what I've tested, CELL and WRLD have nonzero Form Versions.
 

Link to comment
Share on other sites

1 hour ago, zilav said:

I think I found the reason, explained what to do here https://github.com/wrye-bash/wrye-bash/issues/403#issuecomment-354641012

Just had a read of that and I am confused - What has form 44 got to do with the problem the Bashed Patch is causing for OLD Skyrim (Not SSE), which is what started this investigation a few pages ago .. Or is there also an issue for SSE and nobody still knows how to solve the oldrim problem .. Or is form 44 also being used in Oldrim by Wrye Bash and I missed that point somewhere ???

Link to comment
Share on other sites

12 minutes ago, alt3rn1ty said:

Just had a read of that and I am confused - What has form 44 got to do with the problem the Bashed Patch is causing for OLD Skyrim (Not SSE), which is what started this investigation a few pages ago .. Or is there also an issue for SSE and nobody still knows how to solve the oldrim problem .. Or is form 44 also being used in Oldrim by Wrye Bash and I missed that point somewhere ???

Hashes have different binary format: old ones when form version < 40 and new ones when >=40. So there is no difference if form version in old records < 40 is updated to Oldrim's 43 or SSE's 44, it is bad in both cases. That's why I propose that WB should delete hashes in records having form version < 40 when copying them to the bashed patch and updating their versions to the newer ones.

  • Thanks 2
Link to comment
Share on other sites

4 hours ago, zilav said:

Hashes have different binary format: old ones when form version < 40 and new ones when >=40. So there is no difference if form version in old records < 40 is updated to Oldrim's 43 or SSE's 44, it is bad in both cases. That's why I propose that WB should delete hashes in records having form version < 40 when copying them to the bashed patch and updating their versions to the newer ones.

That makes perfect sense and explains what I was seeing in the hex editor and xEdit. I learned quite a bit about reverse engineering from this. Thank you :)

 

 

 

 

Link to comment
Share on other sites

If that's the case then there are records in Oblivion or FO3/FNV Wrye Flash that have routines to read in certain subrecords but not write them out.  You should add that to any record that you don't want it to write the hashes for.

Link to comment
Share on other sites

Utumno, with today's WIP, clicking on the installers tab produces the following traceback (in both Oblivion and Fallout 4):



Traceback (most recent call last):
  File "bash\basher\__init__.py", line 3496, in OnShowPage
    self.currentPage.ShowPanel()
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\basher\__init__.py", line 2841, in ShowPanel
    scan_data_dir)
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\bosh\bain.py", line 1474, in _projects_walk_cache_wrapper
    return func(self, *args, **kwargs)
  File "bash\basher\__init__.py", line 2871, in _refresh_installers_if_needed
    refresh_info)
  File "bash\bosh\bain.py", line 1548, in irefresh
    changed = not self.loaded and self.__load(progress)
  File "bash\bosh\bain.py", line 1570, in __load
    self.dictFile.load()
  File "bash\bolt.py", line 1515, in load
    self.data.update(cPickle.load(ins))
  File "bash\bosh\bain.py", line 319, in __setstate__
    dest_scr = self.refreshDataSizeCrc()
  File "bash\bosh\bain.py", line 605, in refreshDataSizeCrc
    bethFiles = bush.game.bethDataFiles
AttributeError: type object 'OblivionGameInfo' has no attribute 'bethDataFiles'

Link to comment
Share on other sites

Thanks @Supierce - you're my bleeding edge tester of choice :D

Fixed

307.201801021732

Happy new year with a happy new nightly:

- work by @Daidalos to integrate loot api 3.0.0 - please update

- monkey patch for BP freezing the game - please test

- internal refactoring of game handling (that may break, as in post by Sup above)

- rest of fixes referred to some posts above

Link to comment
Share on other sites

:) Happy New Year

Wrye Bash starting
Using Wrye Bash Version 307.201801021732 (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: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Skyrim\\Mopy\\Wrye Bash.exe', '--debug']
Using scandir 1.5
bash.pyo  288 _main: Searching for game to manage:
bush.pyo   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   82 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   82 _supportedGames:  Skyrim: D:\Steam\steamapps\common\Skyrim
bush.pyo   82 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   82 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to Skyrim found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim
bush.pyo  161 __setGame:  Using Skyrim game: D:\Steam\steamapps\common\Skyrim
testing UAC
mods_metadata.pyo  227 __init__: Using LOOT API version: 0.12.0
mods_metadata.pyo  285 refreshBashTags: An error occurred while parsing file C:\Users\m0l3y\AppData\Local\LOOT\Skyrim\masterlist.yaml:
Traceback (most recent call last):
  File "bash\bosh\mods_metadata.pyo", line 279, in refreshBashTags
AttributeError: 'loot_api.DatabaseInterface' object has no attribute 'eval_lists'

mods_metadata.pyo  300 refreshBashTags: An error occurred while parsing taglist.yaml:
Traceback (most recent call last):
  File "bash\bosh\mods_metadata.pyo", line 297, in refreshBashTags
AttributeError: 'loot_api.DatabaseInterface' object has no attribute 'eval_lists'

games.pyo  702 _fetch_active_plugins: Removed Skyrim.esm from C:\Users\m0l3y\AppData\Local\Skyrim\plugins.txt

 

Good news the "Size Does Matter" plugin (at least) now merges into the Bashed Patch without freezing the game

LOOT I have installed is the latest on Nexus 0.12.1

 

Updated the sticky post on Skyrim Nexus to invite any with Game Freezing issues to try out the Nightly build as a pre-beta3

Also uploaded a new image for all sites, which is a screenshot of the Windows 10 Settings / Apps Uninstallers - Win 10 recently I believe has a new behaviour, any freshly installed Uninstallers in the Start Menu, now get moved. Just after installing the Nightly build, having uninstalled Beta2, I went again straight to the Start Menu to launch in debug mode and saw the newly installed Uninstaller Icon .. vanish, I then went to Settings / Apps and found it had popped up there .. I can only conclude Win 10 now actively watches for any kind of uninstaller in the Start Menu and Squirrels them away to Settings / Apps automatically.

Link to comment
Share on other sites

58 minutes ago, alt3rn1ty said:

:) Happy New Year

Wrye Bash starting
Using Wrye Bash Version 307.201801021732 (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: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Skyrim\\Mopy\\Wrye Bash.exe', '--debug']
Using scandir 1.5
bash.pyo  288 _main: Searching for game to manage:
bush.pyo   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   82 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   82 _supportedGames:  Skyrim: D:\Steam\steamapps\common\Skyrim
bush.pyo   82 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   82 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to Skyrim found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim
bush.pyo  161 __setGame:  Using Skyrim game: D:\Steam\steamapps\common\Skyrim
testing UAC
mods_metadata.pyo  227 __init__: Using LOOT API version: 0.12.0
mods_metadata.pyo  285 refreshBashTags: An error occurred while parsing file C:\Users\m0l3y\AppData\Local\LOOT\Skyrim\masterlist.yaml:
Traceback (most recent call last):
  File "bash\bosh\mods_metadata.pyo", line 279, in refreshBashTags
AttributeError: 'loot_api.DatabaseInterface' object has no attribute 'eval_lists'

mods_metadata.pyo  300 refreshBashTags: An error occurred while parsing taglist.yaml:
Traceback (most recent call last):
  File "bash\bosh\mods_metadata.pyo", line 297, in refreshBashTags
AttributeError: 'loot_api.DatabaseInterface' object has no attribute 'eval_lists'

games.pyo  702 _fetch_active_plugins: Removed Skyrim.esm from C:\Users\m0l3y\AppData\Local\Skyrim\plugins.txt

Missed that one in my tests. Will fix asap.

Link to comment
Share on other sites

Just went through a few things for Fallout 4 and Oblivion in debug mode too, the BashBugDump.logs for those games are just giving "Testing UAC" as content for those logs after Wrye Bash is exited. Skyrim and Skyrim SE are the only ones giving a full log

 

Here's the Skyrim SE one which Idont think you need now but just posting it to show this and oldrim are giving similar results, but FO4  and Oblivion are giving nothing

Wrye Bash starting
Using Wrye Bash Version 307.201801021732 (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: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Skyrim Special Edition\\Mopy\\Wrye Bash.exe', '--debug']
Using scandir 1.5
bash.pyo  288 _main: Searching for game to manage:
bush.pyo   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   82 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   82 _supportedGames:  Skyrim: D:\Steam\steamapps\common\Skyrim
bush.pyo   82 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   82 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to Skyrim Special Edition found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo  161 __setGame:  Using Skyrim Special Edition game: D:\Steam\steamapps\common\Skyrim Special Edition
testing UAC
mods_metadata.pyo  227 __init__: Using LOOT API version: 0.12.0
mods_metadata.pyo  285 refreshBashTags: An error occurred while parsing files C:\Users\m0l3y\AppData\Local\LOOT\Skyrim Special Edition\masterlist.yaml, C:\Users\m0l3y\AppData\Local\LOOT\Skyrim Special Edition\userlist.yaml:
Traceback (most recent call last):
  File "bash\bosh\mods_metadata.pyo", line 279, in refreshBashTags
AttributeError: 'loot_api.DatabaseInterface' object has no attribute 'eval_lists'

mods_metadata.pyo  300 refreshBashTags: An error occurred while parsing taglist.yaml:
Traceback (most recent call last):
  File "bash\bosh\mods_metadata.pyo", line 297, in refreshBashTags
AttributeError: 'loot_api.DatabaseInterface' object has no attribute 'eval_lists'

Link to comment
Share on other sites

Thank you for your tests @alt3rn1ty. I don't know why you can not see the error in FO4, I can replicate it there too, but that probably just means that for some reason refreshBashTags() was not called for you for FO4.

I have committed a fix for this, but as far as I can tell the error itself should be benign, as in not impact functionality.

Link to comment
Share on other sites

@Utumno Thanks, it looks like everyone has been super-busy. 

I got a bit of testing done last night and aside from the known things it looks OK.

I actually spent more time reading the activity on the repo where @Ganda started reworking game handling and the fantastic discussion about profile handling. 

The game handling code actually made me feel more confident about turning on GMSTTweaks for FO4. I still have a few hundred more gmstEids to verify before it's ready for public consumption. 

I'm doing this manually in the GECK verifying them one by one. If anyone knows an easier way to do it (like with xEdit or FO4Dump) please let me know. 

Link to comment
Share on other sites

It would seem there is an issue with the Beta 2 and DynDOLOD's plugin. I started the conversation ( http://forum.step-project.com/topic/13029-dyndolod-236-skyrim-se-beta-with-dynamic-lod/?p=213102 ) with sheson and it would seem the BP is looking for a higher byte size on a STAT record than Skyrim.esm has natively?

Edit: Looks like this is partly being discussed here: https://github.com/wrye-bash/wrye-bash/issues/403#issuecomment-354641012

Link to comment
Share on other sites

Quote

It would seem there is an issue with the Beta 2 and DynDOLOD's plugin. I started the conversation ( http://forum.step-project.com/topic/13029-dyndolod-236-skyrim-se-beta-with-dynamic-lod/?p=213102 ) with sheson and it would seem the BP is looking for a higher byte size on a STAT record than Skyrim.esm has natively?

Edit: Looks like this is partly being discussed here: https://github.com/wrye-bash/wrye-bash/issues/403#issuecomment-354641012

Not correct. I mentioned in a previous post that the current error to inform users about plugins not saved with the Skyrim SE CK should only show for the plugins and not the official files.  It currently shows for both authors plugins and the DLC when comparing records. That behaviour needs to change. I have no idea if my previous post was ignored or there simply wasn't time to implement a change for that.

Like I said I am retiring permanently and will only be commenting from time to time. I see there are some current concerns and I am trying to save you all days and weeks of banging your head on a wall trying to figure something out by telling you what is going on. So please, for my sanity and if you wish for me to continue to comment to save you trouble, please read my posts.

There are no bugs or issues with the records for Wrye Bash for Skyrim or Skyrim SE that I am aware of. From what I am reading so far what you are experiencing is expected. All, and I do mean all plugins used with Skyrim SE other then the DLC must have been saved with the CK. It is expected or an error will appear. Until the current warning is updated to not error on the official DLC then ignore warnings about the size of the records from the DLC. Only pay attention to errors for user created files.

For more emphasis..

Ignore these types of messages

Traceback (most recent call last):
  File "bash\parsers.py", line 3961, in load
    self.tops[label].load(ins, unpack and (topClass != MobBase))
  File "bash\record_groups.py", line 69, in load
    ins.tell() + self.size - self.header.__class__.rec_header_size)
  File "bash\record_groups.py", line 171, in loadData
    record = recClass(header,ins,True)
  File "bash\brec.py", line 1682, in __init__
    self.__class__.melSet.initRecord(self,header,ins,unpack)
  File "bash\brec.py", line 1227, in initRecord
    MreRecord.__init__(record,header,ins,unpack)
  File "bash\brec.py", line 1477, in __init__
    if ins: self.load(ins,unpack)
  File "bash\brec.py", line 1540, in load
    self.loadData(ins,inPos+self.size)
  File "bash\brec.py", line 1691, in loadData
    self.__class__.melSet.loadData(self, ins, endPos)
  File "bash\brec.py", line 1256, in loadData
    loaders[Type].loadData(record, ins, Type, size, readId)
  File "bash\game\skyrimse\records.py", line 182, in loadData
    old_skyrim=True)
ModSizeError: Skyrim.esm: 
Wrye Bash SSE expects a newer format for STAT.DNAM than found.
Load and save Skyrim.esm with the Skyrim SE CK
STAT.DNAM: Expected size == 12, but got: 8

Only pay attention to errors like this:

Traceback (most recent call last):
  File "bash\parsers.py", line 3961, in load
    self.tops[label].load(ins, unpack and (topClass != MobBase))
  File "bash\record_groups.py", line 69, in load
    ins.tell() + self.size - self.header.__class__.rec_header_size)
  File "bash\record_groups.py", line 171, in loadData
    record = recClass(header,ins,True)
  File "bash\brec.py", line 1682, in __init__
    self.__class__.melSet.initRecord(self,header,ins,unpack)
  File "bash\brec.py", line 1227, in initRecord
    MreRecord.__init__(record,header,ins,unpack)
  File "bash\brec.py", line 1477, in __init__
    if ins: self.load(ins,unpack)
  File "bash\brec.py", line 1540, in load
    self.loadData(ins,inPos+self.size)
  File "bash\brec.py", line 1691, in loadData
    self.__class__.melSet.loadData(self, ins, endPos)
  File "bash\brec.py", line 1256, in loadData
    loaders[Type].loadData(record, ins, Type, size, readId)
  File "bash\game\skyrimse\records.py", line 182, in loadData
    old_skyrim=True)
ModSizeError: SomePlugin.esp: 
Wrye Bash SSE expects a newer format for STAT.DNAM than found.
Load and save Skyrim.esm with the Skyrim SE CK
STAT.DNAM: Expected size == 12, but got: 8

SomePlugin.esp is made up obviously so you could put [Insert Plugin Name Here] if you like instead.

Also PLEASE NOTE!!! If someone is an idiot and makes a Skryim SE plugin but releases it for old Skyrim then Wrye Bash will error. So make sure that authors are not doing something stupid like that.

  • Thanks 3
Link to comment
Share on other sites

15 hours ago, Sharlikran said:

Not correct. I mentioned in a previous post that the current error to inform users about plugins not saved with the Skyrim SE CK should only show for the plugins and not the official files.  It currently shows for both authors plugins and the DLC when comparing records. That behaviour needs to change. I have no idea if my previous post was ignored or there simply wasn't time to implement a change for that.

I apologize, I have not read the 48 pages of posts here, but I think I'm being misunderstood. The situation of only checking on plugins is still an issue.

The Skyrim.esm has records in it which are 8 bytes, not the 12 bytes from Skyrim SE. This causes an issue (as I think has been discussed in the bug report I linked to) with plugins that are created solely in xEdit. For instance, DynDOLOD.esp. The error I'm getting is from 000008A6 (FenceWoven01) so I will use that to sell my point.

During DynDOLOD generation, the program pulls the FenceWove01 record from Skyrim.esm and adds a specific flag to it for its purposes. The only conflicts when viewed in xEdit are between Skyrim.esm and DynDOLOD.esp. DynDOLOD.esp now houses an 8 byte record which is perfectly valid, however, WB is tossing out an error for it (not for Skyrim.esm). I say this is perfectly valid, because if you take out DynDOLOD.esp from the equation, then you would get the 8 byte record being fed into the game by Skyrim.esm, not DynDOLOD.esp. My question here is, "what's the difference?". Regardless if the record is being provided by Skyrim.esm or another plugin, the record is clearly in a valid format if it's being fed by Skyrim.esm into the game.

I know the feature is new and likely needs some refinement, but this situation isn't confined to DynDOLOD. I was simply using it as an example for my point. It would seem WB's new check is a bit too rigid because the situation I just gave shouldn't cause any issues in the game whatsoever, yet WB tosses out an error due to the record in the new plugin. Perhaps the issue WB is attempting to fix is only valid for a few record types/specific records and WB is being over zealous by just blanketing the entire issue with all records need to be the 12 byte record.

If this needs to be refined, I'm certainly willing to help out from the user-end, but can't be much help on the development side.

Link to comment
Share on other sites

2 hours ago, TechAngel85 said:

I apologize, I have not read the 48 pages of posts here, but I think I'm being misunderstood. The situation of only checking on plugins is still an issue.

The Skyrim.esm has records in it which are 8 bytes, not the 12 bytes from Skyrim SE. This causes an issue (as I think has been discussed in the bug report I linked to) with plugins that are created solely in xEdit. For instance, DynDOLOD.esp. The error I'm getting is from 000008A6 (FenceWoven01) so I will use that to sell my point.

During DynDOLOD generation, the program pulls the FenceWove01 record from Skyrim.esm and adds a specific flag to it for its purposes. The only conflicts when viewed in xEdit are between Skyrim.esm and DynDOLOD.esp. DynDOLOD.esp now houses an 8 byte record which is perfectly valid, however, WB is tossing out an error for it (not for Skyrim.esm). I say this is perfectly valid, because if you take out DynDOLOD.esp from the equation, then you would get the 8 byte record being fed into the game by Skyrim.esm, not DynDOLOD.esp. My question here is, "what's the difference?". Regardless if the record is being provided by Skyrim.esm or another plugin, the record is clearly in a valid format if it's being fed by Skyrim.esm into the game.

I know the feature is new and likely needs some refinement, but this situation isn't confined to DynDOLOD. I was simply using it as an example for my point. It would seem WB's new check is a bit too rigid because the situation I just gave shouldn't cause any issues in the game whatsoever, yet WB tosses out an error due to the record in the new plugin. Perhaps the issue WB is attempting to fix is only valid for a few records and WB is being over zealous by just blanketing the entire issue with all records need to be form 44 for plugins.

If this needs to be refined, I'm certainly willing to help out from the user-end, but can't be much help on the development side.

Thank you for you detailed post and yes, we are aware that the current handling of record form versions is not ideal as you have seen in issue #403. The current situation is a balance between warning SSE users about old plugins that need to be updated and not crashing Oldrim when merging certain plugins into the bashed patch.

We do aim for a more comprehensive fix regarding the Oldrim issues, but that requires rewriting some of the patching code to actually be aware of form versions (right now it basically ignores them and just copies whatever it sees) and this may take some time.

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