Mousetick

Version compatible with latest runtime: Oxygen Meter 2 - 1130-1170 Updated DLL (not standalone, requires and overwrites this mod) Mod has been officially updated: enhancements and fixes, compatible with latest runtime.

The Virtual Folder Explorer only shows loose files. BSA archives are shown as simple files. The contents of BSA archives are not shown. If a texture is stored in a BSA file, it would not be visible by browsing with the Virtual Folder Explorer. There is no Best of Both Worlds patcher to downgrade from 1.6.1170 AE (latest downgrade available is from 1.6.1130). We don't know where your helgenmud01.nif comes from. Is it the vanilla mesh from Skyrim - Meshes0.bsa? How did you determine that this is the mesh used in-game? How does the textures look when the mesh is opened in NifSkope? Are you using mods? Are you using Skyrim Landscape and Water Fixes? Have you tried without any mods (other than USSEP)?

See https://dyndolod.info/Help/Terrain-LOD-and-Water-LOD for an explanation. Basically terrain LOD includes the ground and water. By switching from MM to ERM you probably removed the MajesticMountains_Landscape.esm plugin from your load order? You should re-generate the terrain LOD with xLODGen to account for that change, otherwise the distant terrain won't match the close terrain. If you re-generate terrain LOD, you should also re-generate object LOD with DynDOLOD because the latter is optimized based on the former. No, that's not necessary.

I have no idea what the screenshots are supposed to show, but it's not your fault I hate the conflict highlighting of MO2 (the one which occurs on the left side). The constant colored flashing on/off like a Christmas tree as I click on different mods in the mod list, drives me nuts. I have learned not to pay attention to it and try to ignore it but it's still very distracting. So it's the same with this mod on the right side. This is not useful information, especially in a long list that's only partially shown. The +/- conflict icons are much more interesting and useful to me. And they're a lot clearer/meaningful, compared to some colors like cyan or magenta.

That's the dynamic LOD of the glow object, created by DynDOLOD. Edit DynDOLOD.esp and remove the reference shown in the last console screenshot. Don't flag anything as Deleted. Completely remove the REFR record from the plugin. You could try hiding the NIF mesh file (/meshes/effects/FXSolitudeLightHouseGlow.nif) in your mod manager but that's not really possible in this case as it's stored in the vanilla BSAs. Or you can try to overwrite it with a loose copy, edited to remove the effect.

I initially didn't fully understand what this mod does and was a bit skeptical of its overall usefulness. I haven't tried it, but following your conversations here and on Nexus, I got a much better picture - thanks I have to admit, I'm now even more skeptical of its usefulness when used with standalone LOOT (where the plugin grouping is normally managed). As for the other main features: The visual indication of (certain) record conflicts is nice, but redundant with checking for conflicts in xEdit. The visual indication of asset conflicts in BSAs is nice, but it's not a complete solution, as it doesn't take loose files into account. The lack of visual indication of ESP/ESM and light/fat plugin type is a big omission and a step back IMHO. In my case, I check for asset conflicts (BSAs + loose files combined) on the left side of MO2, I check for record conflicts in xEdit, and I do all the plugin sorting/grouping in standalone LOOT. This mod doesn't add anything I was missing, it doesn't make the tasks easier or more dependable, but it is removing important information I rely on. So I'll pass for the time being.

The FXSolitudeLightHouseGlow reference has an Enable Parent (not shown in your xEdit screenshots because they clip the bottom of the records, but shown in the console screenshots). You can't directly enable/disable a reference that has an Enable Parent - that's by design and why your attempts in xEdit or in-game via the console don't work. Solution: In xEdit, either remove the 'XESP - Enable Parent' field of the reference, or change it to Opposite of PlayerRef (ID 00000014).

AE CC modules are downloaded from Bethesda.net servers by SkyrimSE.exe, not from Steam servers by the Steam client. Steam doesn't know about these files, so they are ignored by 'Verify integrity of game files' and it has no effect on them.

If you already disabled DynDOLOD and that didn't make a difference, switching to DynDOLOD DLL NG wouldn't help. What about your grass: grass mods, grass cache (or lack thereof), grass settings? Also: memory (OS or GPU) usage?

I think that's true but I'm also wondering if doziness and lack of energy to focus are not the subconscious manifestation of the other intertwined factors. Like you said: chicken/egg. So I'm not sure it should be something to worry about or be bothered by, assuming it doesn't degrade quality of day-to-day life. Indeed. I think this perception of time accelerating is another contributing factor: how we choose to spend the limited, shortening time that remains, and the anxiety that that generates.

According to scientific research, sleep is supposed to be good for the brain and its cognitive functions. I believe it. Also taking regular breaks and walking are supposed to be beneficial. I believe that too. IMHO, awake and alert time is necessary to learn, but not sufficient. There are other factors, some of which you mentioned, that are linked. One is interest in the subject matter and the motivation to invest time in it, which is rather subjective or contextual. Another is the ability to grasp unfamiliar new concepts and paradigms, which seems to diminish as we age - our brain has become "wired" in certain way and it's more and more difficult to "rewire" it. Another is how we prioritize cognitive resources as adults: we may unconsciously put certain matters (e.g. job/housing/family/...) in front of other, less important topics and dedicate fewer resources to them. Lastly, I think learning is not useful if it's not based on understanding and applied in practice. It's boring and tiresome. Without understanding and practice, it's just accumulated knowledge, it doesn't make us "smarter": it doesn't increase our ability to analyze and recognize situations, solve problems, invent new ideas, and learn more in the process - that is, our expertise, or more commonly, our experience. I'd argue that attempting to forcefully stuff the brain with a chunk of raw knowledge contributes to doziness, at any age. Also, the more complex or unfamiliar the subject matter is, the more it needs to be broken down and articulated into smaller pieces, recursively until each piece becomes easy to grasp. Learning can then be accomplished step by step, each requiring a shorter attention and less cognitive energy, with breaks in between to internalize and revitalize. Disclosure: I'm in my late 50s and I routinely take naps

It's not exactly a base game issue. So you were able to successfully complete the 'Game-Launch Smoke Test' at the end of 02-Extenders at some point? Do you confirm? I don't understand what you're talking about. I'll try to explain as clearly and simply as possible: You have a mix of Skyrim SE 1.6.640 files with Skyrim SE 1.6.1170 files. The 1.6.640 files are the ones you downloaded from Steam console and copied over to the game folder, overwriting. The 1.6.1170 files are the AE CC modules you initially installed, which are not included in base Skyrim SE (and were not overwritten by the "downgrade"). These AE CC modules require Skyrim SE 1.6.1170. So it's logically not possible to run the game from the Skyrim Launcher, because the AE CC modules do not work with SkyrimSE.exe 1.6.640 and vice-versa. There is nothing "wrong" with that, as such failure is expected. This is not a useful troubleshooting step. The absolute minimum setup that can run a downgraded Skyrim SE with a mix of 1.6.1170 files is: SKSE (as described in the STEP Guide) Address Library for SKSE Plugins (as described in the STEP Guide) Backported Extended ESL Support (not part of the current Guide, install in mod manager like other SKSE plugins) The above set + the game files obtained from Steam are the new base game. It can only be run by launching it with the SKSE Launcher. Go back to a mod setup where you can successfully run the new base game, then the new base game + the complete set of 02-Extenders, and then successfully complete the Game-Launch Smoke Test procedure. You don't need to uninstall/reinstall anything, just disable mods in the mod manager to trim down the setup. Ignore the previous advice about changing some settings to 'false' in the EngineFixes.toml configuration (they don't apply here, they're for users running SkyrimSE.exe 1.6.1170, but you're running SkyrimSE.exe 1.6.640). They can all be left at their default values, which is normally 'true'. Once you have confirmed you have a sane and functioning new base game + 02-Extenders setup, then we can start actually troubleshooting what your actual issue is. For a proper "Best of Both Worlds" downgrade, you should only overwrite 1.6.1170 files with 1.6.640 files in the root Skyrim Special Edition game folder while leaving the Data subfolder intact. There are actually only 3 files that need to be downgraded by overwriting with 1.6.640 copies: SkyrimSE.exe SkyrimSELauncher.exe steam_api64.dll Everything else should remain exactly as it was initially installed/updated by Steam, that is version 1.6.1170. The whole Data folder should not be tempered with.

Any luck finding the culprit yet, or any progress on the troubleshooting? Googling "WARNING: Missing or zero refcount on when releasing" doesn't find much of anything, unfortunately. That's unfortunate. These Papyrus warnings may be a red herring but they're quite unusual. And based on the small sample of logs you provided, they always precede the crash. There are other occurrences of the same warning (with different Form IDs) at various points throughout the logs, always immediately following a "Reverting game..." message as far as can tell. I think "Reverting game..." is printed when a previous save is reloaded. Some of the Form IDs are prefixed by FF (e.g. FF00224A, FF002BC0). They are dynamically spawned references so we don't know what they are. Other Form IDs are vanilla references such as 0010ED38 or 0010ED36. I checked a few of them in xEdit, they're all references to ACTI base objects, such as ore or clay deposits, which have local scripts attached. My wild guess is that something (could be a faulty script) is corrupting the VM's internal data structures during gameplay. When a game save is reloaded, the VM cleans up its memory by freeing up script instances. It finds unexpected garbage (Missing or zero refcount) but still goes ahead and accesses a bogus memory block, leading to the crash. Have you tried opening a game save in ReSaver? It'd be interesting to see if the save file itself is healthy or not. -- Unrelated to the crash issue: You have some scripts missing. Check the "Cannot open store for class" messages at the beginning of the Papyrus logs. For example, shovelbodymcmscript and ShovelBodyAliasScript are part of Shovels Bury Bodies and are necessary for it to function. It looks like you have that mod's plugin in your load order, but its scripts are not installed somehow, which would be a user error. Other scripts may be missing simply because a mod was shipped without them and is broken as a result, or because its plugin still references them although it doesn't really need/use them, which are mod author errors.

If you find that the game still gives out too much loot overall, despite having resolved whatever issue you had before, I'd heartily recommend you give Simply Reduced Loot a try. It's extremely lightweight (no scripts) and simple. It works by increasing the chance that a loot leveled list returns nothing. So for example if a loot chest asks for 1 leveled gem, 1 leveled scroll, 1 leveled weapon and 1 leveled potion, it might only be filled with 1 leveled gem and 1 leveled potion, or 1 leveled weapon and 1 leveled potion, randomly. This only affects generic loot, not unique artifacts, so you can still obtain them as usual. There are 2 versions: 33% or 66% reduction (that is statistically speaking - you can still get a full set of loot items depending on RNG - but on average across the entire game you'll get one or two thirds less loot than vanilla). There are 2 modules: one for loot per se (found in chests or in boss inventories), and the other one for merchants' inventory. I've not used the merchant module but it works exactly the same way. The bad news is that it edits a lot of leveled lists. The good news is that it doesn't modify the contents of the lists, only the probability to return nothing. There are compatibility patches available but they're probably outdated and cover very few mods. Since you're now patching leveled lists manually rather than relying on WryeBash, you can simply ignore the leveled list contents and only forward the 'LVLG - Global' field from Simply Reduced Loot to your custom patch, which is straightforward and doesn't require any thought. If you wish to use another rate of reduction than 33 or 66%, you could adjust the probability to your liking by editing a small set of global variables that are used throughout the leveled lists. Other mods, such as Morrowloot or Open World Loot, limit the quality of loot rather than its quantity throughout the game, including the type of equipment carried by NPCs. But they provide other features (e.g. deleveling the world or increasing encounter zone levels) which may be undesirable, and their leveled list implementation is more complex, making patches more difficult to find or to make. I've been using OWL because it's lightweight, it's designed for WACCF weapon tiers so it fits naturally, and I could find patches for the weapon/armor mods I use. It can be used together with Simply Reduced Loot as they do and modify different things (quality vs. quantity). Yet other mods, such as Don't Roll In That - NPC Loot Reduction, limit the quantity of common loot by preventing equipment from being looted off corpses. I don't have any experience with those.

This is a vast and complicated subject, even more so when WACCF is used. I'm surprised by your observations about loot. The approach you took to resolve specific leveled list conflicts should have no significant impact on the quantity of loot you find. In most cases, the edits that the aforementioned mods (WACCF, CACO, CCOR, AMB CA) make to leveled lists only affect the type of loot per level, not its quantity. For humanoid NPCs, the quantity of loot is determined by their inventory (defined in NPC_ record) and outfit (defined by OTFT record referenced by NPC_ record). For creatures and animals, the quantity of loot is determined by their death items (defined by DeathItem[...] leveled list referenced by NPC_ record). For chests, the quantity of loot is determined by their contents (defined by CONT record, itself referencing Loot[...] leveled lists). CACO does make a lot of changes to some of the above but they're balanced and designed to work with the overall alchemy/cooking overhaul, and they typically don't conflict, so let's put it aside. Other than that, WACCF, CCOR and AMB CA either don't directly edit the above, or they edit them without changing the quantity of items found. The leveled lists that WACCF, CCOR or AMB CA touch are typically referenced indirectly and they return only 1 item per level. Even if they were incorrectly merged with vanilla, or with USSEP changes, they would contain the wrong type of item per level, but they would still return only 1 item per level. I suspect that the "too much loot" behavior before changing your patching methodology is caused by something else. The "much reduced loot" behavior you observed after might be a coincidence - it's hard to say. But instead of trying to reason in generic terms, I find it easier to look at specific examples using the latest version of all mods: LItemGems [LVLI:00068525], LItemGems75 [LVLI:001046E3], LItemGemsSmall [LVLI:000F961D], LItemGemsSmall10 [LVLI:0010E0E0], LItemGemsSmall25 [LVLI:001046E2], LItemMiscVendorGems25 [LVLI:0009AF0C], LItemMiscVendorGems100 [LVLI:000C44A7] Conflict between CACO and CCOR: both mods' additions should be merged, otherwise one or the other won't ever be found in loot or in merchant's inventory. It may look like the list contains more "stuff", but it still returns the same quantity of items per level. The quantity is determined by whatever is referencing those lists, not by the lists themselves. The fact that both kryptopyr mods conflict and no patch is provided by kryptopyr is a bug. The bug was reported and acknowledged more than a year ago (see "Gemstone levelled list incompatibility with CCOR" in CACO bug section). LItemEnchArmorLightGauntlets [LVLI:000B4223] and LItemEnchArmorLightGauntletsNoDragon [LVLI:000FDA14] Conflict between CACO and AMB CA: both mods' additions should be merged, otherwise CACO's unique enchanted alchemy gloves won't ever be found. Same as previous. Likewise, looks like a bug to me. LootCitizenChildToysList [LVLI:001046E7] and LootCitizenChildToysList75 [LVLI:001046E9] Conflict between WACCF and CACO: both mods add their own version of BugsInJarList, only one of them should be kept. Doesn't matter which one, as their contents are identical. CACO is one kryptopyr mod that (strangely) doesn't require WACCF, so it duplicates WACCF here. If you keep both BugsInJarLists you'll find a Bug In Jar item twice as often as if you keep only one, but you'll still find the same number of Bug In Jar at a time. This list is referenced by children NPC inventories, so unless you routinely pickpocket children, it won't matter much at all in the end. LItemFoodInnCommon [LVLI:00098E5F], LItemFoodInnCommon10 [LVLI:0010E0E1] and LItemIngredientFoodPrepared [LVLI:00087135] Conflict between CACO and USSEP: the USKP Meat Pie should be added to CACO's version of the list, otherwise it won't ever be found in Innkeepers' or Food Vendors' inventory. This is covered by the USSEP - CACO patch from kryptopyr's patch hub, in a different way, but the end result in-game is the same. RecipeArmorGildedElvenCuirass [COBJ:000DCA0A], TemperArmorGildedElvenBoots [COBJ:000EB789] and other TemperArmorGildedElven[...] Conflict between CCOR and AMB CA: AMB CA should win and CCOR should be ignored. You could let CCOR win the crafting recipe, but then it would be inconsistent with the other Elven Gilded recipes added by AMB CA. Also even though CCOR changes temper recipes these recipes produce nothing in vanilla or CCOR because the corresponding armor pieces don't exist. Regardless, it would make no sense to merge them (this is true in general for COBJ records). Since AMB CA should be sorted after CCOR, there is really no patching necessary here. LItemBlacksmithArrows75 [LVLI:0009BC2F] and LItemWeaponBowBlacksmith [LVLI:0009BC3F] Conflict between WACCF and AMB CA: WACCF additions should be kept and forwarded to AMB CA's version of the list, otherwise crossbow and bolts won't ever be found in Blacksmiths' inventory (even if the crossbow integration option is enabled in CCOR). This looks like a bug to me again. Might be a consequence of the recent leveled list shuffle in WACCF/CCOR/AMB and the decoupling of AMB from CCOR. DLC2LItemEnchArmorLightHelmet [LVLI:0402BBFE], DLC2LItemEnchArmorLightHelmetSpecial [LVLI:0402BC2B] and DLC2LItemEnchArmorLightHelmetNoDragon [LVLI:0403750B] Conflict between WACCF and AMB CA: AMB CA removes the sublists added by WACCF and replaces them by its own sublists containing "Morrowind-flavored" versions of the enchanted glass helmets, to be found specifically in loot on Solstheim. You could merge the additions from both if you wanted (although it's not the result intended by AMB CA), it wouldn't break anything: both sublists have the same quantity and level, so it would just mean you could still find plain Skyrim enchanted glass helmets on Solstheim. As you can see the conflicts are few and relatively minor. Even if the conflicting leveled lists were incorrectly patched, this would make no difference in the quantity of loot found. Only the type of loot encountered, or never encountered as the case may be. So I'm not sure where the perceived difference in quantity of loot is coming from. Furthermore I don't understand why you stopped using patches. Typically the patches from kryptopyr patch hub are quite good and necessary to patch weapon/armor mods that are not WACCF-dependent or WACCF-compatible. Even mods that claim to be WACCF-compatible manage to mess things up in some way or other. You don't have to keep the patches in your load order: you can simply use them as "blueprints" while incorporating their changes into your manual patch, then remove them. You can ask about specific conflicts or mods you're using, if you want, so we can take a look at what might be going on. Lastly as regards to Bashed Patches and WACCF: WACCF comes with a special plugin WACCF_BashedPatchLvlListFix.esp that is intended to correct WryeBash's mistakes processing leveled lists edited by WACCF (see Installation section on the WACCF mod page for usage details). I don't use WryeBash so I can't speak to the effectiveness of this special plugin, but I suppose it may be adequate. I wonder what happens when adding AMB Content Addon into the mix though, for example, since AMB CA is intended to override some WACCF changes, or when adding other mods into the mix, for that matter.

Yes double-clicking on the name of the plugin is a valid method to open that plugin in xEdit. The messages on the right half of the window show the loading progress of the plugin you selected as well as of those plugins upon which it depends (such as Skyrim.esm, Update.esm, etc). Simply wait until the messages stop with the last line: "Background Loader: finished". At that point the plugin you selected will show as the last entry in the list of plugins on the left half of the window. Continue following the instructions in the guide, at step #2.

They are re-created each time you run the game because they don't exist, from the game's vantage point. Enable the 'empty' mod(s) (now no longer empty) in which you put the INI files you took from Overwrite. You enable them by ticking their checkbox on the left-hand side of MO2. This will stop the INI files being re-created in Overwrite. After enabling the mod(s) containing them, the game will then "see" that they already exist, and use them. The left-hand side of MO2 works like a virtual Data folder for the game. What is enabled is visible to the game, whereas what is disabled doesn't exist from the game point of view - when the game is run from the mod manager. Overwrite is implicitly always enabled, but it's not recommended to leave stuff hanging in it. It's better to move its contents to one or several specific mod folders just like you did - as many or as few as you wish. Or you can simply redirect the SKSE Launcher output into a mod folder, as Z suggested above, which will store any game-created file into that folder instead of Overwrite.

You're making it more difficult to help you by being too vague. "It is... busy": What exactly is busy, when and where? "The papyrus logging is busy" doesn't make any sense to me. 000#####: Is this what is literally written in the papyrus log, or is there a specific Form ID with actual numbers/letters? Load up your entire load order in xEdit, look up the record with the given Form ID, check what overrides it and what uses it. The list of things that use the record can be seen on the 'Referenced By (n)' tab.

The trainwreck log shows the Papyrus VM crashed while loading the manual save Save121_2A78DFB9_1_596F6C6F68_ndcIdemdallOutpost_001354_20240124232126_5_1.ess.

Definitely something to do with the Papyrus script VM. Perhaps when saving the game, apparently. Do you have Autosave on Travel enabled? Autosave on Travel enabled + crash when saving scripts in game save = crash when transitioning between indoor and outdoor. That's not to say Autosave on Travel is the cause or is faulty, it would merely be the trigger. Can you reliably perform manual saves?

A simple Google search for skyrim ussep 1.6.640 would have given you the answer. The first result for me is a reddit post. Link to download Nexus archive of USSEP 4.2.9a compatible with SSE 1.6.640: https://www.nexusmods.com/skyrimspecialedition/mods/266?tab=files&file_id=392477

Your freshly reinstalled from scratch Skyrim SE is version 1.6.1170 which was released on Steam just a few hours ago. LOOT doesn't know (yet) about this new version, so it may look like the vanilla masters are clean, even though they are not. Do not rely on LOOT to determine if vanilla master plugins are clean or not. It's not a reliable source (see spoiler below for details). Run xEdit QuickAutoClean on all the vanilla master plugins anytime the game or the CC content is updated.

This looks very similar to an old issue (description and resolution) which was fixed in Alpha 107 (Changelog: DynDOLOD.exe - fixed not clamping mipmap generation). I don't know if this information is helpful, as it could be the same effect from a different cause rather than a regression, but I'm pointing it out just in case.

Done.

Thanks for the pointer, sheson. xEdit 4.1.5b, with the fix for this bug among other changes, is available for download in the xedit-builds channel of the xEdit Discord server. ESM plugins in the load order that override temporary objects and that were edited or autocleaned with xEdit 4.1.5, need to be resaved with 4.1.5b or later (or with 4.0.4) in order to "repair" them.