z929669

LOOT and BethINI binaries still need to be added as executables as indicated in the Tool Setup table. I think the instructions a very clear, and they've been reworked many times.

Occlusion.esp is bundled with DynDOLOD.esp if you don't tick the plugin box under the occlusion section of the GUI. We suggest always ticking this box so it's separate. Then store it in a different mod, so you don't need to generate occlusion on subsequent runs of DynDOLOD.

Look at upper right of MO for the warning indicator. If it's colored, click it to determine what masters you are missing: Revisit those mod installation instructions. Test with a new playthrough instead of a save when launching.

commenting/removing deactivates the line from being interpreted by the program. Commenting is always best, since it preserves the information.

This is helpful. Thank you. Good to know. Tech's post may help me to address this and the other rocks issue mentioned.

Just following up: It turns out it actually was a hardware issue. Most likely CPU voltage related to AMD TPU setting I had neglected to disable over a year ago when I thought I had disabled all of the built-in overclocking. The only explanation as to why it became a bottleneck in my latest run is degraded performance over time as a result of stress on my hardware, due to the pervasive overclocking features of my motherboard. Anyway, restoring optimized defaults corrected the problem.

As I suspected, my PC is shutting down due to CPU temp spike exceeding the now-higher threshold and fan speeds I've set. As mentioned previously, I use water cooling, and my PC is pretty optimized. I seriously doubt that my hardware and dust buildup have changed significantly in the past 30-60 days, but I will perform my routine PC fan/dust maintenance and do some performance evaluations with Prime95. Rather, I suspect the occlusion routine is more aggressive or demanding than in previous Alphas for whatever reason. Based on some of the other recent posts for Alpha 182, there seems to be increased hardware demand with Alpha 182. No crashdump, but here's my logs, including realtime debug for the record. At this time, I will test with setting occlusion to '1' and disable the realtime/debug logging, since we have a plausible explanation for my recent crashes (overheating of CPU, specifically during occlusion gen of Sovngarde using quality level '3')

My hardware is unlikely the issue, and stress testing would be redundant, as I have done all of that in the recent past with no hardware changes since. As mentioned, I've generated hundreds of times with the settings I provided. Memory is also not the issue. I rarely see more than 32 Gb of my 64 Gb committed when running the process. My system did not BSOD. It simply shut down, so the problem was most likely with the CPU or system bus overheating past the threshold I have set. I will make it a point to monitor my temps though to verify. I may need to relax the threshold I have set once I know what's happening. It's fairly conservative at 85 C. I will have more evidence soon with the realtime log and crashdump. Perhaps it will not crash, since the RT logging slows things down quite a bit.

Here's my logs ... no bugreport, no debug, etc. Situation: Running DynDOLOD Alpha 182 with the following settings on the Step build (standard settings for me, run hundreds of times on this and similar builds): DynDOLOD_SSE_Default.ini The problem occurs during occlusion processing. I forget which worldspace (might not matter). My PC simply shuts down, indicating that the CPU becomes too hot or the system is otherwise critical. use water cooling and no overclocking. My system specs are in my sig. Due to the automatic shutdown, logging is cut off. Events are not able to print until reboot, and then only a general kernel shutdown error. This is my second such crash, so that's why I'm reporting it. Starting now, I have enabled system minidumps and set the following in DynDOLOD_SSE.ini: Debug=1 realtimelog=1 GLListDebug=1 GLDebug=1 I will repeat the process as the previous 2x, and report back with additional info/logs. For what it's worth, occlusion is always taxing on my CPU, but never to the point of a reproducible protective system shutdown. I could lower my occlusion quality setting, but I would rather troubleshoot the problem if possible, since my current config is historically reliable on my PC and mod list.

Sorry to interrupt this testing, but in case you are overclocking your system, I suggest you restore the BIOS defaults (particularly, remove XPM memory timings if enabled). This gets to the stability/stress testing sheson mentioned. I've seen a good deal of trade-offs on my own system with overclocking. Small gains in performance at the expense of BSOD and random issues using xLODGen, DynDOLOD, and other performance-demanding applications (Ps, video conversion, etc.).

I just stumbled across a fix for this issue by loading VLC after MM: VLC at lower priority (position 126) than MM (position 145): VLC at higher priority (position 145) than MM (position 144): ... but this may open up other issues, depending on how it's done. We could also move MM just above VLC, but I think that will cause more issues with CRF, FaECF, possibly RBB and some others sandwiched in between these. @TechAngel85 We should verify LO of VLC with respect to MM and the cascade of LOOT sorting related to MM. Maybe it's a simple edit to the LOOT ML, but I want to be sure of the 'best' position of all these plugins in relation to one another. Fe, CRF probably needs to load after VLC. Likewise, SLSR may also need to load after MM. UPDATE: Vanilla Landscape Corrections.esp has no conflicts with MajesticMountains.esp. The problem is actually due to Snowy Landscapes In Snowy Regions.esp overriding Vanilla Landscape Corrections.esp. Moving the former to one lower priority (126) than the latter (127) also fixes this issue. I'm now rethinking that SLSR should be dropped regardless of the Smooth Shores Patches being lost without it. SLSR does have a good number of CRF patches that are lacking in VLC where SLSR and VLC conflict. Likewise, VLC has a small number of CRF patching that SLSR lacks. I'm going to run the game for a wile without SLSR and the SmoothShores - SLSR Patch.esp to see if there are any issues without them.

Clean your vanilla masters with xEditQuickAutoClean as explained in the documentation. Also read the previous post^

It's safe to update. All that's happening is the source of a few hundred edits is changing from the Step patches to the krypto patches. Good catch on the Metallurgy. I updated the wiki instructions.

Latest 2.3 patches updated, incrementing the latest version of the guide to 2.3.5. The impetus for this update was a change to kryptopyr's Patch Hub no longer maintaining the individual patches under Misc Files but rather focusing solely on the FOMOD. The FOMOD is much more convenient if it's maintained, because it's 'intelligent', and almost all patches are installed automatically if needed based upon the mods installed. This in turn obviated incorporation of several of the former Misc Files into the Step Patches, which was done to ease the burden of installing the krypto patches individually. Now, we can install all of the ESL-flagged patches automatically in one go with the new wiki instructions. IMPORTANT: Do not install the latest Step Patches until the new krypto Patch Hub instructions have been followed to avoid missing patch records no longer in the Step patches! Sort with LOOT after reinstalling krypto patches using the FOMOD and updating the Step patches.

Change the arguments as I have them in the screenshot I posted previously. Except the '-SSE', which isn't needed if the file name you are using is SSEEdit.exe

I would post on the LOOT Discord for assistance. They are likely not writing to the Win registry in the same way as before. Also post on the WB Nexus page for help too. It probably needs to be updated. Also try uncommenting the LOOT path in bash.ini (rename bash_default.ini to bash.ini). Then set the correct path for that.

Did you install the latest version of LOOT in the same path as the old one? Find bash.ini and check the settings for LOOT in that.

In relation to LOOT no longer supporting this mod, use the following method to ensure the USSEP is higher priority than UHDAP ... Wiki instructions updated likewise. The reason why the UHDAP priority must be lower than USSEP priority is due to some audio fixes done by the latter but not the former ...

Mod instructions updated for 2.3 (no special instructions at all now)

It's most likely caused by a mod containing a binary (DLL) that was not installed properly. It could be any of them though and not necessarily the mod related to the OP problem (whatever it was, probably CoMAP)

You may need to launch with this switch:

I have updated TGR 2.3 recommendations and the guide and Nexus changelogs to reflect the expectations for the 2.3.4 Step CR Patch update. This update is also required to run v4.3.3 of the USSEP. For those running an existing Step SkyrimSE 2.3 playthrough, consider not updating USSEP and the Step CR Patches. These updates are most likely not an issue for the majority of users, but those with savegames involving the deprecated location or the affected TGR quest stage, could experience some issues.

Yes. I'm familiar with the all-in-one concept, but I failed to connect the dots. Thanks for clarifying

Yeah, I'd rather update the TGM instructions with a note to those running an existing Step playthrough without the optional file than roll back the change, which will break the Bitterblade Hollow location. I'm not sure that the USSEP changes are disruptive to an existing playthrough, but some of them may well be for specific edge cases.

Merged original topic posted by @Brace It doesn't necessarily make any sense to install all of the mods that articulate with Completionist. Install the Step build and also install Completionist to test it.