Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

Spoiler

 


ccBGSFO4001-PipBoy(Black).esl
ccBGSFO4002-PipBoy(Blue).esl
ccBGSFO4003-PipBoy(Camo01).esl
ccBGSFO4004-PipBoy(Camo02).esl
ccBGSFO4006-PipBoy(Chrome).esl
ccBGSFO4012-PipBoy(Red).esl
ccBGSFO4014-PipBoy(White).esl
ccBGSFO4016-Prey.esl
ccBGSFO4017-Mauler.esl
ccBGSFO4018-GaussRiflePrototype.esl
ccBGSFO4019-ChineseStealthArmor.esl
ccBGSFO4020-PowerArmorSkin(Black).esl
ccBGSFO4022-PowerArmorSkin(Camo01).esl
ccBGSFO4023-PowerArmorSkin(Camo02).esl
ccBGSFO4025-PowerArmorSkin(Chrome).esl
ccBGSFO4038-HorseArmor.esl
ccBGSFO4041-DoomMarineArmor.esl
ccBGSFO4042-BFG.esl
ccBGSFO4043-DoomChainsaw.esl
ccBGSFO4044-HellfirePowerArmor.esl
ccFSVFO4001-ModularMilitaryBackpack.esl
ccFSVFO4002-MidCenturyModern.esl
ccFRSFO4001-HandmadeShotgun.esl
ccEEJFO4001-DecorationPack.esl

Above is Fallout4.ccc


ccBGSSSE002-ExoticArrows.esl
ccBGSSSE003-Zombies.esl
ccBGSSSE004-RuinsEdge.esl
ccBGSSSE006-StendarsHammer.esl
ccBGSSSE007-Chrysamere.esl
ccBGSSSE010-PetDwarvenArmoredMudcrab.esl
ccBGSSSE014-SpellPack01.esl
ccBGSSSE019-StaffofSheogorath.esl
ccBGSSSE021-LordsMail.esl
ccMTYSSE001-KnightsoftheNine.esl
ccQDRSSE001-SurvivalMode.esl
ccTWBSSE001-PuzzleDungeon.esm
ccEEJSSE001-Hstead.esl

Above is Skyrim.ccc

 

the .ccc files are in the same folder as the games EXE, not the Data folder.

Link to comment
Share on other sites

@Supierce @Beermotor - BAIN displays conflicts only for files that differ - those files are binary identical. Since this has come up time and again maybe time for a readme patch ? @Beermotor your last edits (on scandir) somehow changed the whole file - although this may be a good idea, for now let's keep diffs at a minimum (I manually edited out all but the scandir edits)

Link to comment
Share on other sites

Catching up here : I think the Fallout4.ccc and Skyrim.ccc files are to stop the problems for SKSE, being a list for all CC plugins (and in one case an esm as noted in Sharlikrans spoilered list), so as not to need hard coding into the games exe every time there is a new updated list of cc plugins .. and thus not cause SKSE to also need an update. HLP and Wrinkly mention it here

Seems Bethesda listened on that one.

 

P.S Yep I'm back from the much delayed Caribbean Honeymoon at Curacao, I have a new skin colour, called "boiled like a lobster", after being marinated in Kilo Kai Spiced Rum, I think I would probably make a tasty meal right now :). Very enjoyable, saw turtles in the sea and hummingbirds outside our lodge (Kontiki Beach Resort), ate Iguana (unfortunately it did not come on a stick), Red Snapper, Barracuda and Goat .. Plus assorted other things we have never eaten before, and no stomach problems at all throughout which was a bonus for a tropical holiday.

Link to comment
Share on other sites

3 hours ago, Utumno said:

@Supierce @Beermotor - BAIN displays conflicts only for files that differ - those files are binary identical. Since this has come up time and again maybe time for a readme patch ? @Beermotor your last edits (on scandir) somehow changed the whole file - although this may be a good idea, for now let's keep diffs at a minimum (I manually edited out all but the scandir edits)

 

Yes I learned my lesson about using Kompozer to edit HTML. I didn't even realize it tried to reformat the tables until I saw the diff on Github. :wallbash:

Link to comment
Share on other sites

Playing around with the save games I noticed that when I change the header for one, if there is no accompanying skse save game that there is an "[Errno 2] No such file or directory" error. Could you please add a check for that?  Only change it if one exists.  There are times when you may not have an accompanying cosave.
 

Link to comment
Share on other sites

Using Fallout 4 1.10.26 and WB 307.201711041935 standalone. Windows 10 professional. I doubt my load order will help but I've included it.

Currently I get the following whenever I try to rebuild a bashed patch:

Spoiler

settings_links.pyo  459 Execute: Debug Printing: On
Traceback (most recent call last):
  File "bash\balt.pyo", line 436, in <lambda>
  File "bash\balt.pyo", line 1605, in _conversation_wrapper
  File "bash\basher\patcher_dialog.pyo", line 203, in PatchExecute
  File "bash\patcher\patch_files.pyo", line 227, in scanLoadMods
  File "bash\parsers.pyo", line 3981, in load
  File "bash\bosh\__init__.pyo", line 873, in getStringsPaths
  File "bash\bosh\bsa_files.pyo", line 477, in extract_assets
  File "bash\bosh\bsa_files.pyo", line 517, in _load_bsa
  File "bash\bosh\bsa_files.pyo", line 262, in load_record
AttributeError: 'B2aFileRecordTexture' object has no attribute 'offset'

I searched and found nothing for the B2aFileRecordTexture but presumably this has to do with the "modname - textures.ba2" type of files. I enabled debug but that didn't tell me anything and changing iKeepLog in the ini did nothing for me and it is otherwise the default. The released 307 beta Wrye Bash works for creating the bashed patch but obviously has other obvious issues. It did work for the bashed patch though.

How can I tell which file it was on when the error occurred? 

PatchConfig.txt

bashtags.txt

loadorder.txt

Link to comment
Share on other sites

On 11/10/2017 at 8:10 AM, Sharlikran said:

Playing around with the save games I noticed that when I change the header for one, if there is no accompanying skse save game that there is an "[Errno 2] No such file or directory" error. Could you please add a check for that?  Only change it if one exists.  There are times when you may not have an accompanying cosave.
 

Where is that error ?

15 hours ago, CrankyCat said:

Using Fallout 4 1.10.26 and WB 307.201711041935 standalone. Windows 10 professional. I doubt my load order will help but I've included it.

Currently I get the following whenever I try to rebuild a bashed patch:

  Hide contents

settings_links.pyo  459 Execute: Debug Printing: On
Traceback (most recent call last):
  File "bash\balt.pyo", line 436, in <lambda>
  File "bash\balt.pyo", line 1605, in _conversation_wrapper
  File "bash\basher\patcher_dialog.pyo", line 203, in PatchExecute
  File "bash\patcher\patch_files.pyo", line 227, in scanLoadMods
  File "bash\parsers.pyo", line 3981, in load
  File "bash\bosh\__init__.pyo", line 873, in getStringsPaths
  File "bash\bosh\bsa_files.pyo", line 477, in extract_assets
  File "bash\bosh\bsa_files.pyo", line 517, in _load_bsa
  File "bash\bosh\bsa_files.pyo", line 262, in load_record
AttributeError: 'B2aFileRecordTexture' object has no attribute 'offset'

I searched and found nothing for the B2aFileRecordTexture but presumably this has to do with the "modname - textures.ba2" type of files. I enabled debug but that didn't tell me anything and changing iKeepLog in the ini did nothing for me and it is otherwise the default. The released 307 beta Wrye Bash works for creating the bashed patch but obviously has other obvious issues. It did work for the bashed patch though.

How can I tell which file it was on when the error occurred? 

PatchConfig.txt

bashtags.txt

loadorder.txt

I need a reproducer for that - that is minimal active mods and patch options that cause it

Link to comment
Share on other sites

Patch options for Fallout 4 would be just Levelled lists

I cant reproduce, so it really needs CrankyCat to narrow down which mods are causing it to throw that error

@CrankyCat The method to narrow it down is to untick half your mods .. Try Rebuild Bashed Patch

If that does not reproduce the error, switch to the other half activated .. Rinse and repeat until you find the mod.

If you launch "Wrye Bash - Fallout4 (Debug Log)" from your Start Menu ..

6837-0-1510310754.png

 

.. Make the error happen again, then close Wrye Bash, then look in steam / steamapps / common / Fallout4 / Mopy /

You should find a newly created BashBugDump.log file

Its a text file and if you paste the content here it will help Utumno a lot more, especially if you can narrow down the culprit mod.

Link to comment
Share on other sites

@Utumno

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\basher\__init__.py", line 1994, in DoSave
    saveInfo.write_masters()
  File "bash\bosh\__init__.py", line 1125, in write_masters
    cosave = self.get_cosave()
  File "bash\bosh\__init__.py", line 1151, in get_cosave
    return self._cosave_type(cosave_path) # type: cosaves.ACoSaveFile
  File "bash\bosh\cosaves.py", line 352, in __init__
    with open(u'%s' % cosave_path, 'rb') as ins:
IOError: [Errno 2] No such file or directory: u'C:\\Users\\[username]\\Documents\\My Games\\Skyrim Special Edition\\Saves\\Save 5 - Marleny  Helgen Keep  00.16.55.skse'

 

Link to comment
Share on other sites

@CrankyCat

I read your response again so what I said below might not apply since another version worked.  List the file names of all the files in your Data folder.  After you have that, please edit out things like the folders.  Just include the ESP/ESM/INI/BA2 file names. Attach it to a text file like you did.  Something like "dir > listoffiles.txt" in the data folder and then edit the file.

Spoiler

 

If the issue is a BA2 IMO you have one of 2 issues. 1) Someone made a BA2 and the format is unrecognized by Wrye Flash. Make sure all BA2 files are made with Archive2.exe.  If not then you can't expect them to be 100% compatible with Wrye Flash. The game may use them but they may not work with Wrye Flash and it's simple and easy to use Archive2.exe.  2) Please read my response here and the file name conventions they use.  Wrye Flash looks for predetermined file name conventions and even the game won't recognize some of the naming conventions "people want" so make sure you are using the most simple naming convention for Wrye Flash and Fallout 4.

I'm not saying you are being demanding or anything, just consider what I am saying.  The tool author can't be expected to account for every possible way something can be done. It is easier to stick with certain standards.

 

Then if I don't see anything jump out at me you will have to do as Utumno requested.

Link to comment
Share on other sites

On 10/29/2017 at 11:00 PM, Utumno said:

Latest utumno-wip attempts to fix the form version bug - please make bashed patches and test nothing broke.

 

@Utumno Just used the latest Nightly Build Standalone and did a few rebuilds of the bashed patch - Skyrim SE

(I dont think anyone has posted any results for this game so far since you asked for it to be tested)

Opened each rebuild with xEdit

In all cases tried so far :

All Header Versions = 44

All individual records versions throughout the plugin = 44

I think thats behaving as currently advised to be the best practice for this game

(only just caught up on all that has been said on the subject since I went away).

 

 

BN7as6W.png

 

Even on a brand spanking newly created bashed patch ..

KZxTu7Y.png

 

Wrye Bash starting
Using Wrye Bash Version 307.201711041935 (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 Skyrim Special Edition found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo  156 __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.10.1

Link to comment
Share on other sites

3 hours ago, alt3rn1ty said:

 

@CrankyCat The method to narrow it down is to untick half your mods .. Try Rebuild Bashed Patch

[snipped]

And the culprit is... Wild Plants Farming. Everything else works when enabled except this. I'll manually extract and rebuild the Farm - Main.ba2 with Archive2 and see if that fixes it for me.

Thanks everyone! Hopefully this is simple to reproduce and either work around, get the author to fix it, or add a warning.

Link to comment
Share on other sites

1 hour ago, CrankyCat said:

And the culprit is... Wild Plants Farming. Everything else works when enabled except this. I'll manually extract and rebuild the Farm - Main.ba2 with Archive2 and see if that fixes it for me.

Thanks everyone! Hopefully this is simple to reproduce and either work around, get the author to fix it, or add a warning.

Ok glad you found it .. I can reproduce

From the main file install :

From Farm_dlcall_ufo4p : Farm.esp

From Farm_ba2_textures : Farm - Textures.ba2

From Farm_ba2_main_dlcall : Farm - Main.ba2

Build the Bashed Patch .. It will fail at some point and produce the following BashBugDump.log

Wrye Bash starting
Using Wrye Bash Version 307.201711041935 (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 Fallout4 found in parent directory of Mopy:  D:\Steam\steamapps\common\Fallout 4
bush.pyo  156 __setGame:  Using Fallout4 game: D:\Steam\steamapps\common\Fallout 4
testing UAC
mods_metadata.pyo  227 __init__: Using LOOT API version: 0.10.1
Traceback (most recent call last):
  File "bash\balt.pyo", line 436, in <lambda>
  File "bash\balt.pyo", line 1605, in _conversation_wrapper
  File "bash\basher\patcher_dialog.pyo", line 203, in PatchExecute
  File "bash\patcher\patch_files.pyo", line 227, in scanLoadMods
  File "bash\parsers.pyo", line 3981, in load
  File "bash\bosh\__init__.pyo", line 873, in getStringsPaths
  File "bash\bosh\bsa_files.pyo", line 477, in extract_assets
  File "bash\bosh\bsa_files.pyo", line 517, in _load_bsa
  File "bash\bosh\bsa_files.pyo", line 262, in load_record
AttributeError: 'B2aFileRecordTexture' object has no attribute 'offset'

 

In FO4Edit the plugin has 5 ITMs, no UDRs = No biggy but the author could clean it for release first before uploading it.

Ran a check for errors and did not find any.

The BA2s' contain a few custom wim95 (authors name) folders, for example

Textures \ wim95 \ plants \

Meshes \ wim95 \ plants \

I cant see those ordinarily causing Wrye Bash any problems though .. Anyway over to the expert @Utumno :)

Edit : There might be something quirky going on with string files for this mod

  • Thanks 2
Link to comment
Share on other sites

For Oblivion, should the Nvidia Fog Fix still be there ? For me, it makes the game much more unstable. It also adds 519 changes to my bashed patch.

I don't think its ever done me any good, even on older GPU's. Alot of people are probably using it and thinking it will help with crashes.

Link to comment
Share on other sites

1 hour ago, alt3rn1ty said:

Edit : There might be something quirky going on with string files for this mod

Definitely. The only real difference I see in the original "Farm - Main.ba2" file vs one I repacked is that the file paths in the original have back slashes instead of forward slashes. Maybe it's a Russian Windows thing. :-) Oddly enough I get a missing strings warning with Wrye Bash on the repacked ba2 file even though they are the same size and the only difference is that the original had forward slashes.

Edit: Another difference is that in the Strings folder the En versions were first in the original ba2 archive but on my system they aren't that way alphabetically in the folder. I reproduced this when recreating the archive to put the English strings files first but WB still shows the "Missing strings localization files" warning like the mod did on the 307 beta 1 release. Farms actually does have several translation files included with the mod. 

i.e. original has: Strings\Farm_En.DLSTRINGS
repacked has: Strings/Farm_En.DLSTRINGS

Edit2: If I use archive2 to repack anything I have with strings localizations then i get the "Missing strings localization files" error when loading in WB. The only binary difference is the backslashes in the original are now forward slashes. Does the string localization validation expect backslashes? This seems to be a separate issue from the bash rebuild though. I don't see anything done differently than the "Ground" mod which doesn't cause the error. 

I'll leave the rest to the experts and just unselect farms when rebuilding my bashed patch for now :-)

Link to comment
Share on other sites

Thanks everybody - @CrankyCat did rebuilding fix the error ?

Well what happens is we can't load Texture ba2 - now apparently this is a general ba2 but for some reason it has mixed assets ? Will have to investigate but be my guests as I have limited time and digging into the half documented ba2 format it's not something I would look forward to (I had quite my share when I wrote the bsa/ba2 reading code). extending Bash to support texture ba2 is in an important TODO however so ...

 

1 hour ago, CrankyCat said:

Does the string localization validation expect backslashes?

Yes - so that's quite another issue with bsa/ba2 which must be looked at

 

2 hours ago, Sladen2019 said:

For Oblivion, should the Nvidia Fog Fix still be there ?


Hmm - this has come up again - what you say everybody ?

Link to comment
Share on other sites

35 minutes ago, Utumno said:

Thanks everybody - @CrankyCat did rebuilding fix the error ?

While the rebuilt "Farm - Main.ba2" does get the missing strings error now it no longer fails when building the bashed patch. This is odd since the Ground mod by the same author (wim95) works the same way and has no issues.

Edit: I tried building in archive2 with a source file but that didn't change the slash direction.

Link to comment
Share on other sites

1 hour ago, Utumno said:

Hmm - this has come up again - what you say everybody ?

I have always had NVidia cards, and have always followed the old Wrye Bash team recommendation of using it because it could do no harm.

Even now out of habit I have it set for an NVidia Geforce 970. All it does is change some cells fog setting from pure black to 0.0001

 

Nvidia Fog Fix

•  Cells with fog tweaked to 0.0001: 269

•  Oblivion.esm: 262

•  DLCBattlehornCastle.esp: 1

•  DLCThievesDen.esp: 2

•  DLCHorseArmor.esp: 1

•  Knights.esp: 3

 

So I cant see it causing performance / stability issues. If you dont use it you may walk into one of these cells and find the viewing angle which causes the screen to black out which is annoying when it happens ( I recall experiencing it once before finding out the Bashed Patch had it solved - Its like when you go into a guided tour of a cave, and they want you to experience what it was like for the first people working down here with the lights off, that dark ).

Oblivion is notorious for causing stability issues the more mods you use. Getting anywhere near the maximum slots with that game and not causing stability issues requires voodoo. This tweak .. I really cant see it causing such problems, but untick it if it does.

Link to comment
Share on other sites

5 hours ago, Sladen2019 said:

I've never had any screens go all black, but then again I've always used UOP and Weather All Natural which could have their own Fog Fixes.

I agree with @alt3rn1ty, AFAIK Oblivion can even still be played by some tragics as Oldblivion where on ancient cards it remains an issue.

But the question remains as to whether these days it should be turned on by default. Probably not.

Link to comment
Share on other sites

6 hours ago, alt3rn1ty said:

.. have always followed the old Wrye Bash team recommendation of using it because it could do no harm.

Even now out of habit I have it set..

Same here since I first experienced the bug and spent several hours researching WTH was going on. (Didn't use WB back then.)

6 hours ago, alt3rn1ty said:

This tweak .. I really cant see it causing such problems, but untick it if it does.

Agreed.

5 hours ago, lmstearn said:

But the question remains as to whether these days it should be turned on by default. Probably not.

IMO, most users don't go through all the Bashed Patch options/tweaks anyway, so erring on the side of caution may be a good idea, so long as there's no/minimal performance impact. People who do go through all the BP options can easily deselect if they don't want it. If this is no longer an issue on modern Nvidia cards, perhaps it can be stated in the description of the tweak that it's only necessary to use on "x" year & older cards. Or even change the tweak name to Nvidia Pre-(x-year) Fog Fix.

Link to comment
Share on other sites

I need an informed expert opinion on what those backslashes in the bsas should be - is it game specific ?

I also heard about .ccc files that have the ex hardcoded cc plufins for FO4/SSE - need also exact info on these and a couple files for these games so I can parse them

Link to comment
Share on other sites

Ref the Fallout4.ccc and Skyrim.ccc files Sharlikran already spoilered the content, note one of them also includes an .esm confusingly

 

Here's the files in their original format https://www.dropbox.com/s/pcrheq29bfvj6w8/new-ccc-files.7z?dl=0

In case you skip Sharlikrans words again .. These files do not live in Data, they are in the same folder level as the games .exe

Link to comment
Share on other sites

2 hours ago, Utumno said:

I need an informed expert opinion on what those backslashes in the bsas should be - is it game specific ?

I asked Wim95 and he was familiar with the backslash issue. Apparently if you pack files from within the fallout 4 data structure, in place, then you get backslashes. I was unpacking elsewhere and repacking them which apparently results in forward slashes. It makes sense that devs do it by packing the files they use to develop with. That doesn't explain why only Wild Plants Farming (farm - main.ba2) caused an issue while other mods didn't though. I'll repack the "right way" and see if I get the expected results.

Edit: I rebuilt the right way and there was no error from missing string localizations and the bashed patch had no issues. To do this I did the following:

  1. Installed the original Wild Plants Farming mod normally.
  2. Unpacked the original mod 7z for Wild Plants Farming to a working folder.
  3. Unpacked the main ba2 (only)
  4. Created a 7z for the unpacked mod without the textures. 
  5. Installed the temporary mod
  6. Generated a build_farm.txt to use as a source file (attached) from an edited list of the unpacked files and placed it in the data folder. I have full paths in it since past tests caused errors when I didn't but perhaps relative paths would work from \data\.
  7. Used archive2.exe to create a new archive from the source file. I used compression of "none" like the original mod.
  8. Replaced the "farm - main.ba2" with the new one.
  9. Uninstalled my temp mod.
  10. WB had no issues with either strings or the bashed patch.

I did a binary compare on the original vs the new ba2 and they are different possibly because wim95 originally had upper case folder names for existing folders and I have lower case. The size was the same and both had backslashes in the file paths though.

farm_build.txt

Edited by CrankyCat
additional testing info, fix typo
Link to comment
Share on other sites

6 hours ago, RavenMind said:

IMO, most users don't go through all the Bashed Patch options/tweaks anyway, so erring on the side of caution may be a good idea, so long as there's no/minimal performance impact. People who do go through all the BP options can easily deselect if they don't want it. If this is no longer an issue on modern Nvidia cards, perhaps it can be stated in the description of the tweak that it's only necessary to use on "x" year & older cards. Or even change the tweak name to Nvidia Pre-(x-year) Fog Fix.

I agree with RavenMind. I doubt tt's needed with modern cards, but I also doubt that enabling it has any negative effect.

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