Wrye Bash - All Games

[Sladen2019]

I'm intending to use Wrye Bash as my only mod manager for Skyrim SSE. Now for XPMSE/FNIS/Bodyslide, is it ideal to install them manually ?

I think I have read somewhere that current dev builds can handle BodySlide. I have  307.201707160231 installed and running.

 

[alt3rn1ty]

@Sladen2019 I would wait for Utumno answering, but I think the next Nightly build ( second post, at the end of the post "307 WB wip standalone" link to dropbox ) will have the ability to install data files to Tools and CalienteTools folders ( depending upon the game )

See this post and the follow up posts. Utumno has yet to update the nightly build to include that ability though, so check in here and follow the conversation for a while.

But just to make this clear, note that it will not install what Wrye Bash considers illegal files (which includes .exe files), so even though the destination folders are now allowed to be installed into (and included in zip packages obviously), the full Bodyslide setup including exe files can not be done via Wrye Bash. Mods like CBBE with data files for the bodyslide setup though will be allowed.

[Leonardo]

Utumno

 

I've for, what is it 1-2 years, been using a SSD (Kingston 120 Gb) and lately I have started to reconsider other options of using a SSD.  One thing I can think of is to use it as a "Download" partition, meaning I'll download mods and other files to my SSD.

 

It makes it easier to maintain, plus it also gives me full control of the other partitions I use my HDD's for, one of them is 'C'.

 

I know WB is using the Windows\Temp folder, as a working folder, when one is installing mods in BAIN and sometimes WB are moving mod files before the installation is completed.  A lot of people are using a SSD these days and moving mod files in BAIN could sometimes be somewhat problematic when the user has a SSD (Windows installed) and have a little diskspace left.

 

So what I'm trying to say here is that it would be convenient for any user, if the user could configure WB to manage what partition is gonna be used as a temp folder and not rely on Windows only.

 

Also, I'm not sure if one can do that in WB or not by editing the bash.ini file.

[InsanePlumber]

2 hours ago, Leonardo said:

....So what I'm trying to say here is that it would be convenient for any user, if the user could configure WB to manage what partition is gonna be used as a temp folder and not rely on Windows only.....

@Leonardo

It's a simpler solution.
Change Environment Variables for Temp in windows.

01 RMB on MyComputer in desktop nad Properities
02 Go to the Advanced tab and click Environment Variables

 

[lmstearn]

2 hours ago, Leonardo said:

Utumno

 

I've for, what is it 1-2 years, been using a SSD (Kingston 120 Gb) and lately I have started to reconsider other options of using a SSD.  One thing I can think of is to use it as a "Download" partition, meaning I'll download mods and other files to my SSD.

 

It makes it easier to maintain, plus it also gives me full control of the other partitions I use my HDD's for, one of them is 'C'.

 

I know WB is using the Windows\Temp folder, as a working folder, when one is installing mods in BAIN and sometimes WB are moving mod files before the installation is completed.  A lot of people are using a SSD these days and moving mod files in BAIN could sometimes be somewhat problematic when the user has a SSD (Windows installed) and have a little diskspace left.

 

So what I'm trying to say here is that it would be convenient for any user, if the user could configure WB to manage what partition is gonna be used as a temp folder and not rely on Windows only.

 

Also, I'm not sure if one can do that in WB or not by editing the bash.ini file.

Try this as well as IP's solution: https://answers.microsoft.com/en-us/windows/forum/windows_7-files/change-location-of-temp-files-folder-to-another/19f13330-dde1-404c-aa27-a76c0b450818

Or Utumno could consider this, but that's a huge lot of time and resources for little outcome.

[Leonardo]

On 2017-07-19 at 3:36 PM, InsanePlumber said:

It's a simpler solution.
Change Environment Variables for Temp in windows.

01 RMB on MyComputer in desktop nad Properities
02 Go to the Advanced tab and click Environment Variables

  Reveal hidden contents

 

On 2017-07-19 at 3:39 PM, lmstearn said:

Try this as well as IP's solution: https://answers.microsoft.com/en-us/windows/forum/windows_7-files/change-location-of-temp-files-folder-to-another/19f13330-dde1-404c-aa27-a76c0b450818

Or Utumno could consider this, but that's a huge lot of time and resources for little outcome.

I don't understand why a WB user must fiddle with something in Windows when WB can handle such a thing a lot better than Windows.

 

Although, your last link is something I could accept despite for not being a Python nerd.

 

 

[Arthmoor]

I'm running into a problem with the installers tab. When I load it up, it's showing me some mods with an orange box indicating mismatched files, but this should not be the case. If I do a full refresh on the data, Bash will update things to reflect the current status. The problem is, if I close it and then reload it and go right back to the installers tab to look at the packages again it's telling me the same mods it just updated status for are out of sync again. I can guarantee this is not the case for just about all of them. I have a couple of things in my project folders I know have updates in the works, but it keeps reflagging a bunch of other ones, along with installed mod archives. This started haoppening a few dev versions back but it's persisted and I thought it might sort itself out on its own but it hasn't. If I attempt to have the files synced from the Data folder, nothing gets updated, so somewhere within the system Bash does seem to know the mismatch is false.

Something is clearly not staying updated properly between the full refresh and the next restart but I have no idea what, only that I can consistently get it to happen every time I try. Any suggestions? Cause the only solution I can think of is to destroy the package data that's been saved and I'd rather avoid that if I can.

[RavenMind]

13 hours ago, Leonardo said:

So what I'm trying to say here is that it would be convenient for any user, if the user could configure WB to manage what partition is gonna be used as a temp folder and not rely on Windows only.

FWIW, Since I have Oblivion installed to my SSD I necessarily also have Wrye Bash installed there. However I wanted to keep the read/write ops to a minimum on the SSD so I changed the Windows Environment Variables for TEMP/TMP to a standard HDD. If Wrye Bash were not to rely upon the Windows settings for Temp folders, my guess is that it would default to the install location, the folder where \Bash Installers & \Bash Mod Data are located, or somewhere in \AppData\Local. In my case that would be my SSD. This would definitely tick me off since I had specifically moved Temp off of the SSD. Now, would most people know where WB was doing its temp work? Would this just be another setting that people would have to reconfigure, adding to the already somewhat steep learning curve? I don't know, but it may be worth considering.

10 hours ago, InsanePlumber said:

@Leonardo

It's a simpler solution.
Change Environment Variables for Temp in windows.

01 RMB on MyComputer in desktop nad Properities
02 Go to the Advanced tab and click Environment Variables

  Reveal hidden contents

This is exactly what I did. What seems to have borked it for me was using a folder name with a space in it, (D:Windows Temp). Remove the space, no problem. I would presume other types of special characters might have this problem as well. Lots of other languages use diacritics. I know you can't localize for everybody, but this may present a problem for non-english Users. Probably not a whole lot of people out there using custom locations for their Temp folders so I can see why this issue may not have come up before. If it's too much hassle to adjust the code for such a small problem, maybe just a note in the ReadMe alerting Users with custom Temp locations not to use spaces/special characters in the folder name would suffice. (Assuming those who know enough to change Environment Variables are smart enough to actually READ the ReadMe's.) LOL

[Utumno]

On 7/18/2017 at 11:40 PM, Utumno said:

More complicated than it seems - @Arthmoor:

- what is the exact matching game(s) perform to load bsa/ba2 from espm ? Is it per game ?

- can one mod load mutliple bsas ?

- what about the sound/voice/some.espm/ folder present in oblivion - do mods in other games load similar sound folders based on mod name ?

 

 

@Arthmoor - this was missed

Re: installers - that's serious (and next time you run accross something like that please report immediatelly as it may be easier to track)

I need all the info that you can provide me - including screenshots, exact packages info and most importantly which files show up like mismatched. Do these packages (or are projects) have skips turned on ? Other settings (extra directories etc etc) ? General installers tab settings ? Bugdump also please. I can't debug this without all this info and more info - and it's a perfect chance to fix this king of elusive BAIN refresh bugs - it's now or never

 

EDIT: does this happen on dev ? https://github.com/wrye-bash/wrye-bash/archive/dev.zip

Re: The issue with temp does not have to do with encodings - should be the space - problem is I could not reproduce

[Utumno]

Meanwhile:

307.201707201839

- added caliente tools for skyrim/se

- disables autoghosting pop up for games other than oblivion
- fixes mods with resources being tagged as mergeable - please test. What "broke" is that the format for newer games became some.espm some.*.bsa/ba2. I still need the answers to the questions above maybe also @zilav ?- what I supposed was:
 

Quote

 

- what is the exact matching game(s) perform to load bsa/ba2 from espm ? Is it per game ? -> some.bsa for oblivion, some.*.[bsa|ba2] for rest of games - too general ?

- can one mod load mutliple bsas ? -> yes

- what about the sound/voice/some.espm/ folder present in oblivion - do mods in other games load similar sound folders based on mod name ? -> no

 

 

It's very important we sort the installers bug @Arthmoor

[zilav]

All games except for old Skyrim load archives by partial matching. SSE also uses partial matching. In newer games partial matching is limited to predefined names like 'Plugin - Main.ba2', 'Plugin - Textures.ba2' etc., but xEdit doesn't care and loads up everything.

Due to that only in old Skyrim one mod can load a single archive. In other games several archives.

Yes, voice files paths are named the same in all games using plugin's name with extension.

[Dubious]

3 hours ago, Utumno said:

Meanwhile:

307.201707201839

...

- disables autoghosting pop up for games other than oblivion

...

I know the focus is on the Creation Engine games, but just want to remind you that the other Gamebryo engine games (Fallout 3 and Fallout New Vegas) still need "auto-ghosting" and "mark mergeable" for lower plugin caps as well as Oblivion.

-Dubious-

[Arthmoor]

Mainline Bash does not yet support Fallout 3 or NV. I'd imagine the auto-ghost thing will be considered again when that time comes. In the meantime, that means Bash supports Oblivion, Skyrim LE, Skyrim SE, and Fallout 4. None of which benefit from what ghosting is doing.

@Utumno I will get you the information you need when I get a chance. I'm in the middle of something a bit more important for now though.

[Utumno]

2 hours ago, zilav said:

All games except for old Skyrim load archives by partial matching. SSE also uses partial matching. In newer games partial matching is limited to predefined names like 'Plugin - Main.ba2', 'Plugin - Textures.ba2' etc., but xEdit doesn't care and loads up everything.

Due to that only in old Skyrim one mod can load a single archive. In other games several archives.

Yes, voice files paths are named the same in all games using plugin's name with extension.

Thanks! Well Bash was using exact matching for oblivion too.

Which are the predefined names for completeness ? Is it a regex pattern?

 

@Dubious remind me when we merge F3/FNV support

[Utumno]

@Arthmoor ninja'd on fallout3 (btw ghosting makes sense on Oblivion right ?) - zilav filled the gap with the auto bsas, but I do need the info on Installers - especially the filenames that are marked as mismatching. Look out for case differences between the filename in the project (package ?) and the actual file on disc. Killing your settings won't help as far as I can see - since a full refresh rewrites the settings. Does refresh on package momentarily fix the bug?

[alt3rn1ty]

@Utumno I have just noticed something that may be significant reference where different game instances of Wrye Bash try to save settings backups to (sorry this is going to be one of my long winded descriptions ) :

Usually after you give us a new nightly build I go to the command line and CD all different games \ mopy \, and launch them one after the other getting an initial bashbugdump.log along with testing anything relevant for that instance of Wrye Bash ..

Just now I started without using the command line

First with Oblivion - Bash settings saved into Oblivion Mods \ Bash mod data

Again without using the command line

Second with Skyrim Special Edition - Bash settings saved into Skyrim Special Edition Mods \ Bash mod data

 

Note so far and without using the command line, they have saved respective settings into the correct expected bash mod data \ (where previously for me, when using the command line for all of them, they did not)

 

Now this time, I wanted to get a bashbugdump.log for the last of them, so started with the Command line this time, CD to Fallout 4 \ Mopy \, run WB.exe with -d switch

Fallout 4 Wrye Bash now wanted to save the settings into the Oblivion \ Bash mod data

 

Could launching Wrye Bash from the command line make it want to backup settings into the first run Wrye Bash location ? (in this case Oblivion)

I was pleasantly surprised to see the first and second runs correctly saving to their own folders, so was guessing this minor issue maybe fixed .. But then Fallout 4 misbehaved after being launched via command line.

 

More testing posts to follow, with some good stuff for a change from me  ..

Edit : Sorry late bashbugdump.log for the Fallout 4 run

Wrye Bash starting
Using Wrye Bash Version 307.201707201839 (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 
bash.pyo  322 main: Searching for game to manage:
bush.pyo   89 __supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   91 __supportedGames:  Oblivion: e:\oblivion
bush.pyo   91 __supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   91 __supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  149 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  155 _detectGames: Set game mode to Fallout4 found in parent directory of Mopy:  D:\Steam\steamapps\Common\Fallout 4
bush.pyo  170 __setGame:  Using Fallout4 game: D:\Steam\steamapps\Common\Fallout 4
testing UAC
mods_metadata.pyo  223 __init__: Using LOOT API version: 0.10.2
barb.pyo  163 Apply: 
barb.pyo  164 Apply: BACKUP BASH SETTINGS: E:\Oblivion Mods\Bash Mod Data\Backup Bash Settings Fallout4 (2017-07-20 21.57.54) v307.201707160231-307.201707201839.7z
barb.pyo  176 _backup_settings: My Games\Fallout4\BashSettings.dat <-- D:\Documents\My Games\Fallout4\BashSettings.dat
barb.pyo  176 _backup_settings: Fallout4\Mopy\bash\l10n\Italian.txt <-- D:\Steam\steamapps\Common\Fallout 4\Mopy\bash\l10n\Italian.txt
barb.pyo  176 _backup_settings: Fallout4\Mopy\bash\l10n\Russian.txt <-- D:\Steam\steamapps\Common\Fallout 4\Mopy\bash\l10n\Russian.txt
barb.pyo  176 _backup_settings: Fallout4\Mopy\bash\l10n\Chinese (Simplified).txt <-- D:\Steam\steamapps\Common\Fallout 4\Mopy\bash\l10n\Chinese (Simplified).txt
barb.pyo  176 _backup_settings: Fallout4 Mods\Bash Installers\Bash\Converters.dat <-- D:\Steam\steamapps\Common\Fallout4 Mods\Bash Installers\Bash\Converters.dat
barb.pyo  176 _backup_settings: My Games\Fallout4\Saves\Bash\Table.dat <-- D:\Documents\My Games\Fallout4\Saves\Bash\Table.dat
barb.pyo  176 _backup_settings: Fallout4\Mopy\bash\l10n\Chinese (Traditional).txt <-- D:\Steam\steamapps\Common\Fallout 4\Mopy\bash\l10n\Chinese (Traditional).txt
barb.pyo  176 _backup_settings: Fallout4\Mopy\bash\l10n\pt_opt.txt <-- D:\Steam\steamapps\Common\Fallout 4\Mopy\bash\l10n\pt_opt.txt
barb.pyo  176 _backup_settings: My Games\Fallout4\BashLoadOrders.dat <-- D:\Documents\My Games\Fallout4\BashLoadOrders.dat
barb.pyo  176 _backup_settings: Fallout4 Mods\Bash Mod Data\INI Data\Table.dat <-- D:\Steam\steamapps\Common\Fallout4 Mods\Bash Mod Data\INI Data\Table.dat
barb.pyo  176 _backup_settings: Fallout4\Mopy\bash\l10n\de.txt <-- D:\Steam\steamapps\Common\Fallout 4\Mopy\bash\l10n\de.txt
barb.pyo  176 _backup_settings: Fallout4 Mods\Bash Mod Data\Table.dat <-- D:\Steam\steamapps\Common\Fallout4 Mods\Bash Mod Data\Table.dat
barb.pyo  176 _backup_settings: Fallout4 Mods\Bash Installers\Bash\Installers.dat <-- D:\Steam\steamapps\Common\Fallout4 Mods\Bash Installers\Bash\Installers.dat
barb.pyo  176 _backup_settings: My Games\Fallout4\Saves\Bash\Table.dat.bak <-- D:\Documents\My Games\Fallout4\Saves\Bash\Table.dat.bak

[alt3rn1ty]

5 hours ago, Utumno said:

- disables autoghosting pop up for games other than oblivion

 

But Auto Ghosting is still selectable though for Skyrim SE and Fallout 4, on the Mods Tab Header Bar Right click Context Menu ..

 

[alt3rn1ty]

And the good news, from the images in the last post you may have noticed ..

icepenguinworldmapclassic.esp

Is 1 ) Not green, and 2 ) still selected (having rebuilt the bashed patch)

 

Though a bit of strangeness :

As an experiment I deleted the associated .bsa and .ini files (manually from data), to leave it on its own as just an .esp, then reloaded Wrye Bash

The plugin is no longer recognised at all as a potentially merge-able plugin

Is Wrye Bash recognising the plugin from the Installer as having an associated .bsa, or recognising the plugin in data as having an associated .bsa - If its the latter then after deleting the bsa Wrye Bash should be colouring it green again and offering to merge it?

[Beermotor]

Update on this although I can't make a proper detailed report at the moment due to time constraints:  I can replicate the "not green" issue on two packages in my install order.

There are no conflicts, but the plugins for both are showing under "mismatched".  I'll see if I can get proper reproduction steps soon.

 

[alt3rn1ty]

LOOT is on version 0.11.0 since May https://github.com/loot/loot/releases

Will Wrye Bash need an update ?

I ask because there was an issue on Fallout 4 Wrye Bash comments which apparently is resolved if you match up the LOOT installed with the LOOT API Wrye Bash is using .. I didn't even realise that could cause Wrye Bash any issues (or at least not be relevant to someone trying to shift their Bash Installers location to another HD vie the Bash.ini)

[Arthmoor]

3 hours ago, Utumno said:

@Arthmoor ninja'd on fallout3 (btw ghosting makes sense on Oblivion right ?) - zilav filled the gap with the auto bsas, but I do need the info on Installers - especially the filenames that are marked as mismatching. Look out for case differences between the filename in the project (package ?) and the actual file on disc. Killing your settings won't help as far as I can see - since a full refresh rewrites the settings. Does refresh on package momentarily fix the bug?

This is pretty simple to replicate on my end. Doesn't matter which game it's for. Let's just use my SSE install as an example. This is what the packages list looks like if I start up and do nothing more than go to the installers tab. Notice the Castle Volkihar Rebuilt mod (and others) are marked in orange when they should not be.

 

Then if I perform a full data refresh, the results change to this:

Notice that CVR is now correctly indicating it matches the install, as do several other files. The ones left orange or yellow at this point are correctly reflecting that they don't match the contents of the projects or archives.

If I close Bash and do nothing more than start it back up and go back to the installers tab, the results return to the first pic. When it's in the state of the first pic, it will refuse to sync the files from the Data folder because it somehow knows the mismatch is false.

Not sure what else I could provide here since the affected mods seem random and you now have Beermotor's confirmation of it happening in other packages too.

[Beermotor]

11 hours ago, Arthmoor said:

This is pretty simple to replicate on my end. Doesn't matter which game it's for. Let's just use my SSE install as an example. This is what the packages list looks like if I start up and do nothing more than go to the installers tab. Notice the Castle Volkihar Rebuilt mod (and others) are marked in orange when they should not be.

 

In my case, after I posted last night I uninstalled both mods and noticed they had left their plugins behind in the Data folder.  I hadn't processed them in xEdit yet, but there they were. I backed them up and manually removed them, then downloaded the files again, reinstalled, and now everything is green again. 

The only other information I can think of is I installed these packages under an older WIP build and have upgraded a time or two on top of this.  I just noticed the orange status recently but they checked out after a refresh similar to @Arthmoor's experiences. 

I have another package that is pink that I'm going to check out this evening if I have time. If anyone can think of anything I should look at please let me know. I'm not opposed to installing Pylint or something to run a debugger/stack trace. 

[Arthmoor]

Regarding the installers issue, I appear to have forgotten how to get Bash to dump a log of what it's doing. The debug launch option only logs errors and the process I'm doing is not throwing any.

[alt3rn1ty]

3 minutes ago, Arthmoor said:

Regarding the installers issue, I appear to have forgotten how to get Bash to dump a log of what it's doing. The debug launch option only logs errors and the process I'm doing is not throwing any.

You need this link

[Utumno]

21 hours ago, alt3rn1ty said:

Though a bit of strangeness :

As an experiment I deleted the associated .bsa and .ini files (manually from data), to leave it on its own as just an .esp, then reloaded Wrye Bash

The plugin is no longer recognised at all as a potentially merge-able plugin

Is Wrye Bash recognising the plugin from the Installer as having an associated .bsa, or recognising the plugin in data as having an associated .bsa - If its the latter then after deleting the bsa Wrye Bash should be colouring it green again and offering to merge it?

Edge case in the code - since the plugin has not changed size or mod date we don't rescan for mergeability - Run Scan Mergeable on it

20 hours ago, Beermotor said:

Update on this although I can't make a proper detailed report at the moment due to time constraints:  I can replicate the "not green" issue on two packages in my install order.

There are no conflicts, but the plugins for both are showing under "mismatched".  I'll see if I can get proper reproduction steps soon.

 

Which exactly files show as mismatched and aren't - @Arthmoor too for CVR. Does running a refresh on the package (not a full refresh on all installers) momentarily fix it ?