Wrye Bash - All Games

[Vrugdush]

Thanks Sharlikran. I wasn't expecting BOSS support to be added back in; I was just wondering if there was a way for me as an end user to turn it back on in my copy, or if it was completely removed. It turned out to be the latter, as expected. I have no coding skills to help out with, I'm afraid.

 

Yes, I look at plugin headers as well as BOSS and LOOT to see what Tags are suggested. In my example, BOSS had added a Tag that the others were missing. I have made Bash Tag suggestions to mod authors before, and I'll try to continue to do so. I agree that it is indeed better if Tags are added directly to the plugin, not only because it will reach the most people that way, but also because the mod author should hopefully know best which Tags their mod would benefit from. In the case of Oblivion though, it can be tricky, since many mods are so old, and authors may have long since retired. But yes, I'll try.

 

I'll probably be back to ask some potentially silly questions about Bash Tag patcher logic soon, so you might want to steel yourself.

 

In other news, I'm happy to see that a UI bug with dragging and dropping across Markers in the Installers tab, that I reported on many years ago, seems to have been fixed. Yay! Go Wrye Bash team!

[lmstearn]

I'll be trying out Oblivion with new WB- but attempting to avoid any BOSS/LOOT issues as much as possible.

[Sharlikran]

7 hours ago, Vrugdush said:

 It turned out to be the latter, as expected. I have no coding skills to help out with, I'm afraid.

I'll probably be back to ask some potentially silly questions about Bash Tag patcher logic soon, so you might want to steel yourself.

In other news, I'm happy to see that a UI bug with dragging and dropping across Markers in the Installers tab, that I reported on many years ago, seems to have been fixed. Yay! Go Wrye Bash team!

I mostly just mentioned that contributing the code was an option for anyone reading. 

I don't visit much these days but many get the logic. I'm not sure ther is really a logic to it though. If you wonder if you need to add a tag you just read the docs. If it says that for XNAM changes in ZZZZ record then if that is changed you add that tag. It has always been something you manually look for and add. The one good thing though is once the mod requires the tag you are done with that tag. For example if a leveled list deletes something, stop looking at other records for deleted entries. If you see one case where the level is changed stop looking for that. If you end up with one case of both then both are needed.

I'm glad that the UI works better for the markers, but that's all Utumno.

[Utumno]

On 3/17/2018 at 3:21 PM, Dubious said:

Re: The "FalloutNVLauncher.exe" always rebuilding the "C:\Users\..." INI files and resetting them to "RO".  The Launcher is usually only run once, so it will detect and adjust the INI files for the hardware.  After that everyone typically launches the game from the "FalloutNV.exe" file, because that is the one that the "FNV4GB Patcher" is run against to get more than the default 2GB of system RAM allocated to 32-bit games.  That EXE does not rebuild or reset the INI files.  Even when run from the Steam Overlay (or without), that is the EXE used.  In the 3+ years I've been supporting people in that game, I haven't run into what @alt3rn1ty discovered, so it's not a common problem.  Worth noting though.

Re: Wrye Flash 17.7 (WF17) to "wrye-bash-150-fo3-fnv-support.zip" (WB307) dated  2018-03-12 migration.

There is a "NVDLCList.txt" file in the "[Users]\AppData\Local\[Game]" folder which is empty by default when WB307 is installed.  FNV's DLC ESM files require a specific load order sequence, and this seems like the intended place for it.  (The list in the "plugins.backup.nmm" is not sorted correctly for this purpose.)  Propose setting "NVDLCList.txt" as follows:

# This file is used to tell FalloutNV the order in which to load DLC files.
FalloutNV.esm
DeadMoney.esm
HonestHearts.esm
OldWorldBlues.esm
LonesomeRoad.esm
GunRunnersArsenal.esm
ClassicPack.esm
MercenaryPack.esm
TribalPack.esm
CaravanPack.esm

These files are now properly sorted in the "Mods" tab when it is first populated.

I've been running into a problem running "wrye-bash-150-fo3-fnv-support.zip" (WB307) dated  2018-03-12 as a Python install outside of the game folder, getting the "installers" tab to properly load the packages and markers from "Wrye Flash 17.7" (WF17) "StandAlone".

For instance, I have been removing the following (and their ".bak" files) after a failed WB307 test run, and restore the same files from WF17 to try to get back to a "prior to first run" state with WB:
[Users]\Documents\My Games\[Game] || BashSettings.dat, BashLoadOrders.dat.
[Game] Mods\Bash Installers\Bash || Installers.dat.
[Game] Mods\Bash Mod Data || Table.dat.

After restoring both BAIN and the "Mod" tabs in WF17, upon initially loading WB307 detected the version difference (in ?"Table.dat"?), offered to create a backup archive, and did so successfully (once I had ensured the destination folder was not ""Read Only").

It's only been partially successful detecting the WF configuration.  The "Mods" tab is populated and sorted with the plugins marked as "active" correctly, while the BAIN tab loads the packages alphabetically (but not detecting "installed" status) with only the "==Last==" marker near the top after it rebuilds the CRCs.  If the packages themselves are not found, then it loads ALL the markers previously defined.  The WF17 version of "Installers.dat" is now the ".bak" file.  It's as if it ignores the  WF "Installers.dat" completely if it finds the packages, but uses it if it doesn't locate the packages. This has held consistent through several test iterations.

BashBugDump.log

  Reveal hidden contents

Wrye Bash starting
Using Wrye Bash Version 307.201803112048
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
command line: ['Wrye Bash Launcher.pyw', '--debug']
bash.py  286 _main: Searching for game to manage:
bush.py   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   82 _supportedGames:  FalloutNV: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  146 _detectGames: Set game mode to FalloutNV based on sOblivionPath setting in bash.ini:  E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  161 __setGame:  Using FalloutNV game: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
mods_metadata.py   39 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC

-Dubious-

6

Sorry it took a while I am super busy with RL

The only setting files that should affect BAIN are the:

[Game] Mods\Bash Installers\Bash || Installers.dat.

and .bak of it. Markers are stored there as well as install order, installed status etc

Active Mod information is read from plugins.txt so it's not stored in Bash. Load order information is read from modification times so it should be ok just to order the files correctly based on modification time

Re: BAIN

> If the packages themselves are not found, then it loads ALL the markers previously defined

So WB307 reads the markers from WF17 Installers.dat? That's good - or doesn't it read the markers at all if packages are found?

What this may mean then is that the format of the Installers.dat has changed since and when it does find the (some) packages it tries to load those but it fails and then ignores the Installers.dat of WF17. I would need this Installers.dat along with some packages links that are present in this Installers.dat to troubleshoot this but may prove not fixable.

[Dubious]

No problem with the delayed response.  RL happens.

Quote

So WB307 reads the markers from WF17 Installers.dat? That's good - or doesn't it read the markers at all if packages are found?

If (packages in "Bash Installers" folder <> found) then
  BAIN properly reads the markers from WF17 Installers.dat;
Else
  BAIN reads the packages alphabetically, but not the markers in WF17 Installers.dat.
EndIf
Attached: WF17 Installer.dat.zip

The following plugins are under my "utilities" marker, and only require the main game and the NVSE script extender be installed.  Please see 'Checklist Item #4' entry in the wiki "Fallout NV Mod Conflict Troubleshooting" guide for installation instructions and checks it's working.

Plugin links (install order#):
08. JIP LN NVSE Plugin
09. NVAC - New Vegas Anti Crash (NVAC)
12. New Vegas Stutter Remover (NVSR)
13. CASM with MCM

-Dubious-

[Sharlikran]

Something to keep in mind is that the DAT files for Valda's version use much older syntax. It will not convert to 307 because most of the routines have been updated and some of the functionality for converting from 295 has been removed. Those upgrading from Valda's version should not expect things to convert properly. If you use 307 to test do not expect to go back to Valda's versions without issues unless you made backup files.

[Dubious]

21 hours ago, Sharlikran said:

Something to keep in mind is that the DAT files for Valda's version use much older syntax. It will not convert to 307 because most of the routines have been updated and some of the functionality for converting from 295 has been removed. Those upgrading from Valda's version should not expect things to convert properly. If you use 307 to test do not expect to go back to Valda's versions without issues unless you made backup files.

Ouch!  That's going to mean FNV users aren't going to be able to use WB307 at all, since it can't create a FNV BP at the moment.  Without the ability to use the same DAT files for both WF17 and WB307,  switching to WB307 for it's improved BAIN management is a non-starter.  I realize there really isn't any interest in working on WF17, but assuming it would be easier to make the DAT file syntax compatible with WB307 than converting the patcher code, is there any chance of fixing that?

-Dubious-

[alt3rn1ty]

@Utumno Can you please give a way forward outline, and what are the next objectives post Beta - My biggest burning question ; Is the grokking of Skyrim Patchers and further development that we have all had our fingers crossed for five years, nearly at the stage to go ahead?. Or is there more refactoring of the whole code base polishing to come first? ( I caught that you have been super busy RL recently, so I dont think anyone is anticipating anything major happening in the near future, apart from 307 coming out of beta at some point which in itself is quite a major update )

[warmfrost85]

On 4/9/2018 at 3:01 AM, alt3rn1ty said:

the grokking of Skyrim Patchers

Is that the same as asking, "When will more Skyrim SE Bash tags be enabled?"

[alt3rn1ty]

Its a phrase Utumno has said a couple of times meaning one day he hopes to understand (Grok) how Wrye Bash Patchers work, like Merge Patches / Imports Actors / etc (collectively known as Patchers) and be able to expand upon them for newer games than Oblivion.

Wrye Bash and its Bashed Patch is capable of far more than just levelled lists, which is mostly all that anyone can use for Skyrim LE / Fallout 4 / Skyrim SE ..

But the refactoring of all the code needed to be done first, so development of patchers for the newer supported games since Oblivion have been put on hold until all refactoring was done, and then Wrye Bash and its main feature (creating a Bashed Patch) could advance once again in its development.

 

More Bash Tags are I suppose the pinnacle of that request, because without development of the Patchers themselves then Bash Tags cannot be enabled for the ones not working yet per game.

 

I said many moons ago that I would update the Wrye Bash Pictorial Guide again once Wrye Bash was in a good place for me to start producing final screen shots for the purpose .. The first screenshot above for Oblivion is the main one holding up the guides, because until Wrye Bash is at a similar level of completeness in its patchers for the newer games, there is no point producing it only to be re-produced over and over each time a new Patcher is added.

So for all people wondering why the guide has not been updated, thats the reason ..

.. and why I ask what the roadmap is so I can anticipate when to put some time asside for that.

[Utumno]

Thanks Dubious and Sharl for feedback - I am still pressed for time but here is a rough roadmap

 

For 307.beta3:

 

- Loot integration - waiting on @Daidalos and @WrinklyNinja on that

- Fallout3/NV - many headed hydra, popping more heads as it seems

- Fix Restore Settings

I would hope this is out beginning of May

 

308:

Most of the refactoring is done @alt3rn1ty. 306 and 307 are the main refactoring releases. That being said there is still much work to be done internally -  for instance, see https://github.com/wrye-bash/wrye-bash/milestone/13. Well, my mind is an immense TODO list but main goals are stated in https://github.com/wrye-bash/wrye-bash/blob/dev/Contributing.md. Among them the priorities for 308 that affect the users:

1. Move on to newer python/wx python versions, initially wx classic 3.02
2. Update save files editing code for games other than Oblivion

It's high time we switch to wx python3 - this will maybe fix things like the recurring status bar icons resize crash. Saves code would be possible to be extended for other games - provided we have coders to do so - @nycz has had some experience with the saves code.

1. Update patchers so Wrye Bash can process Skyrim's and Fallout4 files as it does for Oblivion

is a laudable goal but as I said I need coders

[Utumno]

@Dubious I tried your reproducer and here is what I get:

So I think that what fails are the BAIN projects - that is, folders as opposed to archives. Can you pack your projects to archives in WF17, remove the projects, save your WF17 Installers.dat and try again loading this Installers.dat? Could you also send me one such zipped project so I unzip it and see if it fails?

 

Edit @Dubious - the order is a bit messed up but at least archives load - hopefully will be easy to fix the order once we make it load

Edit2: tried with a project named u'NVWillow v1.09-BAIN-41779-1-09.09-41779-1-09' I found in WF17 Installer.dat.zip and this does not seem the problem - so, unfortunately, this means that a particular package out of 600+ crashes the loading of Installers.dat. I have to add debug prints on the python branch to pin that package.

EDIT3: pushed those debug prints to https://github.com/wrye-bash/wrye-bash/tree/150-fo3-fnv-support -> unzip, add your ini that redirects installers paths and run on debug mode, it should add a list of packages that failed to load in the bugdump

[Vrugdush]

Can I add two small and hopefully simple UI bug fix requests, please? I checked GitHub, but didn't notice them on there.

 

The first one I've seen mentioned before, but I'm not sure if anything ever came of it: the executable for the BOSS GUI changed names from "BOSS GUI.exe" in earlier versions of BOSS to "boss_gui.exe" at some point. Wrye Bash still expects the old filename and so fails to launch the application if "Launch using GUI" is ticked on BOSS in the Launcher Bar. This can be fixed by the user manually changing the filename, but it's a bit clunky, and not everyone might know how to do it. I know you've removed BOSS integration, but at least launching the program should work correctly, right? :-)

 

The second one is similar, but this time it's a URL format that has changed rather than a filename: Nexus changed their URL structure from "game.nexusmods/mods/modnumber" to "nexusmods/game/mods/modnumber", so Wrye Bash can't open the links to mods properly anymore when you right-click a Package in the Installers Tab and select "Open at" > "TES Nexus". Again, easily fixed on the end user side by re-arranging the URL elements, but as this has to to be done every time you look up a mod at Nexus, it gets a bit tedious.

 

Oh, and I should mention that this pertains to Wrye Bash v307.201803112048 Standalone for Oblivion on Windows 10 Pro 1709, even though I doubt it makes a difference with bugs of this nature.

 

Thanks for your time.

[Utumno]

Thanks for the structured report @Vrugdush - will fix in next built (actually posted the fix in python code in 150-fo3-fnv-support branch)

[alt3rn1ty]

@Utumno I think we may have another for the credits - Have a look at this https://en.wikipedia.org/wiki/Kyoto_school_(art)#/media/File:Singes_Sosen.jpg

Familiar ?. Someone asked on Skyrim SE nexus where the picture of the monkey came from, and I couldn't source it, but believed either Wrye or maybe someone like Metallicow may have used an open source image ..

.. Anyway, Ironfounderson came up with that link which is Public Domain - Do you think it ought to be mentioned in credits as a source ?, the image is just too similar for it not to be.

[Dubious]

Test using "wrye-bash-150-fo3-fnv-support_20180415_1849.zip" (WB307) and "Wrye Flash 17" (WF17).

Good news is now all the markers and plugins are being recognized.  As shown in the debug log, one ".ZIP" file did get hung using the 7Zip package.  I had to manually kill that 7Zip sub-process tree, but once it got past that file the remainder of the process went fine.  (Debug log below.)  I reset and ran a second test without that file and everything went both quickly (dramatically so) and smoothly.

The "install order" appears to be correctly sorted (I didn't take the time to check "before" and "after" on all 659 mods, but spot checks were correct).   The BAIN Projects show up with the correct color coding to reflect install status of their constituent component files that are installed from the package built from them.

I then ran WF17 against the resulting files without changing anything.  It appeared to have no issues using the WB307 files.  I'll run some more tests switching back and forth between the versions, but at first blush it's looking good.  Congratulations on solving that little conundrum.

The only apparent remaining issue seems to be that the plugin contents that install into the "New Vegas Script Extender" (NVSE) plugins folder ("Fallout New Vegas\Data\NVSE\Plugins") did not get recognized as installed.  Those packages show up as a black "+" on a white box, with the details showing zero for all categories (installed, matching, and conflicts).  The minimal test for this would need to install "NVSE script extender" and "JIP LN NVSE Plugin".  Please see 'Checklist Item #4' entry in the wiki "Fallout NV Mod Conflict Troubleshooting" guide for installation instructions and checks it's working.

The file in question causing the hang unpacking is Fallschirmjager-49266-1.zip.  From comments on the download page, it appears to have internal errors in it's mod construction even though the archive tests out as "no errors".

Debug log:

Spoiler

Wrye Bash starting
Using Wrye Bash Version 307.201804150204
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
command line: ['Wrye Bash Launcher.pyw', '--debug']
bash.py  286 _main: Searching for game to manage:
bush.py   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   82 _supportedGames:  FalloutNV: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  146 _detectGames: Set game mode to FalloutNV based on sOblivionPath setting in bash.ini:  E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  161 __setGame:  Using FalloutNV game: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
mods_metadata.py   39 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC
Failed loading Fallschirmjager-49266-1.zip due to 'ascii' codec can't decode byte 0x84 in position 81: ordinal not in range(128)
bain.py  301 __setstate__: Failed loading Fallschirmjager-49266-1.zip
Traceback (most recent call last):
  File "bash\bosh\bain.py", line 298, in __setstate__
    self.__setstate(values)
  File "bash\bosh\bain.py", line 329, in __setstate
    dest_scr = self.refreshDataSizeCrc()
  File "bash\bosh\bain.py", line 652, in refreshDataSizeCrc
    Installer._silentSkipsStart) or fileLower.endswith(
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 81: ordinal not in range(128)

-Dubious-

[Utumno]

16 hours ago, alt3rn1ty said:

Do you think it ought to be mentioned in credits as a source ?

Hahaha this is not credits this is Lore department

@Dubious thanks for trying it out - will have a look at the NVSE thing and at that package - when you say

4 hours ago, Dubious said:

I had to manually kill that 7Zip sub-process tree, but once it got past that file the remainder of the process went fine.

You mean that Bash hung if you didn't kill the 7zip process? Or that the process remained in the background but Bash continued?

[Vrugdush]

Bug report: Unexpected behaviour of CBash in Oblivion regarding the Tags R.ChangeSpells and R.AddSpells. The bug doesn't seem to exactly correspond to any of the previously reported issues with CBash, but hopefully you can start noticing a pattern.

Here's an example of the bug and the minimal load order required to reproduce it. Test plugins and example pictures are included.

One plugin modifies a race to change its racial spells. Another, later-loading one, modifies the race's textures. The first one is Tagged with R.ChangeSpells, and the second with Body-F, Body-M, R.Head, and R.Ears. Neither is Tagged with NoMerge. Rebuild the Bashed Patch normally with PBash and CBash, respectively. Let the plugins be deactivated and merged when asked. Only Merge Patches and Race Records need to be ticked in the Bashed Patch configuration window. Make sure both test plugins are ticked in both places. Compare the results in TES4Edit.

• PBash gives the expected merging of the records; the race gets both the changed spells and changed textures.
• With CBash the change to the race's spells is ignored, and the race ends up with only the changed textures.

 

If the Tag instead is changed from R.ChangeSpells to R.Addspells, you get a different, but also unexpected result:

• With PBash the race ends up with both the original and modded spells, as expected.
• With CBash the race ends up with only the modded spells, like the PBash result with R.ChangeSpells.

 

TL;DR: In CBash the R.ChangeSpells Tag does nothing, and R.AddSpells works like R.ChangeSpells does in PBash.

 

I first noticed this bug with Cobl Races - Balanced and a homemade racial aesthetics mod that needs to load after it, but I've reproduced it with special test plugins that are included here.

Tested with Wrye Bash v307.201803112048 Standalone for Oblivion on Windows 10 Pro 1709. Here's my BashBugDump.log:

Spoiler

Wrye Bash starting
Using Wrye Bash Version 307.201803112048 (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: ('sv_SE', 'cp1252')
filesystem encoding: mbcs
command line: ['C:\\Spel\\Oblivion\\Mopy\\Wrye Bash.exe', '--Language', 'English', '--debug']
Using scandir 1.5
bash.pyo  286 _main: Searching for game to manage:
bush.pyo   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   82 _supportedGames:  Oblivion: c:\spel\oblivion
bush.pyo   82 _supportedGames:  Skyrim Special Edition: C:\Spel\Steam\steamapps\common\Skyrim Special Edition
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to Oblivion found in parent directory of Mopy:  C:\Spel\Oblivion
bush.pyo  161 __setGame:  Using Oblivion game: C:\Spel\Oblivion
testing UAC
mods_metadata.pyo  229 __init__: Using LOOT API version: 0.12.0

I hope it helps. If there's any interest, I could check on the previously reported CBash bugs and see if they still apply.

Addendum for clarity: The Tags on the second plugin don't matter; they're just they're for the purpose of making the example plausible. Also, when building the Bashed Patches, make sure to do it in a way that ensures that they don't influence each other, for example by having the Patch you're not currently building unticked, later in the load order and ghosted. Or just have one Bashed Patch at a time.

R.ChangeSpells Test Plugin 2 - Textures.esp

R.ChangeSpells Test Plugin 1 - Spells.esp

Edited April 18, 2018 by Vrugdush
Clarity

[Dubious]

On 4/17/2018 at 8:39 AM, Utumno said:

@Dubious when you say

You mean that Bash hung if you didn't kill the 7zip process? Or that the process remained in the background but Bash continued?

Bash hung until I killed the 7zip process (apparently for that file only).  Once I did that, Bash continued to process the remainder of the files without incident and produced an apparently correct BAIN.  (Didn't take the time to verify that before resetting and testing again without the suspect file.)  That was different behavior from previous tests, where it ran to completion but didn't produce a BAIN list with more than the "==Last==" marker entry.

-Dubious-

[Utumno]

@Vrugdush thanks for the excellent bug report however there is no one working on CBash now. EDIT: Did the bugs you reported get fixed in the python WIP ?

 

@Dubious I downloaded the wrong version will try again - this should be added to the wiki - as in "BAIN files can be mostly transferred from WB17 to WB307 but if it hangs kill 7z"

[Vrugdush]

@Utumno Fair enough. I suspected as much, but I'm hoping someone will be able to look at it eventually. :-)

In the meantime, I guess the warning that CBash is in Beta should probably stay in place, but it might not be enough to deter most users... The merging of more record types is just too good to give up, and using CBash seems to have become the norm for Oblivion. Some mods even require its extra Bashing power to work as intended nowadays.

Maybe some kind of official statement could be made in the documentation telling users which Patchers and Tags might not be functioning as intended in CBash? Most users probably don't read the list of open bugs, but if it's in the documentation, and the popular modding guides pick up on it, the word might spread. Then users can choose to use Python for the tricky Bashings instead. There should probably also be some guidelines for how to use multiple Bashed Patches then.

I suppose that's very low priority with all that's going on at the moment though. Just food for thought.

EDIT: I've only tried the Standalone. I'll make sure to get Python, etc. installed and have a look at the "bleeding edge" version.

Second EDIT: I've now tried the "wrye-bash-150-fo3-fnv-support" support branch. Learning how forks worked on GitHub was good fun. I can happily report that the UI bugs/oversights are fixed. Turns out that the Nexus URL one wasn't very severe though; Nexus actually automatically reroutes from the old URL format. I just had a browser addon, HTTPS Everywhere, that prevented it. That's probably why no one had reported the "bug" until now; the old URL format worked fine unless a browser addon interfered with the redirection. I noticed something was fishy when Waterfox managed to open a link in the old URL format once per session, but no more than that. I guess that when Waterfox was closed, and then opened by a link in Wrye Bash, Nexus had time to reroute the URL before HTTPS Everywhere kicked in.

Second EDIT, continued: I did however notice another quirk with the BOSS GUI and the Launcher Bar: Once you've launched the BOSS GUI, Wrye Bash doesn't respect the state of the "Launch using GUI" toggle/flag until you exit and restart. It will just keep launcing the GUI instead of command line BOSS regardless of the state of the flag. However, as long as you never actually choose to launch the BOSS GUI, you can keep toggling the flag on and off, and the state is respected, and the BOSS command line can be launched. It doesn't matter whether you start Wrye Bash with the flag on or off, only whether you've actually launched the BOSS GUI during the current session. Conversely, you can launch command line BOSS and then the BOSS GUI in the same session without any problems. The bug is present in the dev branch as well, so it's not something that was caused by the recent "boss_gui.exe" filename fix.

Third EDIT: The bug happens even when failing to launch the BOSS GUI, i.e. when "boss_gui.exe" isn't renamed for the non-bug fixed Wrye Bash build, so it's probably not due to something that the BOSS GUI is doing. Also, the bug is specific to the BOSS "Launch using GUI" option, and isn't with toggles/flags in the Launcher Bar in general, because it doesn't happen with the "Tes4Edit Expert" flag. That one can be toggled on and off in the same Wrye Bash session without problems, and the state is respected.

[alt3rn1ty]

@Utumno Just a heads up we are starting to get a few posts along the lines of "Hey guys, just seen this amazing post on Skyrim / Fallout VR support and apparently Wrye Bash kind of works fine in my humble (haven't got a clue really) opinion"

So I made another addition to the (damned never decreasing in size) sticky posts ..

Quote

Do not post about Skyrim or Fallout 4 VR support, modding those games is not currently supported by Bethesda, and until there is at least a Creation Kit for them there is no point in attempting to make Wrye Bash compatible - Any suggestions that it does work with the VR games will be deleted due to not being supported / endorsed in any way by the Wrye Bash development team

Correct me if wrong but I am pretty sure thats how things stand, until Bethesda officially start supporting modding of those games, and the community figures if there are Record additions / Record format changes / Save format changes / and whatever other technical spanner in the works issues a new version of the game can bring.

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

 

Also on Skyrim Nexus, we have a user lunamichelle41 on Windows Vista having issues trying to get Wrye Bash working - Is Vista still supported ( as noted in the Wrye Bash docs http://wrye-bash.github.io/docs/Wrye Bash General Readme.html#install ) or does the LOOT API negate that OS as compatible ( I know LOOT itself https://github.com/loot/loot/releases requires Win 7 or above, not sure about the API ) ??

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

 

And in case you dont skim the other topics here, something you might miss 

 

[Utumno]

Thanks @alt3rn1ty - I have pull requests and issues for VR games (no clue what's that) but yes, for now, let's focus on LOOT and good old Fallout 3/NV

Vista should be supported by the LOOT API but @WrinklyNinja should know for sure

[Utumno]

Aaaaand

307.201804202117

Should fix the boss gui bug reported by @Vrugdush and I also made some fixups in BAIN - multiply nested packages and some other stuff on package recognition I run across while debugging the WF17 porting of Installers.dat reported by @Dubious. The crash with Fallschirmjager-49266-1.zip. turns out was related to an entry in Installers.dat for that file that was apparently very very old - technically fileSizeCrc was string not unicode and blew as it contained germnan umlauts

This also contains the latest LOOT however the executable crashes for me - I need feedback on that. See:

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

https://github.com/wrye-bash/wrye-bash/pull/408

 

[alt3rn1ty]

26 minutes ago, Utumno said:

~ issues for VR games (no clue what's that) ~

Bethesda have released new versions of the Skyrim and Fallout 4 games, that need a Virtual Reality (VR) Headset (and I think special handsets). I dont know what platforms they are releasing for (guessing its just for PS4 initially), but no doubt there will be what initially looks like a similar bunch of files installed, Bethesda will be wanting to keep the look and as much of the original game but shoe horn it into a VR environment. I know for one thing that Terrain generation will be different, but what other technical changes there will be in game idk. The thing is, same as usual the community immediately goes "lets try stuff, seems to work, therefore alls good" .. yeah, no. But before you know it ten thousand people swear everythings fine like its been tested by professionals

Hence the pre-emptive message for Wrye Bash usage with VR setups - There have already been two posts claiming everything is hunky dory using current Wrye Bash with VR versions of the same games from third parties spreading the "good news". So they were promptly squished.