Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Infernio

  1. @Nephenee13 That's the big known issue with FOMODs. If BAIN doesn't recognize a valid folder structure, it can't get to the stage of looking for an FOMOD ModuleConfig. This will require a lot of BAIN refactoring (namely, making it recognise a new category of 'scattered' packages that have no sensible folder structure and can *only* be installed via a guided process like an FOMOD) and is not feasible at the moment. The workaround is to place a dummy ESP (or a valid top-level folder) next the 'fomod' folder so that BAIN thinks this is a valid package and discovers the ModuleConfig, then using the FOMOD installer. I added Nemesis_Engine as a known top-level directory, so this will hopefully be fixed in the next nightly. Until then, the same workaround as above should work here too: add a dummy ESP or a valid top-level directory to help BAIN figure out where the root of the package actually is.
  2. @Nephenee13 Will be in the next nightly.
  3. @supakimbop That's not the full traceback. Please make a bashbugdump: https://github.com/wrye-bash/wrye-bash/wiki/[github]-Reporting-a-bug#the-bashbugdumplog and upload it here.
  4. @Malonn That's technically a feature, not a bug. See https://wrye-bash.github.io/docs/Wrye Bash Advanced Readme.html#bain-skipped: That said, this is the second time this has come up and the original reasoning for skipping these seems arcane (something to do with 'injected NMM files'), so I removed this skip in the newest py3 nightly build.
  5. @Nephenee13 To add bash tags manually, use the plus button: As for the tag, BOD2 is handled by the Graphics tag. You can find that in the advanced readme: https://wrye-bash.github.io/docs/Wrye Bash Advanced Readme.html#GraphicsSkyrim
  6. @Nephenee13 Those are plugins that have a form version lower than 44. That means they haven't been converted for SSE yet (or were converted incorrectly). Check if there are SSE versions for those plugins, or port them yourself:
  7. The dot means that some of the data from the plugin has been imported into the BP. Most plugins have to be active in addition to having data imported (precisely because not all data will be imported - only what's actually necessary to resolve conflicts), but there are a few types of plugins that should not be activated in addition to being imported. These usually have the Deactivate and Filter tags and WB will warn you if you've enabled one of them by coloring them with a bright red background. In case of doubt, check the mod page to see if the mod author recommends anything.
  8. Interesting. I don't see why it would completely skip it with Form Version < 44, but at least it's working now. That's an experimental feature, currently only available in the 4.1.x builds on the xEdit discord.
  9. Tried it, it's merging the three of them fine for me (with or without the JSW/IW patch installed): Edit: this was with the latest nightly version (310.202108101023), so if you were using 309.1, maybe try that? Edit 2: the screenshot above is in SSE, I converted the plugin to FormID 44 before doing this.
  10. Thanks! I'll have a closer look at this tomorrow.
  11. Okay, I tried reproducing this. With the patch included in the JaySUS Swords download installed, the BP correctly does nothing (since the patch already resolves all the conflicts). Without that patch installed, the BP properly resolves the conflicts (including LItemWeaponSword, the one in your screenshot). I guess it could be because of your plugin being in the middle. Could you share that plugin?
  12. Wrye Bash doesn't include leveled list records in the Bashed Patch unless it actually had to merge the contents because of a conflict (i.e. two plugins modifying the same leveled list). And if it didn't need to include any data from a plugin in the BP, it won't add that plugin as a master either. Do the leveled lists that it does not touch actually need merging? If so, please make sure your LOOT masterlist is up to date (so that you have the right tags) and take an SSEEdit screenshot of the unresolved leveled list conflict.
  13. You can still use BOSS for sorting, just make sure you also have LOOT installed and its masterlist is up to date so that Wrye Bash can get the right cleaning info and bash tags.
  14. @HelloBengbeng17 Wrye Bash relies on LOOT for cleaning info and has some limited capacity to scan plugins beyond that. So make sure you have the latest version of Wrye Bash (309.1) and that your LOOT masterlist is up to date.
  15. @judge0 Use the '-o' argument. For example, if you have a game installed at 'G:\steam\steamapps\common\Oblivion', pass -o "G:\steam\steamapps\common\Oblivion" as an argument to WB in the Oblivion MO2 instance.
  16. Yeah, that'll make WB think you're managing Oblivion since that's the file it uses as a heuristic to figure out if the current game is Oblivion.
  17. @theQuestionmark That should be fixed in the newest nightly build (link is in the second post in this thread).
  18. @Wolfstorm I assume you're the same Wolfstorm that sibir answered on Discord? That answer stands - changing the extension requires a new game, adding or removing the flag does not.
  19. There is no way to do that right now. Feature additions will have to wait for a while since we're in the middle of a major transition (Python 3).
  20. Hmm, it still shouldn't have crashed on that. I'll take a look, but might have to shelve that until after Python 3.
  21. That was back in 2015. xEdit has had numerous updates since then, most notably the introduction of Quick Auto Cleaning (QAC). We've checked that cleaning report, and it is legitimate - those are all new ITMs found by QAC, the older dialogue ITMs are not detected as ITMs by recent xEdit versions. Inigo hasn't had an update since QAC came out, so it has obviously never been cleaned with QAC - hence these ITMs.
  22. Wrye Bash 308 is a 64bit application. The original Mod Organizer can't handle 64bit applications. You can try downloading 307 and using that: https://github.com/wrye-bash/wrye-bash/releases/tag/v307 Also, Wrye Bash has a dedicated thread here:
  23. Wrye Bash reads the header of each save to retrieve information like player name, current location, masters, etc. If you have tons of saves, it could be that Windows is trying to shove them all into its RAM cache, filling up its cache due to the sheer size of all those saves, and then clearing it out and filling it again over and over. You can also try moving them into a profile (i.e. a subfolder of the Saves folder) if you want to keep them. That should make WB ignore them, unless you switch to that profile form within WB.
  24. I don't have much to add. Try the development build and see if that helps. If not, check your save folder - keeping thousands of saves around can slow WB down quite a bit.
  25. @TruCorsair Your version of Wrye Bash is very out of date. Download 308 from the Nexus.
  • Create New...