Jump to content

Vrugdush

Members
  • Content Count

    16
  • Joined

  • Last visited

About Vrugdush

  • Rank
    Clanfriend

Profile Information

  • Gender
    Male
  • Location
    : Sweden

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Vrugdush

    Wrye Bash - All Games

    @Utumno A few times now I've had an error when trying to rebuild the Bashed Patch in Python mode, and the rebuild fails. After restarting Wrye Bash, I've been able to rebuild the Patch without error. Here's the latest message: I'm using the Wrye Bash v307.201804202117 Python installer version on Win 10 Pro x64 (Swedish). Unfortunately I wasn't able to reproduce the error while running in debug mode. Still, here's my BashBugDump.log: And here's my Bash.ini (The 7z compression arguments seem to work fine for me, by the way. Was the issue @RavenMind reported on back in October fixed, or am I just lucky?): EDIT: The error happened again, and I managed to reproduce it in Debug mode this time. It only happens after first building one Bashed Patch in C mode, and then switching to a different Bashed Patch and rebuilding that one in Python mode. If I start with the Python Patch, it rebuilds fine without any error messages. A few mods have been removed since last building the Python Patch, so it is missing masters before rebuild. Possibly the "Magic: Script Effect Silencer" Assorted Tweak was removed in-between rebuilds as well. Here's the (new) Bashed Patch configuration for the Python mode one: And here's the new BashBugDump.log for Debug mode:
  2. Vrugdush

    Wrye Bash - All Games

    Right, here are the questions about Tags and Patcher logic that I've been warning you about. :-) Is there a Bash Tag that can handle NPC and Creature Record Flags? I noticed that there is one for Cells. It would be handy for resolving conflicts such as this one: It seems like the Relev Tag is needed if a plugin changes the "Calculate from all level <= player's level" flag, even if there are no later-loading conflicting plugins. Is this indented behaviour for the Leveled Lists Patcher? From reading the documentation, I would assume yes, but it's not explicitly stated. Since even the UOP team seems to have overlooked this, maybe the documentation needs amending? Some questions and comments regarding the SpellStats Tag. Is there a reason it doesn't include the Effects subrecord? It seems a bit counter-intuitive. Effects is not listed in the included subrecords in the documentation, of course, but it might be a good idea to explicitly state that it's NOT included. Also, is it intended for a plugin with the SpellStats Tag to always trump one with the Names Tag when they conflict? This seems to happen regardless of relative load order and even if the Names plugin is merged and the SpellStats one just imported. I suppose this makes sense, since Names affects many record types and SpellStats is more specific. Still, another one for the docs, maybe? This one is more of a request. It would be nice if the Graphics Patcher also included the "ICON - Icon filename" subrecord for Quests, like it does for other record types, since there are mods that change quest icons now. Patching it manually just feels wrong when Wrye Bash exists. :-) That's it for now. Thanks in advance to anyone who takes the time to read my ramblings.
  3. Vrugdush

    Wrye Bash - All Games

    I will endeavour to do so, @Utumno, but it might take a while, since I've never used GitHub before. I have some research to do. Also, I can confirm that the BOSS GUI toggle bug is now fixed. Thanks! By the way, you say there's no one working on CBash, but is work possible on the Python versions of the Bash patchers? I might have some enhancement requests. :-) ...and if that's not possible, I might have a question or two about what the intended results of some of the patchers are. Would anyone here be familiar enough with the patcher logic to be able to answer that?
  4. Vrugdush

    Wrye Bash - All Games

    @Utumno Bug report followup on the Auto-calc stats issue reported by OOO users via Malonn, which I will henceforth call the CBash Actors.ACBS bug: TL;DR: When one plugin changes an NPCs "Calc min" value, and another plugin conflicts, CBash produces unexpected results. Depending on Tags and the relative load order of the two plugins, CBash sometimes erroneously adds the "Can Corpse Check" flag to the NPC, and sometimes the "Auto-calc stats" flag. 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 an NPC to change its "Calc min" value. Another, later-loading one, modifies the NPC's face. The first one is Tagged with Actors.ACBS, and the second with NpcFaces. 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, Import Actors, and Import NPC Faces need to be ticked in the Bashed Patch configuration window. Make sure the test plugins are ticked wherever possible under these headings. Compare the results in TES4Edit. PBash gives the expected merging of the records; the NPC gets both the ACBS change and the new face. CBash also gives a merging of the records, but decides to add some unwanted sprinkles on top, in the form of the "Auto-calc stats" flag. The error doesn't happen if the relative load order of the two conflicting plugins is changed, i.e. if the Actors.ACBS-Tagged plugin is loaded after the other one. In that case CBash produces the same, correct, result as PBash. Now, if you add the NoMerge Tag to the face-changing plugin PBash and CBash both produce the same, correct result. Also, in this case the relative load order of the two plugins doesn't matter. However, when you instead add NoMerge to the Calc min-changing plugin, you get a different, but also unexpected, result: PBash is once again correct. CBash again merges the records properly, but this time decides to mix things up by erroneously adding the "Can corpse check" flag to the NPC. Oh dear. Result is the same when the relative load order of the two plugins is reversed. Now for the really interesting result; if both plugins are Tagged with NoMerge we get... Drumroll!: PBash is once again correct. Surprise! CBash decides one bug isn't enough, and decides to call in reinforcements from what seems to be our old friend the "CBash does not import Face Data" bug, also known as Bug #216 on SourceForge, for a double bug bonanza! Not only does it add the "Can Corpse Check" flag, but it also doesn't merge the face changes. Result is the same when the relative load order of the two plugins is reversed. So there you have it. CBash has some problems with Actors.ACBS changes, and with importing NPC faces. Tested with the "wrye-bash-150-fo3-fnv-support" branch on Windows 10 Pro x64. Bashbugdump.log: Auto calc stats Test Plugin 1 - NPC Calc min Change Made with TES4Edit.esp Auto calc stats Test Plugin 2 - Conflicting Later-Loading Plugin.esp
  5. Vrugdush

    Wrye Bash - All Games

    @Malonn in regard to Auto calc stats. I've conducted some tests, and this bug seems to only happen with CBash, under certain conditions. Before I get to that though, I have a question: why does OOO change the "Calc min" setting but not turn "PC Level Offset" on? My understanding is, and please correct me if I'm wrong, that without PC Level Offset toggled on, Calc min does nothing? In the Construction Set, you'll notice that the Calc min field is in fact greyed out and its value can't be changed unless PC Level Offset is toggled on. Toggling it on changes the Level field to the Level offset field, and turns the NPC from a static level to dynamically leveling with the player. Also,"Auto calc stats" is automatically turned on whenever PC Level Offset is. You can have Auto calc stats without PC Level Offset, but you can't have PC Level Offset without Auto calc stats. This, in conjunction with the fact that vendor AI doesn't work with Auto calc stats on, creates a game engine limitation that means that any vendor NPCs must be a static level to be able to provide services. Unless of course there's some clever script workaround. Maybe these Calc min changes in OOO are a case of using TES4Edit to input invalid data? With the CS, this change would require first toggling PC Level Offset on, changing the Calc min field, and then turning PC Level offset and Auto calc stats off again, making the Calc min change moot, but messing up your NPCs other stats because the Auto calc toggle doesn't revert the stats to the old values when toggled off. In other words, the futility of this kind of change would hardly go unnoticed when using the CS. I checked the older versions of OOO, and found that it went as least as far back as v1.32 from 2008. It just hasn't caused any problems until CBash though, which is probably why it has gone unnoticed. Right, back to the test procedure: I looked at the OOO plugins, since I believe that's where the bug report originated, and copied OOO's "Calc min" changes to Ungarion to new plugin in TES4Edit, and tagged it with Actors.ACBS. I then made a new, conflicting plugin, changing Ungarion's looks, and tagged that with NpcFaces. I could then replicate the problem with the Bashed Patch adding Auto calc stats, but it only happens with CBash, and only when the conflicting plugin is loaded after the Actors.ACBS one. PBash is fine, so tell your users to use that instead, for this purpose. Full report follows in new post, for clarity.
  6. Vrugdush

    Wrye Bash - All Games

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

    Wrye Bash - All Games

    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: 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
  8. Continuing with my Bash Tag suggestions from the UODP thread, here are some for USIP. These aren't as essential as the Knights one, since these deal with conflicts, and that one was necessary even with no other conflicting mods loaded. Regardless, I think these Tags are more likely to help than hurt. I've checked against a few popular mods, and these are the Tags I'd recommend: Add Actors.Skeleton to preserve changes from beast to regular skeleton for Dumag gro-Bonk (conflicts with Oblivion Uncut), and a few other NPCs (didn't notice conflicts with these yet, but there might be some, even if there are few mods altering SI). Corresponds to the change log entry "Corrected four NPC's (Dulphumph gro-Urgash, Dumag gro-Bonk, Erver Devani and Una Armina) using the wrong skeleton mesh (SkeletonBeast.NIF instead of Skeleton.NIF); did not cause any known problems but may as well fix it so that future clothing/armor replacer mods don't cause them to grow a tail". Add Actors.Spells to preserve changes to Mended Flesh Atronach spells (conflicts with Cobl Tweaks - SI, which adds new death items). I can't find this particular change in the log, but it seems like you've changed the two kinds of level 5 Flesh Atronachs to use the level 5 spells specifically created for them, which previously went unused. Maybe while you changed the summoned versions to remove the No Low Level Processing flag, although I can't find that in the change log either... Anyway, this isn't a huge deal, since the level 5 Atronachs are rare—the Boss version seems to only be used in one location, and one of the spells is even identical between the level 4 and 5 versions—but a bug is a bug, and the fix should be preserved. :-) Add C.Music to preserve changes to music in several locations (conflicts with Cobl SI, which places objects in these cells). Corresponds to the lines "Correct the music in Bliss, Crucible, the Palace District, Mania Garden and Dementia Garden, now set to public (town) and not default (wilderness)." and "Corrected several houses across the Isles and the Mania and Dementia gardens using the “default” music type rather than the correct “public” music type." in the change log. There are probably more that could be useful, but I've only just returned to the game, so my load order is still small, and these are the ones I've found so far. Toodles for now. I'll probably be back with a few suggestions for the UOP as well.
  9. Hi! I have a Bash Tag suggestion if there's ever an update. Add Relev to "Knights - Unofficial Patch.esp" to preserve the removal of the "Calculate from all levels <= player's level" flag from the "NDLL0ArmorHeavyBoots" Leveled Item list. The removal of this flag seems to correspond to the line " Fixed the leveling on the heavy Boots of the Crusader so that the player always receives the correct version for their level both from the quest and the armor stand at the Priory (instead of possibly a lower-level version)" in the change log. Wrye Bash includes this leveled list with the flag in place in the Bashed Patch even if the only mods containing the list are "Knights.esp" and "Knights - Unofficial Patch.esp". Basically, unless Relev is in place, the change is reverted even if there are no conflicting mods. From reading the Bash Tag documentation, I gather that this is probably intended behaviour. Just in case you're curious, "Knights.esp" itself does not have the Relev tag. Tested with both CBash and PBash in Wrye Bash v307.201803112048 Standalone on a load order with just the official DLC and their respective patches in place. See the attached image for the PBash result. The BOSS Masterlist has this Tag suggestion in place already, but it's not yet in the LOOT one. Regardless, having the Relev Tag in the file header seems prudent. Thanks for your time.
  10. Vrugdush

    Wrye Bash - All Games

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

    Wrye Bash - All Games

    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!
  12. Vrugdush

    [RELz] LOOT - Load Order Optimisation Tool

    OK. Thank you for setting my mind at ease.
  13. Vrugdush

    [RELz] LOOT - Load Order Optimisation Tool

    This is probably low on the list of priorities now, with all that's going on with groups, but I noticed that the BOSS Masterlist for Oblivion has Bash Tag recommendations that the LOOT Masterlist is missing. Do you have a way to automatically extract the newly added Tags from BOSS for easier inclusion in LOOT? Seems like dull work to do manually. I suppose one way to do it would be to compare a really old BOSS Masterlist, from when it was first converted to LOOT, to the newest one, and check for any Tag changes. There might not even be that many. It's just that the one I noticed was for the Knights - Unofficial Patch, and so is likely to affect a lot of players. With the newer version of Wrye Bash no longer reading Tags from BOSS, LOOT incorporating these Tags could be helpful to those Oblivion players who don't add Tags manually. Thanks for your time, and good luck with the groups implementation. It seems quite useful.
  14. Vrugdush

    Wrye Bash - All Games

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

    Wrye Bash - All Games

    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.

Support us on Patreon!

×