Jump to content

Dubious

Members
  • Content Count

    33
  • Joined

  • Last visited

  1. Dubious

    Wrye Bash - All Games

    @Ganda: Thought it was probably you. Actually think that was a good choice for testing, for exactly the reasons you gave. Just wanted to be sure the results were as expected. I'm on there daily, so feel free to contact me directly if you need some test verification.
  2. Dubious

    Wrye Bash - All Games

    FYI: I saw notifications about Wrye Bash 307 being updated in the Nexus "Fallout New Vegas mods" page by someone whose name began with "Ganda" a couple of day ago. However, the download "files" page still does not have any files more recent than 04 Jul 2018, and the version information indicates it is 307Beta3. So it doesn't look like the update (if there was one) "took" in that location.
  3. Dubious

    Wrye Bash - All Games

    @acidblood719: That's a start, but he needs more info to figure things out (including which game you are attempting to use). Please see the "Reporting bugs" section in the first post of this thread. -Dubious-
  4. Dubious

    Wrye Bash - All Games

    I'm not having that problem with WinSnip and the 307.201807251609 version for FO3 and FNV on Win7. -Dubious-
  5. Dubious

    [RELz] LOOT - Load Order Optimisation Tool

    Re: LOOT Groups. Sorry for the delayed response. I had to step back and think over your questions, and check some of my initial assumptions. One is that I have only been using LOOT with games that use the "Gamebryo" engine (Oblivion and Fallout New Vegas). That has afforded me the luxury of ignoring the difficulties Skyrim and other "Creation Engine" games have brought to LOOT's table. So, while the basics are still there I needed to re-learn how those differences impacted LOOT by reading the "Introduction to Load Orders" article. (Nice article on the differences. Doesn't seem to be linked into the "Application Documentation" though.) However, the topic of how "Masterlist Groups" are applied is not covered (or I failed to find it) in the "Application Documentation". Without attempting to dig into either the code or the instructions for maintaining the "masterlist", the "abstract picture" I perceived from the existing documentation runs as follows: 1. Plugins are loaded in current "load order" (meaning in date/time stamp sequence for Gamebryo engine games). 2. Master/dependency relationships are determined from the plugin headers. 3. Game and DLC masters are sorted to the top (lowest mod index) positions in dependency order. 3a. Where dependency of "master" files is not related, they ''probably'' remain in timestamp or original load order. 4. Other "masters" are sorted to follow the "DLCs". 5. Probably the "dependencies" are then allowed to remain in the orginal load order sequence as they were encountered. 6. "Masterlist" groups are applied to both "masters" and "dependents". (How is not explained. The following are suppositions.) 6a. Presumably the "Master" mod-index position ordering relative to other "masters" is maintained. 6b. Dependents are checked to determine they do not violate other "master-dependent" relationships and then "masterlist groups" use their meta-data criteria (e.g. "load after") to place them after their "master" within the placement for that "masterlist group. 6c. Where there is no meta-data affecting their sequence, the master files remain in load order sequence. 6d. "Masterlist groups" follow the hierarchy of the "daisy-chain" links shown in the "Edit Groups" diagram. (How this is applied is not known to me, and generally not considered important for user understanding. It is only with the introduction of "user defined groups" (UDGs) that it appears to matter.) These "masterlist groups" are generally categorized as "early", "mid", and "late" loading groups, with "default" group apparently determining the "mid" point. 7. All plugins which do not fall into any other "masterlist group" are placed in the "default" group in the sequence they appear in the load order after sorting for "master-dependency" relationships. It was stated on the forum that "all plugins must belong to a group", which had been an unspoken assumption in the "Editing Plugin Groups" documentation which should be added and emphasized. The "default" group is in the "mid" category of "masterlist groups". 8. Where needed, date/time stamps or "plugins.txt" files are updated. The old "priorities" system appeared to have been a way of imposing a "secondary hierarchy" on the "default" group of plugins. (This may have been another point where the "abstract picture" breaks down. If the older priorities could override the "masterlist groups", I never tried to discovered it as I only used it with what appears to now be called the "Dynamic Patches" group: e.g. "TES5Merged Patch", "Bashed Patch", and "Override Patch" files to force them to load last in the correct order.) Following the "rule of one" principle I have developed the habit of adding new plugins to my load order as near the top (low mod-index) as seemed practical (e.g. just below "unofficial patches"), and letting LOOT sort them down to the highest necessary override position as a solution to the "every author wants to load their plugin last so it wins" problem. I've learned I can safely make some adjustments to the sorted sequence as long as I respect LOOT insisting that certain plugins follow others. This permitted me to "group" plugins in contiguous sequence which could then be combined into a "merge plugin". But it often meant that I had to split some logical groupings into more than one sub-group in order to respect LOOT's insistence. (For example, I have four "Fixes" merged plugins for that very reason: LOOT wouldn't let them sit together. One of them has combined 20 individual plugins.) It initially appeared to me that the addition of UDGs were adding a "secondary" level of grouping to plugins within the "default" group, OR for inserting UDGs into the "masterlist group" "daisy-chain" sequence. But the experimental evidence is that UDGs have the same level of "priority" as "masterlist groups". They are "primary" level hierarchy instead of "secondary". If UDGs (even those consisting of a single "master" file) are added to the "default" group without hierarchy (no daisy-chain but simply "spurred" off the "default" group as "green circle" nodes), then they get moved to the bottom of the "default" group as "overrides" without regard for whether or not their master had previously preceded others in the "default" group; which was not the intent. If they are "daisy-chained", then they become separate "masterlist" level groups following the "Default" group. I can now see why it was implemented that way, but the documents don't make that clear. The problem is apparently that a UDG is not merely a "grouping" of related mods (as implied in the "Editing Plugin Groups" documentation), but also a hierarchical change to the "masterlist" without the same rigor and rationale as that used by the masterlist maintainers. It appears my mistake is somewhere along the line I got the impression it was a "secondary" rather than "primary" grouping: e.g. sub-groups within the "default" group. My intent had been to "pull-up" dependents somewhat randomly placed lower due to the date/time stamp on the original file to immediately follow the "primary" merged plugin file of the group. Now my concern is that "user defined grouping" plugins may be overriding the sorted hierarchy without regard for the "master" relationship with plugins outside of the UDG, with the UDG automatically becoming the arbitrary "winner". If it doesn't matter, that is one thing. But automatically making UDGs the override winners seems to be going back to the "everyone wants to be last" problem. I foresee problems with making UDGs the equivalent of "masterlist groups". That sort of thing should be requested of the LOOT maintainers so it gets the proper consideration. Most users don't understand the issues. Going by my own experience, I don't want that capability. I want the ability to define sub-groups within the catch-all "default" masterlist group to keep together specific sequences of plugins that can usually be re-positioned within limits without attempting to override other plugins. I don't want to have to define UDGs of unrelated plugins just so I can daisy-chain the other plugins in the "default" group (attempting to leave it empty) around my "merge plugin" UDGs. I think UDGs are a great idea, but not at the same level as the "masterlist groups". Better as sub-groups of masterlist groups. -Dubious-
  6. Dubious

    [RELz] LOOT - Load Order Optimisation Tool

    Seeking some clarification as to how LOOT "groups" work even after reading the documentation. I've built a number of "merged plugins" for "Fallout New Vegas": being careful to maintain both the ordering of LOOT's sort and the needed contiguous nature of the files to be merged. These "merged plugins" have been mixed in among other individual files in the sorted load order and function just fine. "Groups" seemed like a natural way to ensure those contiguous collections of plugins that made up the "merged plugin" would remain placed together when it becomes necessary to rebuild the merge. So I created a "group" for and added the single existing "merged plugin" file to that group. (Later I added the individual plugins that make up the merged file to the same group, but the problems started before then.) Now here is where I get confused. At first I added the new "merged plugin group" into the chain of "masterlist groups" just after the "default" group (as it normally sorted just after the "YUP Gameplay Tweaks" group, the last "masterlist group" before "default"). Normally (without assigning any new group) it had a couple of other "default" plugins preceding it. But immediately upon assigning the plugin to that new group, it changed position in the load order. The only difference was the creation of the group and inserting it into the descent chain of groups. (Not clear to me what the "Dynamic Patches" group refers to. Various forms of "merge patch files"? It would help the documentation if the "masterlist groups" were explained. I realize these groups seem to vary by game, but that just suggests their explanation needs to be "included" in the help file once the specific game has been identified.) So I removed that group from the chain between "YUP" and the "default" groups, and just connected the "default" group to the "merged plugin" group (green circle). I was expecting it to return to it's previous location in the sort order, but instead that causes the group to appear at the bottom of the load order; below the "LOD" group. I tried various other experiments and the results seem to be that adding a plugin to a group immediately causes that plugin's normal position in the load order to be ignored, and the group position in the chain to override. If not daisy-chained, but simply "spurred" off of "defaults" (green circle) the groups get sorted to the bottom of the load order below any other "default" (ungrouped) plugins, and not even in the same order relative to their position in the load order as individual files. Even "daisy-chains" seem to ignore the intervening placement of single plugins. I'm still assuming the "ungrouped" sorting should prevail first. The individual plugins that were interspersed among the "merged plugin" files still need to be loading prior where that occurs. The assignment to a "group" seems to break those priorities. Also noticed that you can't simply remove a group entry from a plugin in the metadata. Apparently you have to clear the entire metadata for that plugin and start over. -Dubious-
  7. Dubious

    LOOT Groups

    Moved as post under the [Relz] LOOT thread. -Dubious-
  8. Dubious

    Wrye Bash - All Games

    Okay. Added the script as a new wiki page and linked it in the "migration guide". Seems to be working. -Dubious-
  9. Dubious

    Wrye Bash - All Games

    Out of my comfort zone here. Clone/repo the wiki? Why not just add a "new" wiki page (in which case: should it be given a "[dev]" or other tag on the title line)? Hate to waste your time on such basic matters, so if you can point me to the appropriate docs on how the wiki is organized I should be able to figure it out from there. -Dubious-
  10. Dubious

    Wrye Bash - All Games

    Just posted the "migration guide", but it hasn't shown up on the WB Wiki "Home" page as yet. My first post to the GitHub wiki, so I probably made a mistake. I wrote and mentioned a script file (WFProfile.cmd) for helping a migrator to manage backups of the different version files. However, have no idea where to post it and how to link to that location. It's too long (44KB) to post in that article (though easy to customize). Suggestions? @Sharlikran: We cross-posted, so I will update the migration guide with that info. Thanks. -Dubious-
  11. Dubious

    Wrye Bash - All Games

    I've not been able to re-produce that traceback from the same settings files. No initialization problem with current WB307 at all with the old settings. (The window had to be resized, so it was using the old settings.) I guess we chalk it up to an extreme edge case. I have found that the deletion of the backup settings archive file includes ALL 7z files in that folder containing the word "settings" when 307.201805122101 closes. (So much for my personal theory of an open file handle.) I copied a 7z file with the settings for the traceback attempt into the same folder, and it was deleted along with the backup file. Haven't tried with archives not containing the name "settings" as that shouldn't matter anyway. I'm using 7Zip 1805. -Dubious-
  12. Dubious

    Wrye Bash - All Games

    Test using "wrye-bash-150-fo3-fnv-support_20180512_2101" (WB307) against Fallout New Vegas on Win7SP1. Backup of settings to "Bash Mod Data\Backups" as "Backup Bash Settings FalloutNV (2018-05-31 03.07.34) v43-307.201805122101.7z". File is deleted upon closing WB307. BashBugDump.log This time there was no problem using my modified version of the "bash.ini" file (with additional comments), or with switching between WB307 and WF17 using the same settings files. -Dubious-
  13. Dubious

    [WIPz] TES5Edit

    Thanks. That was it. I needed to refine my definition of "unique" records to "any with the same mod index as the plugin being merged up", instead of only those with a "white background". -Dubious-
  14. Dubious

    [WIPz] TES5Edit

    Using TES5Edit 3.2.2 on Win7SP1. "Merging up" a couple of "optional patch files" into the main "Fallout New Vegas" plugin (WeaponModsExpanded). After adding 'masters' preceeding the main plugin as masters to it (and repeating for each of the patches), injecting unique records from the patch files, and selecting all sub-records for "copy as override" into the main plugin and selecting that file as the target, get the error message with the first plugin to be copied (WMX-DLCMerged) as follows: 'The required master "WMX-DLCMerged.esp" can not be added to "WeaponModsExpanded.esp" as it has a higher load order.' -Dubious-
  15. Dubious

    Wrye Bash - All Games

    Test using "wrye-bash-150-fo3-fnv-support_20180420_2117" (WB307) against Fallout New Vegas on Win7SP1. Whenever switching from WF17 to WB307 (regardless of how many times this has previously occurred), it detects a "different version of WB" settings were previously used and offers to save them. Closing WB307 causes the settings file which was backed up to be deleted from the save location. This is not so much of a problem as the settings from WB307 seem to be acceptable to WF17 (other than ignoring the "order" in both "Mods" or "Installers" tabs), but sort of defeats the entire purpose of creating a backup. I only happened to determine this was a "feature" of WB307 because I had the folder open to confirm the file was actually created and saw it deleted upon closing WB. Suggested improvement would be to prompt for the backup only if there were no files matching that WB version present in the destination folder, and leave it for the user to clean out older "date/time stamp versions". This is only going to be an issue until the patcher gets updated for FO3/FNV, negating the need to switch back and forth between versions of WB, but that may take awhile. -Dubious-

Support us on Patreon!

×