Hi folks, hope you all had a nice weekend! Mine ended up a little "special" because after two years of keeping it on life support, the dishwasher that came with my house finally "died the death"  and left us in a situation where we either had to fork out multiple hundreds of $$$ to fix a many years old appliance or knuckle down and buy a new one.

 

 

After some research, I ended up picking up a new "adult toy" and finally got it installed right before bed yesterday. Now I get to spend today doing a bunch of dishes catching up for the weekend, since I was too lazy to hand wash these last few days. 

 

But I digress. When we left off last week, we were continuing to shake down my new 1900 mod build, which was running into some pretty serious teething problems. What had initially seemed like a location-dependent crash was increasingly looking like a failure tied to script lag, script errors, or some combination of the two. Now script lag can come from more than one source. On one hand, it can come from straight-up overload, especially when a mod is trying (and failing) to execute a function over and over again because of technical problems. It can come from sheer bandwidth exhaustion too, especially when cloak spells and private registries end up drowning on large numbers of NPCs. The latter I'm starting to suspect might be part of my problem with the Rift in particular. 

 

This morning, a new version of Faster SMP came out that offers much better multithreading support, so I started by installing that. I also made sure that I had the right AVX support settings loaded for my current CPU. I'm pretty sure that hasn't changed at all since last time I updated, but if you've been following me for a while you know that I did a major hardware update last year including changing from a 7700K CPU to an 11900K one. Hopefully this new SMP update will improve overall performance. To save time in the future, I installed both the AVX 2 and AVX 512 versions so I can switch back and forth for testing/bugfixing if required.

 

 

We're also going to go into my SMP XML file and make sure the features that we want are actually enabled. This will involve merging the Baka Haeun data so that we don't lose its tweaks.

 

 

And right away we can see that we're losing a lot of controls when we let BHUNP overwrite the SMP configs. We're going to end up hiding the BHUNP config file, but first we'll go through and make sure that the relevant settings get passed forward (if applicable).

 

Here you can see we've ported over the BHUNP changes. While we were at it, I enabled a few other sensible features such as disabling player-character physics when in first person view. Since I don't play with VR or with a "true first person perspective" type mod with a rendered player body, I don't need POV physics. 

 

 

With that saved and the BHUNP file hidden, you can see below that FSMP is now the native provider of all its files.

 

 

Let's hop into the game and take a little stroll to see if there's a noticeable effect on frame rate "out of the box." As we loaded in, one that that was apparent was that my FPS was clamped to 60 during the loading screen. I'll need to research this because in Fallout 4, this can be disabled with mods and it improves loading time. I probably already have the technical ability to do this with some of the graphics mods I've already got installed, but its just as possible that Skyrim has specific issues that caused me to not enable this and I just forgot. So yeah, one more thing to research!

 

Frame rates are great inside the Resting Pilgrim. ENB is reporting an average of 180 FPS and this is with some setup scripts and stuff still running in the background. So far, so good. Inside the "live" part of the inn, FPS is running between 120-180 depending on if I'm moving (interesting that it swings so much with player physics disabled), but visually the difference isn't noticeable and other than one stutter when an autosave triggered (I swear, its like its impossible to truly disable the damn autosaves!) the visual experience has been smooth. 

 

Now one thing does dawn on me as I work through all this - by letting BHUNP override the FSMP config files, I was unwittingly disabling support for my graphics card's CUDA cores, since I was effectively running FSMP at default settings and CUDA defaults to off when no config setting is provided in the XML file. Notwithstanding occasional stutters that are probably linked to quest startups, walking around Helgen I was getting 50-80 FPS for the most part. This is pretty good, as I don't think I was really going over 55-60 in exterior zones before. The FPS swing is a little more noticeable, but not too bad. One other thing I noticed, which speaks to the papyrus engine getting more CPU time, is that the iWant status icons settled into their 'fully installed' configuration much faster than I'm accustomed to. 

 

 

Compare to this one from Friday's troubleshooting run where some icons were overlapping.

 

 

That overlapping behavior is normal during startup and resolves fairly quickly, but after updating and configuring SMP it completed a lot faster. That's good, since this is all scripted and it speaks a reduction in script lag. 

 

One small digression - as I left the Helgen gate I saw the new SMP wind effects in action and they look great. The screen shot doesn't really capture it but this guy's cloak is subtly shifting and deforming in the wind. A very nice "immersion" feature!

 

 

Still had some stuttering during combat, which I'm pretty sure was indeed script lag and might be related to some of the FEC errors we saw in the papyrus log on Friday. However, when it wasn't having stutter, combat FPS was still smooth and looked good. Average FPS while walking around in the outside world was 45-55 though it seemed to dip when reaching cell boundaries (and, by extension, when loading in adjoining cells). This may be related to grass cache generation so its possible that issue won't be as pronounced in a properly implemented playthrough where the grass has all been pregenerated. 

 

Now for the real test - let's teleport to Riften and then walk from there to the hunter's guild. I'm going to turn on god mode but leave AI detection active; if I can get to the guild and hostiles appear, I'll let them shoot me so that I can try to trigger the crash from before. 

 

Here we are in Riften right after the teleport. FPS is hovering around 30 with minimal stuttering (and that probably from initializing all the NPCs). Scripted functions such as the ZAZ furniture for the meat merchant are firing in a timely manner. 

 

 

Inside a packed tavern, I was getting about 60 FPS with some deviations up and down. A little bit of stuttering when new actors entered the cell, so still not perfect. We've definitely got some susceptibility to spikes of script activity which does mean we've still got room for fine tuning.

 

 

Looking in the papyrus log reveals that as this stuff is going on, Skyrim at war is still running and generating a lot of errors. SAW's load on the game, which has caused problems in the past (remember back in Kirstia's adventure where it was murdering the frame rate near Markarth?), but we also have some other things to look at, including notably DB_BodypaintScript, which is part of Distributed Bodypaints and Overlays. I'm open to the possibility that some of what we're seeing with DB is actually "functioning as intended" - these may be calls against features that aren't enabled - but I want to drill into it and also take a look at whether or not that mod has updates available to it. 

 

 

 

I rested a few hours in the inn and when I left it was daytime. Unfortunately, Riften FPS had dropped a bit (with all the NPCs active) and I observed some script lag. The prisoner you see in this screen shot had SOS placeholder underwear on him for a little bit before the schlongification script (itself tied to a cloak spell, not ideal) fired off. A solution here might be to try bootstrapping SPID in as a replacer for the SOS cloak spell, but that's a more involved, longer term project if no one has done it before - especially since I've heavily customized SOS already.

 

 

Further testing in Riften revealed that the frame rate there was very sensitive to what I was rendering - FPS dramatically improved when not looking towards the town square. This is a data point I'll need to hang on to for now, it might indicate that I need to add some occlusion planes to Riften or otherwise try to optimize it. But I've dragged my feet enough, let's step out back into Tamriel.

 

Well, I guess that's the end of that. While on the loading screen, the FPS (previously pegged at 60 as I'd mentioned before) abruptly tanked, first to 13 and then to 0.2, and then the game crashed without generating a log. Whatever problem was happening before seems to still be impacting the area west of Riften. So that's one mystery that is neither solved, nor resolved yet. Let's take a peak into the papyrus log and see what it was chewing on when the game crapped out. 

 

 

Hi there, Skyrim at War. I don't want to jump to conclusions and definitely label this mod as the problem, but if you've been following me for a while you know that one reason I've heavily tailored this mod in the past is because it caused crashing during grass generation. I'm not sure this is the same issue, but I'm open to the possibility it might be. Moreover, while I passed the weekend I put in a lot of thought and decided that at the end of the day, this mod never really met my expectations while, on the other hand, caused a lot of problems. It's time to remove it from the load order.

 

This isn't just a matter of unchecking the mod on the left side of MO2. I've extensively patched this mod for integration with my setup, and we need to unwind those changes. As you can see below, it has hooks in 5 of my conflict resolution patchs.

 

 

We'll go into xEdit and use "report masters" to find the relevant entries and edit them... but it may take a while as there are a bunch of changes to undo. You can see an example of the "report masters" output below... though this is certainly the shortest list I'm going to get.

 

 

Here you can see how I had previously merged edits from Audio Overhaul Skyrim with SAW; now we need to revert those changes. After doing so, we'll also use the "clean masters" function on this patch, to remove the master index for SAW and ensure it doesn't crash out when the SAW esp is missing.

 

 

 

Note that I also reverted the force, damage, and radius values. In theory, I don't mind keeping SAW's balance changes, but since these are tied to a new hazard object I'm going to play it safe and keep the values that were associated with the vanilla hazard.

 

The next file to look at is the leveled items patch, and we can see that it actually out-and-out contains some SAW leveled lists in it as overrides. This was to integrate them with mods like Heavy Legion, and we'll start out by removing all the SAW (EE form ID prefix) leveled lists from the patch. Once that's done, then we'll run the filter again to pick up any references to SAW in other mods' leveled lists.

 

One thing I am a little put out about is having to remove the combat style data from this mod. I liked a lot of what it did in that dimension, and at some point in the future I might come back and restore some of those features to the vanilla Imperial and Stormcloak NPCs, then just purge the parts of this mod that were problematic, such as the scripted content (formation marching, etc) and the ACHR data and packages. That'll be a project for another day - probably another day far in the future. 

 

 

OK, it took a while to sort that out, but as you can see, SAW is now retired and it isn't throwing any warning flags with relation to my conflict resolution patches. Let's also pull out Frozen-Electrocuted-Combusted. I like this mod, but it almost entirely duplicates content from Maximum Carnage (albeit, with results that look a better overall) and it was throwing a lot of errors in the Papyrus log. Fortunately FEC didn't require any patching in the first place, so removing it is as simple as deactivating the mod. 

 

Last but not least, we're going to update Devious Strike to its latest version. Before we do a performance test, we'll quickly check that mod in xEdit to make sure it doesn't require any compatibility patching. It returned no errors, dirty records, or conflicts, so that's a pretty good start! Let's hop back into the game and roll up a test character.

 

 

Whoopsie. Looks like I should have done a little further checking before I tried to load into the game. Here's the issue, below:

 

 

As you can see, the form ID structure of the mod changed, and so one of my old patches now contains an invalid entry. We'll need to go through and clean this up. It turns out that the underlying issue is that this went from an uncompacted plugin to a compact one some time after I last installed it, and in-between those versions more records got added to the original. This meant that it compacted down with a different set of form IDs than I got when I compacted it DIY. I ended up just pulling all the modded records out of my conflict resolution patch and rebuilding it (it was just a matter of restoring SLA Exhibitionist faction membership to block 'modesty' cover animations). 

 

 

I started by spawning at Helgen and walking to Falkreath with AI detection turned off. Frame rates were generally pretty good - consistently about 60 with much less stutter than I'd seen prior to removing SAW. I did get pauses at zone lines, which is probably from grass cache generation; as I mentioned before, this is a "testing only problem" because for a live run I'd pregenerate the grass cache to fit the finalized landscape. The reason I don't pregen during testing is because I often fiddle with or adjust the worldspace during these periods and that quickly results in floating or screwed up grass unless I purge the cache between playthroughs. 

 

An interesting aspect of the new version of Devious Strike is that it allows more faction options for the Strikers. I suspect that when I get around to configuring it, I'll be limiting Strikers to Necros, Warlocks, and maybe Silver Hand. 

 

 

During the walk to Falkreath, frame rate remained consistently above 60 except when caching grass, which is a good sign. The goal, after all, is to keep the available processing power above the point where everything creates the illusion of seamlessly working in the background.

 

 

Frame rates got a little janky as I approached and then walked through Falkreath, which was possibly a result of Distributed Overlays and SOS both processing a lot of characters for the first time; I was able to see the textures getting applied as I walked through town, which points to some script lag. 

 

Once I got outside, the script lag seemed to settle down - this prisoner applied his body paint and SOS assignment before I could get close enough to see anything changing.

 

 

One thing that I realize is probably also contributing a bit to the occasional lag bursts when I approach settled areas is the 'real names' mod I have, which I didn't think to set to "stranger mode" before launching in. In a fully configured playthrough, this mod would only be firing when I entered dialogue with generic characters, rather than doing its thing as soon as I shared a cell with them. Having fixed the settings, we'll need to pay attention to the impact when I reach the next settlement.

 

 

Approaching Half Moon Mill, we had a crash. The crash log is interesting because it shares some elements in common with the issue we saw previously with some of the crashes outside Riften. The crash address is different, but this is actually good because unlike the previous one there are hits on Google for this address, such as this one. This will let me do some research into this issue and maybe nail down a cause.

 

The new log

 

Similar items in the probably call stack from the earlier failures

 

Research led me to this conversation about one of the FYX mods:

 

 

The conversation continues and it turns out that RBark was using 1.0.2, rather than 1.0.2.2, which fixed some issues with SMIM compatibility. And lo and behold, I'm also using an older version of this mod. Let's update this mod and then try again. Its probably premature to expect that this alone fixed the problems I was having over at the Rift, but it sure would be nice if it did. 

 

Once I got back into the game, I retracted my steps to Half Moon Mill. Turning on Stranger Mode definitely appeared to help with frame rate fluctuations, though I'm sure part of that too was the presence of local grass data in my override folder from the previous run. 

 

 

That did the trick for Half Moon Mill! Next we're going to turn on AI detection (but also turn on god mode) and walk to Markarth. This should put a little more strain on the system but hopefully we can continue to maintain a healthy performance level. Once I get to Markarth I'll take a carriage to Riften and directly approach the problem zone. 

 

 

Hern, why are you naked? Do I need to investigate your outfit record? After this I ran into some bandits near the coffee house - had some stutter in combat, so there's still some research to be done in there.

 

 

Review of the relevant timestamps in the Papyrus log confirms that these issues were caused by script lag - as you can see, the suspended stack count exceeded the limit during this timeframe, meaning that there was a heavy script pileup of the sort that's going to hit the FPS count.

 

 

The specific scripts listed here aren't necessarily the culprit for the slowdowns, but analysis of the logs may reveal mods that are putting too heavy a hand on the system. Some scripts that I'll need to investigate further...

 

• SPPlayerAliasOnHitScript (belongs to Sexlab Pheremones - also a mod that's already kind of on probation because of footprint vs. value concerns)
• Maximum Carnage in general (though I don't really want to dump this one if I can help it)
• RN_Listener_Skills - for LOTD Curator's Companion - a good mod but one that might get removed because of footprint vs. value
• SkyBirds in general - a constant presence in the script log and while it doesn't seem to be directly causing problems I may need to weed it out in order to conserve resources. I'd rather keep it of course because its a great ambient immersion mod.
• Faction Warfare - another one that I really hate to think about removing, but that is undeniably a heavy resource user

 

Unrelated to the stack dump, I do see that Meat Farm is throwing Papyrus errors and I know that one has been updated several times since I last worked with it, so I'll need to look at updating that one. Interestingly, when I returned to the game after doing my analysis of the P log, outdoor frame rate was up to 60-70 FPS. I'm also noticing repeated errors regarding Immersive Decompising Dead that need to be looked at. I like the idea of this mod, but if its busted I'll probably pull it for the time being.

 

 

The superior outdoor FPS (except for when it paused to cache grass) lasted until I hit the first Markarth Hold guard post. The jank appears to correlate with several different mods processing a number of NPCs in the area as well as some combat that was happening deeper in the cell (I found the bodies as I continued my walk). A little bit later I got attacked by a bandit and the script engine started stack dumping again. Skybirds was once more very present in the log, which is making it look increasingly like I'll need to learn to live without that mod if I want to stabilize my frame rate. 

 

Below you can see we've reached the roadside shrine of Dibella. This guardian from the Sacred Band is doing a good job showing off the new wind physics for SMP.

 

 

Looks like someone needs her facegen fixed...

 

 

We made it to Markarth intact, so the final leg of this stress test run awaits: traveling to Riften.

 

 

Things went well initially at Riften, but the game choked out and died trying to enter the tavern. Papyrus log showed a large number of failed quest calls to the Torch Remover mod, which frankly I've been leaning towards retiring anyway on account of some unwanted behavior it can cause during the main quest. This crash did not generate a crash log, which is annoying. I'm starting to wonder if the issue is linked with an actor who lives in this area and who might be moving between locations, contributing to the variability of the no-log crashes around Riften. 

 

 

While this run didn't solve all my problems, it gave a lot of good information that'll contribute to debugging. Specifically, next time we'll assess whether or not we should remove SkyBirds, Immersive Decomposing Corpses, and the Torch Remover mod. We'll also look to fix the glitches we ran into (blackface and mesh issues for the Reveler, Hern's outfit record) and get Meat Farm updated to hopefully cut down on the error spam. 

 

See you next time!