Mertz

The best way I've been able to explain it to folks is Skypatcher is to Skyrim what Dehacked is to DOOM. Conflicts still occur. If multiple Skypatcher mods modify the same records the conflict is resolved by alphabetical order.

Correct. Wrye was very concerned about installing binary executables (.exe files) into the game's data folders and that restriction carried over through about 60 updates to the present day. There is a discussion about removing it so this might not even be a thing by the end of 2024. If that happens you can install tools like any other mod and they'll be bit-level hashed and tracked like any other mod. Pandora dumps everything into the Data folder. Monitor144hz has technical reasons for doing this, mainly to work around some broken mods. You'll have to manually unzip the archive into the Data folder, make a shortcut, then copy that shortcut into your \Mopy\apps folder.f

Thanks @sheson the --speed switch sounds like just what I need. Much appreciated

Hey @sheson I have a question that's kind of the opposite of the usual: I have a 7800X3D and 64GB of RAM and a 24GB graphics card. Data folder is on a PCie 4x4 drive and DynDOLOD is running on a different PCIe 4x4 drive. Is it possible to tune DynDOLOD to use more cores/RAM to process faster? Edit: it isn't slow and usually finishes in under 15 minutes.

If Wrye Bash crashes it should write a Bash Debug log in the Skyrim Special Edition\Mopy\ folder where you have it installed. If you can see an obvious cause in the log then that should guide you to what might be going on. If you can't make any sense of it reach out to the WB team on the Wrye Bash Discord or the official forum post on AFKMods

Always use the latest Wrye Bash release on NexusMods. As of this writing this is v310 with v311 scheduled for release later in 2023.

WB 310 or greater no longer merges plugins for Skyrim SE/AE or Fallout 4. It can do ESL flagging but you should know what you can and can't add the ESL flag to before using it. If you're in doubt about a candidate plugin. toss the plugin into xEdit and check it with the ESL tools and scripts there.

Understood. I'll revisit the documentation again and see what I need to do in order to capture a better debug log for you if I can reproduce the issue. See below. I ran several tests this morning with both RenderDoc and the AMD GPU profiler running to try to capture the OpenGL compute shader that is executing when the bugcheck occurs. I was going to submit a bug report to AMD but alas as fate would have it, I got four complete runs without the bugcheck occurring again on the AMD 2022.8.1 driver. If I can reproduce the error again reliably I'll run the same procedure again and share it with you before submitting a bug report to AMD. I'd also like to try it again with Mesa Injector running to force everything onto the CPU just to test. I'd like to try to eliminate buggy game assets before concluding it has anything to do with DynDOLOD or the AMD driver. Yep I'm on the Bash dev team, mostly testing these days due to RL work. I'm running the Bash 311 nightly builds. I disabled the Bashed Patch to eliminate unknown variables.

I'm also getting the OpenGL bugcheck on the newest AMD RDNA2 (22.8.1) drivers. I have a hunch as to what is going on. I originally had a more detailed post with the exact texture atlas that was being processes when the bugcheck was raised, but I suck at keyboards and accidentally closed the tab. I'll try to be as brief as possible. In summary it was processing Solstheim World when it the main thread stopped and threw: Error: OpenGL: invalid operation while processing 602A829C. I've attached my bug dump and the entirety of my ./Logs directory. I've also added a file with the clipboard contents and a DXDiag log to this post. So what changed on AMD cards? AMD just updated their OpenGL drivers in mid-July in their 22.7.1 driver. This is the first time I've run alpha .95 with the new (now 22.8.1) drivers. The release notes on 22.7.1 are vague in what was changed but can be found here: https://www.amd.com/en/support/kb/release-notes/rn-rad-win-22-7-1 Steps to reproduce aka my usual process: Disable bashed patch in Bash Run "monitor external installation" in Bash and leave it running in the background Run xLODGen .94 to generate .btr & close Switch back to Bash and create a new project for the xLODGen output. Zip output. Install xLODGen output. Close Bash Start TexGenx64 SSE and generate. Zip and close. Install texgen_output in Bash. Close Bash Run DynDOLODx64 SSE. Zip and close. Thanks for your hard work on DynDOLOD and please let me know if there's any other information or testing I can provide for you. P.S. I'm currently generating LOD without SolstheimWorld enabled. I'll update this post if I can reproduce the bugcheck without it. Update: can reproduce even without SolsthemWorld. Mertz_Beermotor_20220814-DynDOLOD3a95_bugreport.7z

Thanks for the .NET 6 LODGen version @sheson

I'm not sure why you've not gotten a response on this because this is an extremely common problem with running Wrye Bash under MO2's VFS. I think it is a permissions problem on your TEMP folder (research Windows %TEMP% variable) but perhaps someone that uses MO2 will come along that knows a step-by-step fix. Also if you haven't already updated Wrye Bash to 307b4 or later which came out right after your post, you should absolutely grab it. It has loads of patcher improvements that B3 did not have.

Heads up for Wrye Bash users: You should be running a version of Wrye Bash later than September 2017 to properly install the DynDOLOD patch files as they exist in the 2.36 release of the Resource Pack. If not, you may have issues since the DynDOLOD folder in the package will be skipped. A release candidate for Wrye Bash 307 Beta 2 can be downloaded here from the second post of the WB official thread. Follow the 307 WIP Standalone link which will take you to a Dropbox repository with the newest build. Once updated, run the Wizard included with the resource pack again and "Install missing" if necessary.

I use this and I may end up adding it to Wrye Bash as a new Bashed Patch tweak in the future in v307 final or 308. This is a super popular modification and it will save everyone a plugin slot.

I actually stopped by to check on this since I had a discussion with a MO2 user the other day and told them about the Discord version. Good to hear this is sorted.

Some people have experienced trouble using the Standalone executable version of Wrye Bash with MO2, so it is suggested that you run the Python version of WB, one of the latest builds. Outdated TV created a video how-to on how to get WB Python installed with MO2 here: https://youtu.be/5yNU9XF9zmc I need to emphasize that this is not a Wrye Bash issue. Wrye Bash is an extremely powerful mod manager in and of itself and is still being very actively developed to support new game features. If something changes in the future that makes it incompatible with MO/MO2 it is not intentional.

From what I have been able to gather so far, this is either part of the live folder stuff, or due to the anti-ransomware measures that are also part of the Windows Creators Update (due in September). Whatever it has completely put the kibosh on the VFS functionality in my insider build and killed my FONV install.