Mousetick

I used this mod in all my latest playthroughs and I liked it. It's a good improvement I think. No issues encountered in a heavily modded setup.

I used this mod in all my latest playthroughs. I used pretty much all of tarlazo's mods actually This one is supposed to address a very specific and tiny issue. I can't say whether it actually works because I never tested the bug without this mod. But it didn't hurt anything either as far as I could tell.

I used this mod in all my latest playthroughs. I does exactly what it says on the tin and it works quite well. It works with any radiant-eligible clearable location, including mod-added ones without patching anything.

I used this mod in all my playthroughs and I liked it. I think it's a good improvement. No issues were encountered in a heavily modded setup as far as I can remember.

Having played many many hours with this mod without any issues after dumping FIZZLE, I'd strongly recommend it. It's very lightweight compared to FIZZLE, as its script runs only when casting spells vs. FIZZLE's cloak spell script which runs "constantly". It doesn't have the various compatibility and performance issues carried by cloak spell-based distribution to NPCs. Its user experience for new users is also superior to FIZZLE: a spellcasting failure is indicated by a "puff" of colored smoke (different color depending on spell type) around the player (or the NPC), which is easily noticeable even in first-person view. Whereas with FIZZLE a failure is indicated by a small audio "click" and nothing else happens. I found that FIZZLE feedback quite confusing and it was difficult to notice what was happening when I started playing with FIZZLE. It has its own formula for calculating the chances of success/failure which is not the same as FIZZLE's so the experience may feel different at first for users accustomed to FIZZLE. But the idea is the same: trying to cast higher level spells than skill levels may fail, the chances of failure increasing the higher the level difference. I was using a different mod than EEOS in my playthroughs to distribute spells to NPCs so I can't speak to how well this mod works with EEOS in regards to NPCs trying and failing or succeeding to cast spells in a pure STEP setup. Note: I'm not currently playing or even running Skyrim these days, haven't been for the past 6 months or so, and don't intend to return to it for quite a while, if ever. I just thought I'd chime in in favor of this mod, which is quite underrated IMHO. There are not many mods that do this kind of thing it seems. Last I checked there were 3 mods: FIZZLE, this one and another one that I don't remember. This mod also exists in a "full featured" version by the same MA, with more options and features, and a much more "sophisticated" behavior (not recommended for STEP). My 2 cents, hope they help. Cheers.

ICH provides different 3D models of closefaced helmets for beast races and orcs than for humans and elves, specifically designed to fit the shape of their heads. With your patch you'll lose the custom helmets of ICH for the affected races, i.e. they'll wear the same helmet as the humanoid races - which is also how vanilla works. It's a known bug in Maids II. I don't know if there is a better fix. I played it with the missing heads, it didn't bother me too much. I'd recommend playing Maids II as a separate game/adventure. When I played it I didn't know what to expect, so I played it in the middle of a typical Skyrim game/adventure. It completely ruined my immersion and I stopped playing that game afterwards. It starts off in the Skyrim universe and then completely goes off the rails, it's not lore-friendly at all. It's a disjointed fever dream. Boy do I regret ever playing this mod, the worst of all story mods I played

Yes the UI is not the most user-friendly out there, to put it mildly. It's an old mod, back when modding standards and know-how were lower. The Heart Beat Script option is indeed quite confusing... and its description is wrong. It's not a frequency, it's the inverse: a period, an interval in seconds. This mod works by detecting the locked container or door closest to the player, if any, and by running a hidden quest on it to handle the possible unlocking done by bashing it or casting a spell. It needs to do it this way because the player doesn't activate the door or container when bashing the lock or casting the spell, so it doesn't know which lock the player is "attacking". It just guesses by selecting the locked container or door closest to the player. The Heart Beat is how often the hidden unlocking quest is restarted: every N seconds. Every time the hidden quest is restarted, the locked container or door closest, if any, to the player is selected. As time elapses and the player moves about, another lock now closest to the player, may be selected, and so on and so forth, every N seconds. If you set the Heart Beat value to 3 (the default), the mod will restart its hidden quest every 3 seconds (NOT 3 times per second as the description says). Therefore it will be able to select a new locked container or door closest to the player, every 3 seconds. If you set the Heart Beat value to 15 (the max), it can select a new locked container or door closest to the player every 15 seconds. If you move fast and try to bash a lock, it may not work (nothing happens when bashing or casting spell) because the hidden quest is still running with another lock you passed by a few seconds ago when the Heart Beat was last triggered, instead of the lock you're now looking at in front of you. You'd need to stand right in front of the lock for at least 15 seconds to make sure the hidden quest has been restarted with the correct, closest lock. So the 'Heart Beat Script' is essentially a "lock selection refresh timer". Hope that makes sense? As for this mod's use of scripting, yes it's entirely scripted but it's pretty lightweight. It's idle most of the time and doesn't do anything until the player bashes a lock or casts the unlocking spell on it. The detection and selection of the locked door or container closest to the player is handled natively by the engine, not by scripts. The only potential overhead this mod may have is restarting its hidden quest every N seconds, but it's negligible.

I used to have this mod in my load order (the "tweaked conditions" version) but recently dropped it after realizing I never felt the need to change the values and I have already too many MCMs. The default values used by GDO are ok with me. It's nice to have the options in theory and this mod certainly doesn't hurt anything. It just edits some global variables that the GDO plugin uses to control when, in which context, guards say certain lines. But I would question the opportunity cost of adding such mod to the Guide: one more mod to test and support, and for users to install, for very little value added.

First I need to correct something I said earlier about magic skills only increasing while in combat which is patently false. It depends on the type of spell: Offensive/Detrimental or Defensive/Beneficial. For example, Candlelight gives Alteration XP at any time. Yes, you got it. This works separately for each skill. If you initially nerf all skills speed by 20%, after reading 5 skill books: 2 One-Handed, 1 Restoration, 1 Light Armor and 1 Alchemy, the resulting speeds will be: -12% One-Handed, -16% Restoration, -16% Light Armor, -16% Alchemy and -20% all others. If there are no complaints about it not working on the newest patch, or users making a tantrum demanding a compatible update, it's a good sign it probably works fine.

I concur with all your observations, however I can't confirm about bound weapons as I never use them. I'm pretty sure magic skills only increase while in combat - that's vanilla behavior not changed by Odin or Vokrii as far as I know. When I use summoning spells with Odin, I can summon a creature by casting the spell before combat but I only gain Conjuration experience while the summoned creature is in combat. About speech and trading, speech skill increase depends on the base value of the traded items, not on the actual price at which they're sold or bought (which are themselves a function of speech skill). There is already an economy mod in STEP, Trade & Barter, that allows you to configure the bartering parameters, but they make you richer or poorer from trading and don't affect the speech skill gain. In vanilla, if you trade a stack of identical items, you only get the speech skill XP corresponding to one item. With Bug Fixes SSE (included in STEP), you get the skill XP of one item multiplied by the number of items in the stack (see 'Speech Experience: Item Stacks' configuration setting). That may be a factor. Vokrii grants speech skill points for shouting, so if you shout a lot that may be another factor. -- There are several problems with character leveling in Skyrim: Player level is a direct function of skill levels. All skills contribute equally to player level. Skill levels are gained organically by playing the game. Some skills can't really be avoided (e.g. Speech or Lockpicking). The skill XP -> player XP function is very sharp: it makes the player level up very quickly at low levels and progressively slows down at higher levels, reaching a point where the player needs to grind unused skills to gain enough skill XP to reach the next character level. Mods I use for balancing leveling: Main mod is Experience which tries to solve the above problems by completely decoupling player XP from skill XP (and also reversing the dependency by capping skill levels based on player level). Skill XP is gained as usual, same as vanilla. Player XP is disconnected from skill XP and it is gained by completing objectives and quests, discovering locations, clearing dungeons and killing enemies (all configurable) - similar to traditional RPGs. It can also be optionally gained by increasing skill XP but it's off by default and is pretty much pointless as it would re-create the same problems as in vanilla. The player leveling curve as a function of player XP is unchanged compared to vanilla, i.e. very fast at low levels then progressively slower to become a slog at high levels. Experience Multipliers (MCM sliders for each skill) is an MCM UI for configuring skill XP gain multipliers. It provides a simplified and user-friendly configuration, but not as extensive, compared to Skyrim Skill Uncapper. Nerfing or bumping skill leveling is still useful even with the above Experience mod. Skyrim Skill Uncapper can still be used if needed to uncap skills beyond 100 or use some of its other features. Leveling Freedom - Configure your XP Curve - Gentler Smoother Steeper or Flat mentioned previously to both lift and flatten the player leveling curve (i.e. more XP needed to level up player at low levels and less drastic speed difference between low and high levels). Reading Is Good (SKSE) changes skill books to increase skill XP gain multipliers rather than skill levels. Makes skill books very valuable to counter-balance nerfed skill XP gain multipliers. Notes: I've used the above mods with the Skyrim SE 1.5.97 runtime. They should all be compatible with the latest Skyrim SE/AE version but I'm not too sure about Reading Is Good. Although all the above mods can be installed/uninstalled mid-game, to make the most of them it's best to use them from the start of a new game and adjust parameters along the way as wished or necessary. The Experience mod is a significant departure from vanilla character leveling mechanic so I'd be hesitant to recommend it unless you are highly bothered by the vanilla problems I listed above and are willing to experience something different. Personally I think it's great and I love it, as do most of its users. I've never had any issue with it, and it works with any content (vanilla, Bethesda Creations or mods). Though it does require some fine-tuning to accommodate each playstyle and the amount of content to be played, because its "out-of-the-box" configuration is balanced for plain SE vanilla content (before AE and without any mod-added content).

I don't use Skyrim Skill Uncapper to configure leveling (I use a combination of other mods instead), and I play with a lot of mod-added content or modded gameplay mechanics on top of the STEP base, so I can only provide general pointers and some subjective thoughts. I don't think some one-size-fits-all advice can be given. It depends on your playstyle and preferences. You'll probably need to experiment and adjust as needed. You can simply reduce skill XP gain multipliers to slow down skill leveling which in turn proportionally slows down player leveling since the latter is derived from the former. Or you can reduce skill level to player level multipliers to keep leveling skills at the same pace as vanilla but slow down player leveling. This can result in a relatively highly skilled but lower level player. Consequently there are fewer perk points available compared to vanilla to leverage the relatively high skills. Or you can combine the two approaches for a slower overall, but potentially too grindy and restrictive as time goes on, progression. For example, this configuration: Slower Leveling for Skyrim Skill Uncapper which reduces both by 25% (this is not an endorsement or recommendation, but you could take a look at it for inspiration). Reducing skill level to player level multipliers slows down player leveling more and more as the player level increases, even more so than in vanilla, due to the sharp leveling curve. Some data points not to be construed as recommendations, based on my personal experience deviating greatly from a standard STEP setup: I find the player becomes very powerful at around level 40 and the game starts to progressively become less enjoyable past that level. I try to balance my leveling configuration to reach endgame at about level 60, tweaking along the way if necessary. I set all skill XP gain multipliers to 0.5 except Pickpocket and Enchanting, which I don't use much and are already grindy enough in vanilla for my taste, remaining at 1.0. That's very slow and makes the game more challenging for longer. I use Leveling Freedom - Configure your XP Curve - Gentler Smoother Steeper or Flat to make the player leveling curve flatter. So while the skill & player level progression is slower, it's smoother and not so grindy at higher levels. Beware some mods have their own configurable skill XP settings. You'll want to change either their multipliers or Skyrim Skill Uncapper's but not both together to avoid cumulative effects and potential confusion. Change the multiplier of one mod and leave the other at 1.0. From the top of my head: CACO provides its own Alchemy skill XP gain multiplier configurable in its MCM. CCOR provides its own Smithing skill XP gain settings configurable in its MCM. It also optionally allows gaining skill by using Tanning Rack / Smelter / Mining Deposit which is not normally possible in vanilla. Lastly it allows for using an alternate skill XP formula to prevent XP farming. Vokrii grants Smithing skill XP from Mining Deposits. The conflict with CCOR is apparently not addressed by the STEP CCOR Patch in the current guide, so the actual behavior with both installed depends on which version of the mineorescript.pex file wins in the mod manager. Edit: Vokrii / CCOR conflict is addressed by patch from Kryptopyrs Patch Hub as instructed in the current guide. I missed it while looking in the wrong places.

Default Adept should be fine if you've already played Skyrim before. Skyrim's difficulty option only affects the player in combat, in a simplistic narrow manner - specifically: the amount of damage taken by NPCs from the player versus the amount of damage taken by the player from NPCs. At Adept difficulty the ratio is 1:1. All other gameplay and combat aspects remain the same regardless of difficulty level. You can change the difficulty at any time, even during combat, if you find combat too easy or too challenging. A few mods in the STEP Guide affect some gameplay aspects that can make them a little more difficult or easier than vanilla, including but not limited to: CACO: Various configurable options, mainly about Potions and Poisons. CCOR: Various configurable options. Ghosts Mechanics and Shaders Restored: Makes ghosts into sneaky bastards. Realistic AI Detection: Makes sneaking harder. Trade and Barter: Various configurable options, mainly about trade prices and money earned/spent. Thieves Guild Requirements: Various configurable options. FIZZLE: Spellcasting may fail depending on skill. Smart NPC Potions: NPCs can use potions and poisons. Vokrii: Mastery perks (first perk in each branch) make progression unbalanced and overpowered compared to vanilla perk trees. Vokrii Perks For NPCS: Slightly counterbalances previous.

The differences are real and expected but do not change the appearance of the meshes in-game. Many meshes were split into multiple shapes, as the Changelog for 1.0.5 indicates: Splitting meshes prevents light flickering. ELFX meshes are basically vanilla or SMIM meshes that have been split into multiple shapes to prevent light flickering, but they're otherwise visually identical to the meshes they're based on - which is (and the only reason AFAIK) why they're used by the Guide. This mod now provides split meshes by default, so it no longer provides a 'ELFX' version as a patch, since it would be redundant. Illustration by comparing ELFX > v1.0.4 > v1.0.7 in MO2 NIF Previewer: Note the different number of shapes between versions, while the number of faces remains the same and the number of vertices remains roughly the same. As for the file dates, they're correct. In your screenshot the newer files are dated 2/27 or 3/3. If they'd taken your current local time, they'd be dated 3/5. File timestamps are normally preserved in ZIP, RAR and 7Z archives, and restored when extracting. BSA archives do not preserve timestamps.

@z929669 The recommendation to install the ELFX patch needs to be removed from the Wiki instructions because that patch no longer exists. From the mod's Changelog:

No and no. The ELFX patch is no longer available because it's not needed/useful anymore. The STEP Guide instructions are outdated, you can ignore the patch.

I use a single 'Configuration' mod with highest file overwrite priority, in which I place all user-editable configuration files, whether they come from mods when they are installed or they're created at runtime. I typically keep a copy of the original configuration in its respective parent mod folder, as a 'default configuration' reference. This eliminates all risk of losing my changes when updating mods and keeps everything in one easily found place. As this involves a lot of manual file & mod management, I wouldn't suggest it as an approach for the STEP Guide. I'd like to suggest another approach for the guide, derived from it: provide a ready-made 'STEP Configuration' mod, containing all the configurations for the mods used in the guide, to be installed like the STEP Patches. Pros: Mods are already configured as they should be for the Guide. Eliminates a bunch manual of mod/file management/editing at installation time, and dealing with stuff appearing in MO2 Overwrite at runtime. Eliminates a bunch of associated documentation describing how to perform the previous. Streamlines documentation and support, removes ambiguities when referring to configuration files and their expected location. Cons: Needs to be installed early in the Guide, in order to perform the 'Game-Launch Smoke Test', and then sorted to bottom of mod list before performing the 'Performance Tuning', and then sorted again to bottom of mod list after installing the 'Post-Processing' group. These extra steps can be easily explained to, and achieved by, the user with MO2 UI (right-click mod -> Send to... -> Highest Priority), but they could be missed (as any other extra step). May need to be maintained to keep up with mod updates making not backward-compatible changes to their configuration. Though nowadays a lot of "modern" mods are well-behaved - particularly those that create their configuration at runtime if it doesn't exist, and update it dynamically if needed and it already exists. An existing user updating the 'STEP Configuration' mod to a later version downloaded from Nexus, would lose their custom edits if they made any. This would not completely eliminate the need for manual editing of some mod configuration files (e.g. SSE Display Tweaks), but it's not worse than other approaches in that regard.

I don't think DynDOLOD (specifically, the DynDOLOD .esm, .esp, and Occlusion.esp plugins) is the cause of the crash. As we tentatively found in the other topic regarding this issue, based on analysis of various crash logs and Papyrus logs, the crashes appear to involve references to ACTI base objects with locally attached scripts. These references and/or activator base objects can come from vanilla or from mods. It just so happens that DynDOLOD places references in the world to its own ACTI with a locally attached script, so they seem to be affected too: they're the 'victim' of the bug, so to speak, rather than the perpetrator. Your test results seem to confirm that. Furthermore, the crashes are random over time and space, and the few Papyrus logs that were examined point to some kind of in-memory data corruption at runtime. Static data like ESP/ESM plugins, if they are free of any error in xEdit, cannot by themselves cause such kind of runtime data corruption. It's much more likely to be caused by buggy code: Either native code from SkyrimSE.exe (extremely unlikely or it would have been experienced by many more users a long time ago). Or native code from SKSE or NetScriptFramework DLL plugins (DynDOLOD.dll included). Or VM code from compiled Papyrus scripts added or modified by mods. Or a combination of several of the above. You may want to read the other topic (A new crash I am trying to diagnose) in its entirety, particularly regarding the WARNING messages in the Papyrus log, which may be used as an indicator of corruption and as an "early warning system" of an impending crash. In that topic I also try to offer suggestions for troubleshooting.

Section 19-Utilities, second item: DynDOLOD 3 Alpha. Expanding it or following the Wiki link shows the following text (relevant bit highlighted in green):

Section 20-Patches, penultimate item: Step Patch - Conflict Resolution. Expanding it or following the Wiki link shows the following text (relevant bit highlighted in green): You're not making any sense: Files are there but you can't find them? You found the file but it's not the right one - which file? Please read carefully and follow these 3 simple steps: Go to https://www.nexusmods.com/skyrimspecialedition/mods/31054/?tab=files. Download the file named 'Step Grass'. It's listed on that page, at the very bottom of the page. Install 'Step Grass' as a separate mod and enable in MO2.

Nope. The DynDOLOD DLL NG crash is a completely unrelated issue. You can update to the latest version (Alpha-14) if you want (make sure to save your game in an interior cell beforehand) but that won't help in your case. You said your crashes were random and the logs involved different objects each time, but you only have provided one crash log so far. You may want to create a new topic for your issue and post multiple recent crash logs, while providing some context: what you were doing at the time of the crash, what was changed (if any) in load order before, etc.

Thanks for the tip! I can see how bookmarking would be useful in some cases while working in xEdit, but it's not very intuitive or efficient for navigating a tree-like hierarchy: it requires bookmarking every step of the way, remembering which bookmark/shortcut corresponds to which node/level in the hierarchy, and updating the bookmarks when traversing laterally. Too many steps and mental effort compared to a history of viewed pages with back/forward functions. Yes indeedy. That's my understanding as well. I tried to explain as much in my post, but it apparently got lost in the wall of text I realized it's partly wrong though, because I'm very bad at probability math. The correct outcomes for this particular example would be: In the best case the list will return a total of 15 items to the chest (0.75^15 = ~1.3% chance of happening), and in the worst case, it will return 0 items (0.25^15 = about 1 chance in 100 millions, practically never), with an average of 15*0.75 = ~11 items across all draws. I've updated my post above with these corrections.

Good question. I'm not aware of an easy way to navigate nested objects back and forth in xEdit. I wish there were 'Back' and 'Forward' shortcuts, and a history of viewed records, like in a web browser. Personally I write down the form ID of the record I'm viewing before drilling down the hierarchy, so I can go back to previous records later. It's a cumbersome hassle. Another way to navigate back is by using the 'Referenced By (n)' tab at the bottom of the record window, but it can list several possible paths back which doesn't really help. About your other questions, let's drill down the list chain from your example, and then go back up, the way the game would work: Belethor's Merchant Chest requests up to 15 items from LItemMiscVendorArmor75 [LVLI:0009AF07]. LItemMiscVendorArmor75 [LVLI:0009AF07] requests one item each from 5 sub-lists, one of them being LItemArmorCuirassAnyTown [LVLI:0001674E]. LItemArmorCuirassAnyTown [LVLI:0001674E] requests one item each from 2 sub-lists, one of them being LItemArmorCuirassHeavyTown [LVLI:00016747]. LItemArmorCuirassHeavyTown [LVLI:00016747] contains 16 entries, some of which are individual armor pieces, others are more sub-lists. The list has the 'Calculate from all levels <= player's level' flag. If the player is level 10 for example, the game will randomly pick an item among the first 8 entries from Level 1 to Level 8, rather than pick the Level 8 entry (closest to, and not greater than, level 10). Thus the list may return a low-level Iron Cuirass, even though the player is level 10 and better Banded Iron Cuirasses are available. The list has the 'Calculate for each item in count' flag. This has no effect here, because only 1 item is requested from this list. The list contains 4 identical entries for Iron Cuirass at Level 1. This is intended to increase the probability of returning an Iron Cuirass. This makes the Iron Cuirass 4 times more likely to be picked than if it were listed only once. One item has been selected from LItemArmorCuirassHeavyTown [LVLI:00016747]. Repeat the above steps for the other sub-list within LItemArmorCuirassAnyTown [LVLI:0001674E]. Then we're back to LItemArmorCuirassAnyTown [LVLI:0001674E] which now contains one randomly selected Heavy Armor Cuirass and one randomly selected Light Armor Cuirass. The list has 'Calculate from all levels <= player's level' flag. See above. The list has the 'Calculate for each item in count' flag. This has no effect here, because only 1 item is requested from this list. Repeat the above steps for the 4 other sub-lists within LItemMiscVendorArmor75 [LVLI:0009AF07]. Then we're back to LItemMiscVendorArmor75 [LVLI:0009AF07] which now contains one randomly selected Cuirass, one randomly selected Boots, one randomly selected Gauntlets, one randomly selected Helmet and one randomly selected Shield, of various qualities/levels. The list has the 'Calculate from all levels <= player's level' flag. See previous. The list has the 'Calculate for each item in count' flag. As the vendor chest requests 15 items from this list and each entry in this list has a quantity of 1, this causes 15 random separate item selections, rather one single item selection multiplied by 15. For example, the list may return 3 shields, 2 boots, 4 cuirasses, 1 gauntlets and 5 helmets. If that flag wasn't set, it could return 15 identical helmets, or 15 identical boots, etc. The list has a 'Chance None' value of 25. There is a 25% chance the list selects nothing. As the 'Calculate for each item in count' flag is set, this applies to each random selection. So in the best case the list will return a total of 15 items to the chest (0.75^15 = ~1.3% chance of happening), and in the worst case, it will return 0 items (0.25^15 = about 1 chance in 100 millions, practically never), with an average of 15*0.75 = ~11 items selected across all draws. You can use the Creation Kit to see how the leveled list behaves inside the chest: Enter the list Form ID in filter field. Double-click the list found. In list panel, enter desired player level and number of items. Click 'Preview Calculated Results'. See also https://en.uesp.net/wiki/Skyrim:Leveled_Lists.

Your Papyrus logs contain the same "WARNING: Missing or zero refcount on when releasing" as Soulmancer's, with different Form IDs. In the logs you posted, all the Form IDs point to vanilla ACTI objects (activators) with attached scripts: all but one are mining deposits, the other one is a word wall. I was suggesting this is due to memory corruption (not leak), or in-memory data corruption if you prefer, over time as you play the game. A buggy component is overwriting good data with random/garbage data. Data used by the Papyrus VM for its internal scripts housekeeping. When a save file is reloaded during gameplay the VM needs to clean up its current gameplay state before it loads the save (as opposed to a save being loaded right after launching the game, where the VM starts in a "blank" state). The crash occurs during the cleanup phase. There are no objects or Form IDs listed in the crash logs because no plugin objects are involved: this happens entirely within the VM's internal housekeeping. Which goes boom because it finds and uses garbage data instead of good data. This is only conjecture. I don't know what's really happening and I reckon trying to explain it is not very helpful. I think the peculiar warnings in the Papyrus logs are correlated with the crashes, and could be used as a troubleshooting point. The VM warning is telling something is unexpected and wrong when "releasing" (presumably releasing memory used by scripts attached to objects) during the cleanup phase, a telltale sign that memory corruption has occurred during gameplay, and it precedes the crashes. For troubleshooting, I'd suggest using the standard process of elimination by disabling mods (not only plugins, but entire mods if they contain loose scripts). You could focus on the most likely culprits first: SKSE plugins. Mods containing scripts. Mods that you added or updated since before the crashes started occurring, and which fall into the previous 2 categories. Test with Papyrus logging turned on, play for a bit, save and reload without restarting the game, and keep an eye on the logs for "WARNING: Missing or zero refcount on when releasing" messages. I don't think your issue is/was the same as that originally discussed here. Yes it's related to Papyrus VM too but it's a different issue. If it's resolved, I'd bet it was caused by using SpeedUpNativeCalls = true with Papyrus Tweaks NG.

Yes, it's exactly the same crash and circumstances as Soulmancer. Your crash log shows the Papyrus VM crashed while loading Autosave3_28DD73E7_0_546F7276616C64_GraywinterWatch01_000654_20240216114521_10_1.ess. Can you try to reproduce with Papyrus logging turned on? Post the Papyrus log so we can take a look. It'd be interesting to see if it contains similar "WARNING: Missing or zero refcount on when releasing" messages. No, I don't think so. The issue with VSMO caused functional breakage but couldn't cause crashes, AFAIK. Also the issue existed depending on which version of USSEP was used, independently of runtime version. I know for a fact that incorrectly programmed Papyrus scripts can in some cases cause memory corruption and crashes sooner or later, as I experienced it once with one mod. I don't remember the exact details other than the script used out-of-bounds elements in an array, but the resulting crash and its timing wasn't at all like the crash being investigated here. This was a big discovery for me as until then I had assumed the Papyrus VM was memory-safe (like JavaScript for example), but evidently it's not. FYI Soulmancer here is Kulharin on Nexus. Same person, same crash as they reported here.

More likely trying to use the light plugin with 3rd-party patches made for the full/fat/normal plugin. Right. Some 3rd-party patches were updated to work with the light plugin - those are another solution, if available.