Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

5 hours ago, Supierce said:

I hate to contradict Zilav, but Leo's question was how to do it in xEdit.

No, I actually wanted to find out how the mod checker in WB can show version number of a mod after I rebuilt the bashed patch.  And alt's post was correct, I tested it earlier today and now the version number for my mod showed the correct version.

Of course I needed to add the correct version for my mod first by editing the file header in WB, which worked as intended.

Link to comment
Share on other sites

11 hours ago, Arthmoor said:

@zilav Maybe a good idea to disable editing of that field since there's never a reason to allow it?

Experienced modders need to edit it sometimes, especially in FO3/FNV plugins. I used it too once, apparently you need to know what you are doing :)

  • Like 1
  • Haha 1
Link to comment
Share on other sites

I find that logic a bit shaky, but this isn't a topic for Wrye Bash discussion. Tampering with that version header is a bad idea. Let the CK handle it.

Link to comment
Share on other sites

What does it mean when building a patch for Oblivion and the error window fills up with nothing but "PGRDS" over and over again? Using CBash if that matters at all.

Link to comment
Share on other sites

Can anyone help me fix this error when building the bashed patch:

Vigilant.esp: SPGD.DATA: Expected size == 48, but got: 96
Error loading 'SPGD' record and/or subrecord: 022C603C
  eid = u'zzzCHRainStormParticles'
  subrecord = 'DATA'
  subrecord size = 96
  file pos = 1843568
Error in Vigilant.esp

Link to comment
Share on other sites

1 hour ago, godescalcus said:

Can anyone help me fix this error when building the bashed patch:

Vigilant.esp: SPGD.DATA: Expected size == 48, but got: 96
Error loading 'SPGD' record and/or subrecord: 022C603C
  eid = u'zzzCHRainStormParticles'
  subrecord = 'DATA'
  subrecord size = 96
  file pos = 1843568
Error in Vigilant.esp

Bethesda fixed saving of SPGD in CK only in October 2017 update, before that it was saving broken bloated data. Looks like this mod has been saved by older CK which screwed SPGD, so the author must fix it using the latest one.

Link to comment
Share on other sites

10 hours ago, zilav said:

Bethesda fixed saving of SPGD in CK only in October 2017 update, before that it was saving broken bloated data. Looks like this mod has been saved by older CK which screwed SPGD, so the author must fix it using the latest one.

Thanks! I suppose from your answer that we're not going to fix it by simply re-saving in the CK. It's strange that in xEdit everything seems normal and the form version for the record is 44, only the warning message about unused data at the bottom of the window:

https://i.gyazo.com/f589c4cece8ce8ad56cec56ce24eebdb.png

Another issue I'm having is Wrye Bash merging Better Quest Objectives into the bashed patch, all files including patches and the main esp. Then for some strange reason it flags Better Quest Objectives.esp (the main esp) as master and, while it deactivates it because it's merged, and looks green and everything seems in conformity, the game doesn't load the bashed patch. Loot also produced and error message for the bashed patch saying that its master (BQO) should be active in the load order, but is deactivated. Yet, the plugin shows in green as if merged into the bashed patch. Right after rebuilding the patch you actually get the plugin to be inactive (merged) and the bashed patch active, without complaining of missing master. That's when, running loot, I got the error message. Activating Better Quest Objectives.esp, loot no longer sends out an error message and if I, then, deactivate it again, it will cause the bashed patch to be deactivated as well, as expected.

This happens with Skyrim SE and didn't happen in the LE. It's pretty inconsistent because if you merge a master and all its dependencies there shouldn't be a dependency inherited by the bashed patch... Or if you keep the dependency, the master file shouldn't be merged or deactivated.

Link to comment
Share on other sites

Conflict resolution: I'm trying to resolve audio conflicts in my SSE build and noticed that all of Audio Overhaul's patches make it into the bashed patch. If I have an overall Conflict Resolution plugin that includes audio edits, merging, picking and choosing what to carry, that should override some or all of the mentioned patches, that plugin (loading last but before the bashed patch) gets overridden by the bashed patch.

When building the bashed patch, does WB only include edits from the files merged into it (and leveled lists) or does it take into account possible overrides that the plugins it merged might have later in the load order?

Link to comment
Share on other sites

3 minutes ago, lmstearn said:

Something like a heuristical Bash? Not at present, but it's certainly an idea for a fork. Alternatively you could try Mator's Smash.

How compatible is mator's smash with wrye bash (used as mod manager)? Is is just a question of making the smashed patch before the bashed patch? I feel it might mess things up, as even if I deactivate (ghost) the plugins merged into the smashed patch, when I build the bashed patch it will still read the ghosted archives and merge them in, unless I tell it not to, or deactivate the esp's in the installers tab or, worse, move them below the bashed patch in the mods tab. Sounds like a lot of work when bashed patch plus some manual CR will achieve the same as the smashed patch...

Link to comment
Share on other sites

AFAIK, no dramas with Bashed Patch- just a different flavour on things- there's a comprehensive thread here, you know.

But as the Red Hulk graphic implies, use at own risk. :)

Link to comment
Share on other sites

6 minutes ago, lmstearn said:

AFAIK, no dramas with Bashed Patch- just a different flavour on things- there's a comprehensive thread here, you know.

But as the Red Hulk graphic implies, use at own risk. :)

Read it, hated some of the attitude... Foresaw a lot of reading and tinkering and headaches for negligible results. Then I read some more. Phrases like this in a post immediately drive me away: " Mator Smash completely obviates Bashed and Merged patches to the point where it and basic record checking in xEdit are the only two things you ever need to make fully functional patches. I'm assuming you're using Mod Organiser for this, but if you're not, you should be."

I figured out I haven't needed mator smash hitherto, probably won't need it hereafter. But thank you for confirming that bit of extra conflict resolution I'll need when using the bashed patch. :thumbsup:

Link to comment
Share on other sites

Mator Smash is unreliable at best. It would be better to just wait on Wrye Bash to get full tag based patching up to full power for Skyrim. That functionality is godlike for Oblivion modding and would solve the problem you're trying to address quite nicely without blindly smashing every little conflict known to man into the patch file.

Link to comment
Share on other sites

Will take a poke at it in a bit. Do we know when that support will get folded into the main Wrye Bash code?

Link to comment
Share on other sites

ASAP - with a huge disclaimer that this will remain a beta as I have no time to really support it (nor the games etc). But since this is working code and at least people can use BAIN and the rest of Bash functions and since maintaining this branch separately has costed me huge time and effort I intend to merge in for next and final hopefully 307 beta - what also remains for the beta is the form version fix (it's not in this FO3 branch, so don't use this branch with SSE). The form version "fix" for now is that I carry the record form version from the mod along in the patch - let me know if this enough in issue https://github.com/wrye-bash/wrye-bash/issues/342

Link to comment
Share on other sites

What about progress with Mash?

I've seen a lot of fuss around Morroblivion of late, as someone who didn't play MW "back in the day" and only started a few months ago for modding fun, is Morroblivion already a platform worth going for? That is, besides having better Wrye Bash support.

Does it have a comparable mod base? I started modding Morrowind on the grounds that Morroblivion would take away the fun of achieving the best results on the original version, plus all the mods available for the original MW wouldn't necessarily be usable in Morroblivion.

Link to comment
Share on other sites

Tried a patch build for NV on the following load order:

Active Mod Files:

00  FalloutNV.esm
01  DeadMoney.esm
02  HonestHearts.esm
03  OldWorldBlues.esm
04  LonesomeRoad.esm
05  GunRunnersArsenal.esm
06  ClassicPack.esm
07  MercenaryPack.esm
08  CaravanPack.esm
09  TribalPack.esm
0A  D.E.I.M.O.S..esm  [Version 1.05]
0B  NVWillow.esp
0C  YUP - Base Game + All DLC.esm
0D  YUP - NPC Fixes (Base Game + All DLC).esp
0E  Vurt's WFO.esp
0F  VertibirdCrashSites.esp
10  AFKEmServRailStationHome.esp
11  Bashed Patch, 0.esp

Got this traceback, which is consistently repeatable:

Traceback (most recent call last):
  File "bash\balt.py", line 436, in <lambda>
    if onButClick: self.Bind(wx.EVT_BUTTON, lambda __event: onButClick())
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\basher\patcher_dialog.py", line 209, in PatchExecute
    self._save_pbash(patchFile, patch_name)
  File "bash\basher\patcher_dialog.py", line 298, in _save_pbash
    patchFile.safeSave()
  File "bash\parsers.py", line 4054, in safeSave
    self.save(filePath.temp)
  File "bash\parsers.py", line 4072, in save
    self.tes4.dump(out)
  File "bash\brec.py", line 1638, in dump
    out.write(self.header.pack())
  File "bash\brec.py", line 193, in pack
    return struct_pack(*pack_args)
struct.error: pack expected 6 items for packing (got 5)

Installing these mods went through without issue so as far as I can see the installers tab works fine, and so does moving things around on the Mods tab as well.

Link to comment
Share on other sites

Whenever I try to resize icons to 32x32 in settings/status bar, from the installers window, Wrye Bash crashes. If I do the same from the mods window, it's ok. This has happened with every version of wrye bash I've used up to the latest... Not a breaking bug, but a crashing one nonetheless.

Link to comment
Share on other sites

Isn't there already an open issue somewhere for that? In any case, it's not limited to the installers tab. The mods tab will do it too. Only Wrye Bash isn't what's crashing, it's Python itself, so there's no debug info available to look at.

Windows 10 if that somehow matters. Running as admin.

What's interesting is that if you step through from 16 -> 24 -> 32 everything comes out just fine. You can then change to any of the settings at will, on any tab, without it crashing Python.

Link to comment
Share on other sites

On 2018-02-10 at 11:30 PM, godescalcus said:

What about progress with Mash?

I think this (his post below my post) is your answer.  If you also wonder when WMSA gets another update is something I cannot answer and only Sharlikran knows when so you need to ask him, but don't expect a positive response from him.

On 2018-02-10 at 11:30 PM, godescalcus said:

I've seen a lot of fuss around Morroblivion of late, as someone who didn't play MW "back in the day" and only started a few months ago for modding fun, is Morroblivion already a platform worth going for? That is, besides having better Wrye Bash support.

Does it have a comparable mod base? I started modding Morrowind on the grounds that Morroblivion would take away the fun of achieving the best results on the original version, plus all the mods available for the original MW wouldn't necessarily be usable in Morroblivion.

You are not the only one who have notice the same thing about the Morrowind modding community.

Also, with the current situation about the postponed server migration at GHF, I dunno where or how solid the Morrowind modding community really is today as it once were on the old BSF forum.

In case you need to get the original links of GHF or the linked forum thread buttons on GHF-DL to work properly then you need to do this.

Link to comment
Share on other sites

Today I tested this for SkyUI and since I not only use SkyUI I also needed to uninstall another mod that requires SKSE64, just to see if it's a glitch in SkyUI and it was.

Anyway, after I test it I launched WB and put back those SKSE64 mods then I sorted my loadorder with LOOT, but after I checked the gamesaves I notice that both SkyUI and the mod wasn't in blue.

So after I moved the another mod below SkyUI both mods was now in blue.  Which makes me wonder if it's feasible to let WB to backup the current loadorder by automatically saving the current loadorder before uninstalling a mod?

What I mean is about when I right click on the row bar I get this.

5a8173304ddca_ModsTabinWB307.thumb.jpg.786e4b875e24636fe2d0b2b7e6d90956.jpg

Link to comment
Share on other sites

25 minutes ago, lmstearn said:

Like as in testing a mod?

Yes.  It's also useful when one need to reproduce a mod issue in-game.

Link to comment
Share on other sites

On 2/11/2018 at 2:54 AM, Arthmoor said:

Tried a patch build for NV on the following load order:

Active Mod Files:

  Reveal hidden contents

 



00  FalloutNV.esm
01  DeadMoney.esm
02  HonestHearts.esm
03  OldWorldBlues.esm
04  LonesomeRoad.esm
05  GunRunnersArsenal.esm
06  ClassicPack.esm
07  MercenaryPack.esm
08  CaravanPack.esm
09  TribalPack.esm
0A  D.E.I.M.O.S..esm  [Version 1.05]
0B  NVWillow.esp
0C  YUP - Base Game + All DLC.esm
0D  YUP - NPC Fixes (Base Game + All DLC).esp
0E  Vurt's WFO.esp
0F  VertibirdCrashSites.esp
10  AFKEmServRailStationHome.esp
11  Bashed Patch, 0.esp

 

 

Got this traceback, which is consistently repeatable:

 


Traceback (most recent call last):
  File "bash\balt.py", line 436, in <lambda>
    if onButClick: self.Bind(wx.EVT_BUTTON, lambda __event: onButClick())
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\basher\patcher_dialog.py", line 209, in PatchExecute
    self._save_pbash(patchFile, patch_name)
  File "bash\basher\patcher_dialog.py", line 298, in _save_pbash
    patchFile.safeSave()
  File "bash\parsers.py", line 4054, in safeSave
    self.save(filePath.temp)
  File "bash\parsers.py", line 4072, in save
    self.tes4.dump(out)
  File "bash\brec.py", line 1638, in dump
    out.write(self.header.pack())
  File "bash\brec.py", line 193, in pack
    return struct_pack(*pack_args)
struct.error: pack expected 6 items for packing (got 5)

 

Installing these mods went through without issue so as far as I can see the installers tab works fine, and so does moving things around on the Mods tab as well.

Thanks fixed redownload please !

On 2/11/2018 at 2:59 AM, godescalcus said:

Whenever I try to resize icons to 32x32 in settings/status bar, from the installers window, Wrye Bash crashes. If I do the same from the mods window, it's ok. This has happened with every version of wrye bash I've used up to the latest... Not a breaking bug, but a crashing one nonetheless.

 

On 2/11/2018 at 3:27 AM, Arthmoor said:

Isn't there already an open issue somewhere for that? In any case, it's not limited to the installers tab. The mods tab will do it too. Only Wrye Bash isn't what's crashing, it's Python itself, so there's no debug info available to look at.

Windows 10 if that somehow matters. Running as admin.

What's interesting is that if you step through from 16 -> 24 -> 32 everything comes out just fine. You can then change to any of the settings at will, on any tab, without it crashing Python.

This issue is probably (but not certainly) a bug in wx version used that was 10 years before windows 8/10 - never ever had it on 7

https://github.com/wrye-bash/wrye-bash/issues/334

Issue is closed for now but feel free to add info - the more the merrier we may end up fixing it somehow from python side

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