alt3rn1ty Posted March 10, 2018 Share Posted March 10, 2018 It should be bash, but nonetheless it looks funny when seeing that. @Leonardo Scroll down here until you find bush.py Link to comment Share on other sites More sharing options...
Malonn Posted March 10, 2018 Share Posted March 10, 2018 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 More sharing options...
Dubious Posted March 10, 2018 Share Posted March 10, 2018 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- Utumno 1 Link to comment Share on other sites More sharing options...
Malonn Posted March 11, 2018 Share Posted March 11, 2018 @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. Utumno 1 Link to comment Share on other sites More sharing options...
Sharlikran Posted March 11, 2018 Share Posted March 11, 2018 The line of code for SKSE is here. The same line for NVSE is here. The code will work the same. The # symbol is a comment so ignore that. Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 11, 2018 Share Posted March 11, 2018 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 More sharing options...
alt3rn1ty Posted March 11, 2018 Share Posted March 11, 2018 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 More sharing options...
Malonn Posted March 11, 2018 Share Posted March 11, 2018 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. alt3rn1ty 1 Link to comment Share on other sites More sharing options...
Utumno Posted March 11, 2018 Author Share Posted March 11, 2018 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 alt3rn1ty 1 Link to comment Share on other sites More sharing options...
Malonn Posted March 12, 2018 Share Posted March 12, 2018 @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 More sharing options...
alt3rn1ty Posted March 12, 2018 Share Posted March 12, 2018 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 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 More sharing options...
alt3rn1ty Posted March 12, 2018 Share Posted March 12, 2018 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 Utumno 1 Link to comment Share on other sites More sharing options...
Utumno Posted March 12, 2018 Author Share Posted March 12, 2018 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 More sharing options...
zilav Posted March 12, 2018 Share Posted March 12, 2018 Use the latest versions, 0.94 in FO3 and 1.34 in FNV Utumno 1 Link to comment Share on other sites More sharing options...
Malonn Posted March 13, 2018 Share Posted March 13, 2018 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 More sharing options...
Dubious Posted March 17, 2018 Share Posted March 17, 2018 (edited) 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 March 17, 2018 by Dubious added "Re: The "FalloutNVLauncher.exe"" to the beginning. Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 22, 2018 Share Posted March 22, 2018 @Utumno If you ever need to look inside any game BSAs for any supported games, Zilav has released a new command line tool BSArch Link to comment Share on other sites More sharing options...
Vrugdush Posted March 27, 2018 Share Posted March 27, 2018 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. alt3rn1ty 1 Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 27, 2018 Share Posted March 27, 2018 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 More sharing options...
Vrugdush Posted March 27, 2018 Share Posted March 27, 2018 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 More sharing options...
alt3rn1ty Posted March 27, 2018 Share Posted March 27, 2018 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 Link to comment Share on other sites More sharing options...
Vrugdush Posted March 27, 2018 Share Posted March 27, 2018 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 More sharing options...
alt3rn1ty Posted March 27, 2018 Share Posted March 27, 2018 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 More sharing options...
Sharlikran Posted April 1, 2018 Share Posted April 1, 2018 @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 More sharing options...
alt3rn1ty Posted April 1, 2018 Share Posted April 1, 2018 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. lmstearn 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now