Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

My ini was read-only after installing FNV for the first time in 3 years.  Last time it wasn't like that.  Even FNV couldn't save changes to settings made via the in-game options.

 

I'll be testing this new branch of Bash too.  Last I heard, FO3 & FNV were not a priority for support, so this is quite the treat to see.  Flash is okay--does the job--but some modernizing is pleasing to see.

Link to comment
Share on other sites

When you (or any program) creates a new folder, it inherits the access permissions and protections of the parent folder, back to the root folder of the partition/drive.  By default, Windows (since some unnoticed security update) gives these "read only" (RO) on new folders and files.  People are in the habit of just changing it on a given sub-folder or file, but not on the parent folder(s).  The next new folder inherits from the parent (which probably is inheriting from the "root folder") and it's "RO" again.  Along comes another security update, and the root defaults may get propagated down once again.  (More MS "big brotherism".)

When you change the folder properties, it's got an option that is supposed to allow you the propagate changed permissions and protections downward to sub-folder and files within the changed folder, but does not always seem to work correctly (at least in my experience on Win7SP1).  Double-checking after such a propagation I have still found folders which are "RO" until manually changed.  Even so, MS seems to reset folders to appear "RO" in Windows Explorer, though the file contents are left alone once changed.  "RO" on folders does not appear to act the same as on files, as you can still create new files within them.

-Dubious-

Link to comment
Share on other sites

@Utumno New Flash fires up, installers work (for the most part--see below) an d seem to recognize an old Flash installation fine.  Good stuff.  But,

NVSE Plugins are not working right.  If the package has only the NVSE\Plugins\ directory with anything inside (or not) it doesn't get recognized.  Most options are greyed out.  If I were to add an extra directory to the package ("Meshes", for example) it gets partially recognized and I can select "Has extra directories" and all is good.

So, BAIN does not recognize NVSE plugins.

Link to comment
Share on other sites

12 hours ago, Malonn said:

My ini was read-only after installing FNV for the first time in 3 years.  Last time it wasn't like that.  Even FNV couldn't save changes to settings made via the in-game options.

Thank you for confirming what I believed, I have since tested a few times the problem now ..

@Utumno Every time Fallout New Vegas game Launcher runs ( FalloutNVLauncher.exe ) it sets the Fallout.ini ( in Documents \ My Games \ Fallout New Vegas \ ) back to the same settings as Fallout_Default.ini ( in Steam \ steamapps \ Common \ Fallout New Vegas \ ) - And then Write Protects it. This happens every time the New Vegas game loads.

@Bethesda Why?!

So 2 bad things :

1. As Malonn says even the game itself cannot save its settings changes

2. Every time the game launcher does that, by resetting the ini to default settings, it wipes the Registered ArchiveInvalidationInvalidated!.bsa entry from being in there, so Wrye Bash BSA Redirection will never work for Fallout New Vegas while this is the case, (because as soon as you launch the game with the launcher the ini goes back to defaults and gets locked again, even though the actual BSA may end up staying installed after someone has manually unlocked the ini file and let Wrye Bash do its thing .. It is not registered in the ini), and currently Wrye Bash every time you load it, and try to go to the Installers Tab after the game has locked the ini again, you get the same problem I have already posted a BashBugDump about on the previous page.

 

So I suppose the only fix for this is to manually unlock the ini, then use NVSE to launch the game and never use the New Vegas games official launcher. I wont be going as far as that though, I am only keeping the game installed long enough to maybe take a few screenshots for nexus pages and then I will be getting it and FO3 off my HD to free up space again.

Link to comment
Share on other sites

8 hours ago, Dubious said:

When you (or any program) creates a new folder, it inherits the access permissions and protections of the parent folder, back to the root folder of the partition/drive.  By default, Windows (since some unnoticed security update) gives these "read only" (RO) on new folders and files.  People are in the habit of just changing it on a given sub-folder or file, but not on the parent folder(s).  The next new folder inherits from the parent (which probably is inheriting from the "root folder") and it's "RO" again.  Along comes another security update, and the root defaults may get propagated down once again.  (More MS "big brotherism".)

When you change the folder properties, it's got an option that is supposed to allow you the propagate changed permissions and protections downward to sub-folder and files within the changed folder, but does not always seem to work correctly (at least in my experience on Win7SP1).  Double-checking after such a propagation I have still found folders which are "RO" until manually changed.  Even so, MS seems to reset folders to appear "RO" in Windows Explorer, though the file contents are left alone once changed.  "RO" on folders does not appear to act the same as on files, as you can still create new files within them.

-Dubious-

In the case of Fallout New Vegas, the game launcher is setting its ini to Read Only every time it launches. I have my Documents folder on my second partition (moved to that location), it is not RO. Within that all other sub-folders including My Games \ Fallout New Vegas \ are also not RO. This is on Win 10 x64.

Edit: Actually scratch that .. I think you are right, after reading your post I did find the Documents folder and all sub folders were RO, then I changed all of them, then I launched the Game launcher and it did what I expected - But I just checked again O_o all the folders above have gone back to being RO so it looks like you are right in this may be the cause of the problem ..

@MicroSoft WHY?!!! ffs.

Edit 2: But if that is the case, why are Oblivion / Fallout 3 / Skyrim / Skyrim SE / Fallout 4  .. Not affected the same way, their ini's all remain Writeable no matter what edits them.

Anyway up - Whatever the actual cause is, makes no difference, this is going to be a PITA for New Vegas and BSA Redirection not working when people thought they had it setup.

Link to comment
Share on other sites

I found things mostly the same as @alt3rn1ty.  Running the launcher and exiting makes no changes, but selecting anything from within the launcher set's Fallout.ini to RO and resets it.  You could modify fallout_default.ini to work around this--maybe back it up first?  I just don't use the launcher.

Link to comment
Share on other sites

@Utumno

Packages with the NVSE\Plugins\ directory only still are greyed.  Grey box, grey letters and most of the context menus items are greyed out as well.

Link to comment
Share on other sites

15 hours ago, Utumno said:

Thanks @alt3rn1ty and everyone else!


307.201803112048

Should address everything but the BP - alt could you link me to this? Then try deleting it and recreating one

This is the Bashed Patch created on installation by Wrye Bash 307.201803041642 - Installer https://www.dropbox.com/s/har60qbp8uf6pjf/Alt New Vegas Bashed Patch%2C 0.7z?dl=0

Deleting it and using the file menu to create a New Bashed Patch makes ones exactly the same as the other 

lZNJCnB.png

 

Try to Rebuild the newly created Bashed Patch for New vegas, in Debug mode it silently fails to build - BashBugDump.log ..

Wrye Bash starting
Using Wrye Bash Version 307.201803041642 (Standalone)
OS info: Windows-10-10.0.16299
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Fallout New Vegas\\Mopy\\Wrye Bash.exe', '--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:  Fallout3: e:\fallout 3
bush.pyo   82 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo   82 _supportedGames:  FalloutNV: D:\Steam\steamapps\common\Fallout New Vegas
bush.pyo   82 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   82 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   82 _supportedGames:  Skyrim: D:\Steam\steamapps\common\Skyrim
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to FalloutNV found in parent directory of Mopy:  D:\Steam\steamapps\common\Fallout New Vegas
bush.pyo  161 __setGame:  Using FalloutNV game: D:\Steam\steamapps\common\Fallout New Vegas
testing UAC
mods_metadata.pyo  229 __init__: Using LOOT API version: 0.12.0
Error in HonestHearts.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in FalloutNV.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in YUP - Base Game + All DLC.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in DeadMoney.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in OldWorldBlues.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in LonesomeRoad.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in FalloutNV.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in DeadMoney.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in HonestHearts.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in OldWorldBlues.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in LonesomeRoad.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in YUP - Base Game + All DLC.esm
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

Error in jsawyer.esp
parsers.pyo 4010 load:  
Traceback (most recent call last):
  File "bash\parsers.pyo", line 4004, in load
  File "bash\record_groups.pyo", line 83, in load
  File "bash\record_groups.pyo", line 1026, in loadData
NameError: global name 'bush' is not defined

brec.pyo 1803 getGMSTFid: Error loading bash\db\FalloutNV_ids.pkl:
Traceback (most recent call last):
  File "bash\brec.pyo", line 1799, in getGMSTFid
  File "bash\bolt.pyo", line 913, in open
IOError: [Errno 2] No such file or directory: u'D:\\Steam\\steamapps\\common\\Fallout New Vegas\\Mopy\\bash\\db\\bash\\db\\FalloutNV_ids.pkl'

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 205, in PatchExecute
  File "bash\patcher\patch_files.pyo", line 340, in buildPatch
  File "bash\patcher\patchers\multitweak_settings.pyo", line 238, in buildPatch
  File "bash\patcher\patchers\multitweak_settings.pyo", line 103, in buildPatch
  File "bash\brec.pyo", line 1799, in getGMSTFid
  File "bash\bolt.pyo", line 913, in open
IOError: [Errno 2] No such file or directory: u'D:\\Steam\\steamapps\\common\\Fallout New Vegas\\Mopy\\bash\\db\\bash\\db\\FalloutNV_ids.pkl'
 

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

I am now moving on to uninstalling this version of Wrye Bash for all games, and installing 307.201803112048

Link to comment
Share on other sites

And now with 307.201803112048 installed, the new installation generated Bashed Patch gives the "Unrecognised Plugin" warning ..

.. But Rebuilding the Bashed Patch is successful

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: ('en_GB', 'cp1252')
filesystem encoding: mbcs
command line: ['D:\\Steam\\steamapps\\common\\Fallout New Vegas\\Mopy\\Wrye Bash.exe', '--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:  Fallout3: e:\fallout 3
bush.pyo   82 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo   82 _supportedGames:  FalloutNV: D:\Steam\steamapps\common\Fallout New Vegas
bush.pyo   82 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   82 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   82 _supportedGames:  Skyrim: D:\Steam\steamapps\common\Skyrim
bush.pyo  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  146 _detectGames: Set game mode to FalloutNV found in parent directory of Mopy:  D:\Steam\steamapps\common\Fallout New Vegas
bush.pyo  161 __setGame:  Using FalloutNV game: D:\Steam\steamapps\common\Fallout New Vegas
testing UAC
mods_metadata.pyo  229 __init__: Using LOOT API version: 0.12.0

7ol3M4E.png

Link to comment
Share on other sites

Ahhh pinned it - but I still need @zilav's feedback - we set the patch form version semi-arbitrarily, not sure which version to use:

FNV

validHeaderVersions = (0.94, 1.32, 1.33, 1.34)

FO3

validHeaderVersions = (0.85, 0.94)

If you search the source for validHeaderVersions you will see some min(max) mumbo jumbo on setting the version on the patch (that probably has to do with the BP masters' header versions). Does this affect the record format ? If yes which one corresponds to the record format we use ?

 

EDIT: on creating a new mod the form version is hardcoded in the MreHeader class - we were using FO3's class that had the FO3 version hardcoded to 0.85:

class MreHeader(MreHeaderBase):
    """TES4 Record.  File header."""
    classType = 'TES4'

    #--Data elements
    melSet = MelSet(
        MelStruct('HEDR','f2I',('version',0.85),'numRecords',('nextObject',0xCE6)),
        MelBase('OFST','ofst_p',),  #--Obsolete?
        MelBase('DELE','dele_p',),  #--Obsolete?
        MelUnicode('CNAM','author',u'',512),
        MelUnicode('SNAM','description',u'',512),
        MreHeaderBase.MelMasterName('MAST','masters'),
        MelNull('DATA'), # 8 Bytes in Length
        MelFidList('ONAM','overrides'),
        MelBase('SCRN', 'scrn_p'),
        )
    __slots__ = MreHeaderBase.__slots__ + melSet.getSlotsUsed()
Link to comment
Share on other sites

Here's a bug report for Mr. @Utumno:

Oblivion.  Bashed Patch.  If a mod changes certain NPC's "Calc Min" setting to 1, when building the Bashed Patch, Bash sets their "Auto-Calc Stats" to on.  This shouldn't happen?(?)  The result is that certain NPCs effected by this are supposed to offer services but don't when the Bashed Patch does this.  The fix is to go into the mod that changes Calc Min to 1, and set it to 0, then rebuild the Patch.  Now, is this "normal"?  If one wants to change Calc Min to 1 (or anything else), one should be able to without Bash setting Auto-Calc Stats, right?  The following are the known NPCs that have Calc Min above 0 and get Auto-Calc Stats set by the Bashed Patch.  Not all of these people sell goods, so some of them have no impact in-game.  Others are supposed to sell stuff and don't have that option anymore after Bash sets Auto-Calc Stats.

  • Ungarion [0000A088]
  • Hauls-Ropes-Faster [0000A297]
  • Fithragaer [0000BEE6]
  • Dovyn Aren [0001605C]
  • Malintus Ancrus [000222A6]
  • Tumindil [00028F9D]
  • Ulmug gro-Cromgog [00028FA9]
  • Thaurron [0002D018]
  • Faelian [0002F875]
  • Alval Uvani [00030196]
  • Brodras [00034E72]
  • Gaspar Stegine [00034EB1]
  • Hafid Hollowleg [00035EB0]
  • Fallen Knight of Thorn [0003aa8d, 00071b94]
  • Gin-Wulm [0003E92D]
  • Dead Captive [00064c1d and 000651a7]

I am standing by for any further details that you may need.

Link to comment
Share on other sites

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

 


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-

Edited by Dubious
added "Re: The "FalloutNVLauncher.exe"" to the beginning.
Link to comment
Share on other sites

Is there a way to make the newer versions of Wrye Bash apply Bash Tags from the BOSS Masterlist? For Oblivion, BOSS still has a few that LOOT seems to be missing.

 

For example, the Knights Unofficial Patch benefits from the Relev tag to preserve its removal of the "Calculate from all levels <= player's level" flag from a leveled list for heavy boots. This tag is listed in the BOSS Masterlist, but not in LOOT's. At least currently.

 

I realise that LOOT is the future, and BOSS isn't necessarily always right—such as with its somewhat awkward sorting of the DLC plugins—but it would still be nice to have the option to read the tags.

Link to comment
Share on other sites

4 hours ago, Vrugdush said:

Is there a way to make the newer versions of Wrye Bash apply Bash Tags from the BOSS Masterlist? For Oblivion, BOSS still has a few that LOOT seems to be missing.

 

For example, the Knights Unofficial Patch benefits from the Relev tag to preserve its removal of the "Calculate from all levels <= player's level" flag from a leveled list for heavy boots. This tag is listed in the BOSS Masterlist, but not in LOOT's. At least currently.

 

I realise that LOOT is the future, and BOSS isn't necessarily always right—such as with its somewhat awkward sorting of the DLC plugins—but it would still be nice to have the option to read the tags.

Needs reporting in the LOOT topic, or on GitHub in the relevant masterlist issues - Those are the only place where LOOTs masterlist issues would be addressed (Best place would be github, for example the Oblivion Masterlist Issues, the forum topic posts may well get forgotten (imagine trawling through all those pages just trying to find extant requests for additions / changes), whereas on github the issue would always be pending being looked at by any contributer with time to maintain them, and close the issues).

In due course, Wrye Bash would eventually update its masterlist to sync with the LOOT ones .. The LOOT masterlist is going through a bit of an overhaul at the moment due to LOOT changing a bit of how it functions (Replacing Priorities with Groups, while still keeping Load After function - Read on from this post)

Link to comment
Share on other sites

Thanks for the reply, alt3rn1ty. Sure, it would be nice if the LOOT Masterlist was up to date, but what I was asking was, if there is still a way to make the latest Wrye Bash versions read from BOSS, until that happens.

Link to comment
Share on other sites

I think its no longer possible (someone correct me if I'm wrong). Wrye Bash now uses the LOOT API, and understands the format of the new masterlist.yaml file. Which means anything missing from the new masterlist.yaml file will need to be carried over from the old masterlists

Zpy6IZC.png

Link to comment
Share on other sites

OK, that's too bad, but as expected. I guess it was best in the long to run to excise BOSS completely. Thank you.

 

Unfortunately this means that end users who don't know how to add Bash Tags manually (or just can't be bothered) are more likely to miss out on some rule-of-one-circumventing goodness until LOOT's tag list catches up.

 

Sorry for going a bit off-topic, but most people frequenting this thread probably know a lot about LOOT as well, so I'll just ask: is there a way for LOOT to automatically extract the tags from the BOSS Masterlist and incorporate them into its own? Seems like a very dull task to perform manually.

 

Also, I noticed that the BOSS Masterlist (for Oblivion) was updated on Nexus, but mhahn123 had trouble getting it to update on GitHub, so if there is a way to extract the tags, using the list on Nexus seems prudent. Although I guess most additions are load order rather than tagging related, and would likely not matter much to LOOT.

 

That's enough rambling from me. Thanks again.

 

Link to comment
Share on other sites

As mentioned earlier, go to the LOOT topic, all questions for Contributing & Support, How to Contribute, Masterlist editing .. and a fair few other such related links start from the LOOT home page which is linked in the LOOT topic first post. Some documentation / links may change when the next documentation update happens (judging by how the latest developments are coming along in the thread that may be quite soon).

mhahn123 probably had trouble with the recent GitHub change to only supporting Web Protocol TLS 1.2, older protocols are no longer supported, so old communications methods between utilities and GitHub which have not been suitably changed to use the new encrypted protocol will fail, same as people who have not updated or received more recent updates to Windows will have issues too, mostly less supported OS like Windows 7 (and 8) users seem to have been hit the worst :

Quote

Windows 7 users must also ensure that they have enabled TLS 1.2 support to support updating the masterlists from LOOT's official repositories on GitHub.

Quote is from LOOT description on Nexus

I think Vortex (Nexus Mod Managers successor) also already supports the change at GitHub, and also natively supports LOOT API

Wrye Bash and LOOT have already been updated to support the change

Link to comment
Share on other sites

@Vrugdush No BOSS support except with older versions. Currently the only two working versions are Wrye Flash for FO3 and FNV which is useless because all BOSS masterlists are closed and cannot be changed with the exception of the Oblivion masterlist.

Would you please look at the header of the plugin. Does it have any bash tag suggestions in the plugin header? If not ask the author to add that please.  Wrye Bash takes the provided taglist included with Wrye Bash and only after looking at it calculates other sources. One source is the plugin header. If that is added then when very popular and maintained mods are released with the tag suggestions in the plugin header it won't matter whether or not the BOSS or LOOT masterlist is updated. In fact, if one installs Wrye Bash incorrectly by accident and the LOOT API (not LOOT itself) isn't installed, then Wrye Bash won't even have access to the LOOT masterlist in the first place.

In order to have full access you need LOOT installed and the LOOT API that comes with Wrye Bash. LOOT API is just a fancy way to say all the files needed for Wrye to access LOOT information.  I am not developing Wrye and wouldn't have the means to add BOSS support. It has been asked before and I don't remember the reasons why it's not added.  However, as I mentioned out of 6 games and 5 are closed to changes.  Naturally if anyone wants to volunteer to do a complete rewrite they can volunteer to write the Python code needed and submit it for approval. I know Utumno is always willing, but with scrutiny of course, to accept code provided if anyone is willing.

Link to comment
Share on other sites

Note to all - I will not be able to test all supported games anymore, I have reduced down to just Skyrim SE and Fallout 4, and uninstalled Oblivion / Fallout 3 / Fallout New Vegas completely .. Needed the space.

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