Mousetick

If the objects are added by the mod itself, as opposed to being added by another master and overridden by the mod, and they're not used by anything else, you can simply remove them completely from the plugin - as if they were never there in the first place. Adding new objects permanently disabled (UDRs) to the world doesn't make sense and is just useless bloat, they might as well not exist at all.

For the inventory bloat, there is no good solution but this mod Hide Quest Items in Container Menu, which I use, alleviates the issue somewhat, with some small caveats. There are more drastic and riskier approaches that I haven't tried, such as Remove Quest Items or Let Me Drop It (Removable Quest Items). As for CC quests, I don't play with any CC content but I know there are a few mods that try to address the issue. For instance: Rebalancing Anniversary Edition - Quest Requirements, which delays each CC quest until a specific configurable player level is reached, similar to Timing Is Everything. It's not very immersive, but it allows for spreading the quests over an entire playthrough, or for delaying them until you're ready to tackle them (i.e. initially set minimum level to 100, then change it to your current level when you want it to start). Fewer quests started early also reduces the inventory cluttering by useless quest items. Lastly, as a general way of decluttering the quest log, I'd suggest Hide Those Futile Quests SE. This is merely an organizational/cosmetic tool, it doesn't affect the quests themselves.

I didn't read everything but it looks like you need another MO2 instance. Profiles share most data between them, while instances are completely separate. Each instance can manage multiple profiles: Instance A Profile A1 Profile A2 ... Instance B Profile B1 Profile B2 Profile B3 ... ... This video guide may help: Profiles VS Instances | Mod Organizer Guide Skyrim. Beware multiple instances can require a lot of disk space for mod storage, as a same mod present in different instances is effectively installed as multiple copies of the same mod, one copy in each instance. No, that's not expected. The 'enabled/disabled' status of a mod is per-profile. The same mod can be enabled or disabled in different profiles. That is the main purpose of profiles. Yes, that's how it's expected to work. Different profiles of a given instance share the same mod. Installing a mod adds it to all profiles, uninstalling it removes it from all profiles (of a specific instance - other instances are not affected if they contain the same mod, as it's a separate copy of that mod). This is normal and expected. All profiles of a given instance share the same Executables configuration. To configure different executables for use by different profiles, either create a new executable (e.g. "SKSE for Profile #2") and manually select it to launch depending on which profile you're using, or use a separate instance, which uses a completely separate Executables configuration.

The NPC yelling "No more! I yield, I yield" are almost certainly not falling from the sky, they're rather fleeing from a threat. This normally shouldn't happen inside walled cities unless random hostile events are enabled, which you've ruled out. Blood on the Ice murders happen behind the scenes, except the last one you're supposed to catch at night. I don't think this is related to the random deaths you've noticed, however it may be linked to the strange noises you're hearing when switching between indoors/outdoors. The perceived threat could possibly be you, the player. I can't think of any rational explanation for the strange noises, so something must have gone out of whack, somewhere at some point. If I were you I'd either leave the area (Windhelm) for a while and come back later to see if the weirdness has cleared up, or I'd load earlier saves to try and determine when/where the weirdness started.

About the seemingly random killings of civilian NPCs, I have experienced them in the past and observed 2 possible causes: 1. NPCs victims of random hostile events. Depending on quest progress and mod setup, vampire or dragon attacks randomly spawned inside cities. I think dragon attacks inside cities were disabled by Bethesda at some point in vanilla Special Edition, but there are mods (such as Dragon Attacks) to re-enable them. Similarly I think vampire attacks inside cities were disabled in vanilla SE, but they can be re-enabled with mods like Timing Is Everything. Run For Your Lives reduces the risk of casualties in these events but doesn't eliminate it. If you use mods like Extended Encounters or Immersive World Encounters, that add new types of random encounters, they may also spawn hostile events inside cities or near towns and settlements. 2. NPCs falling to their death from the sky. Even with SSE Display Tweaks and rendering at less than 60 fps, I'm still experiencing NPCs and creatures randomly suddenly appearing in the sky and then falling to the ground, from time to time. I don't know what causes that and there doesn't seem to be a pattern, it's probably the wonky physics engine. It doesn't happen often enough to bother me, but when it does happen the NPC logically dies on impact. Yes, it's immersive and realistic that innocent NPCs can accidentally die but ultimately I didn't like that. Skyrim is too sparsely populated as it is, I don't want events outside of my control to decimate the civilian population even more Suggestions: You can use Obituary - NPC Death Log and Notification to be notified as soon as an NPC dies. The mod can teleport you to the NPC so you can investigate and maybe see the cause of death. The teleportation feature is not immersive, but can be useful for troubleshooting or understanding what went on. The mod can also resurrect the NPC, but I'd advise caution in using this feature as I'm not sure how well the game handles resurrected NPCs. Make unique NPCs 'protected', so they can't die unless the player kills them. There are several mods available for that. They're adequate with vanilla NPCs and quests, but if you use mods that add NPCs and or quests, or mods that modify vanilla quests, they fall short and can be a hindrance because they break scripted deaths. After a while I got tired of fiddling with those mods so I made my own patch, tailored to my specific mod setup, to protect innocent vanilla NPCs that are not supposed to die outside of my control (most of them, but there aren't many vanilla NPCs to begin with). No clue about the strange noises you're hearing. Perhaps a script that triggered the sound and should have stopped it at some point, is stuck and still running. Does the noise follow you as you move, does it change in volume, does it stop in interiors? Check your active magic effects in case you have something stuck on your character.

I've been using this for a while without issues, there have been many updates since it was released. It looks good to me and I like it. It includes custom LOD models and supports Just Ice out of the box. Works great with DynDOLOD. There are many options to choose from. I've been using 'High Poly Consistency' full meshes, 'Low Poly' LOD meshes, 'Icy Fixes Full' plugin, 'Icy Fixes High Poly Backlight' meshes, 'Just Ice - Less Dark' brightness. I haven't tried any of the partitioned stuff (to prevent light flickering), or the icy caves meshes, which were WIP and incomplete for a long time but are now apparently finished. Notes: I'm using Simplicity of Snow rather than Better Dynamic Snow. This mod comes with a patch for compatibility with BDS, I don't know if it's any good. Probably obvious, but just in case: Mutually exclusive with Glaciers LOD Meshes. This mod does the same thing and a lot more.

Discussion topic: Advanced Notification Log NG by MaskedRPGFan Wiki Link Keeps track of notification messages and displays, in an MCM, a log of all messages emitted during a session. So you can go and look at past notifications to see if you missed any. Latest version can also manually or automatically save to a file. Suggested notification mods to go with it: Configurable Notification Messages (by MaskedRPGFan) Diziet's Murder Notification (by diziet) Informed Mail Delivery (by Glanzer) Notification Filter - Remove unwanted notifications (by miere) Obituary - NPC Death Log and Notification (by asdasfa) I use all of the above

Objects that look like they're covered in shimmering white/grey paint: usually caused by Parallax textures used with non-Parallax meshes (or vice-versa?). Assuming ENB is also used to enable Parallax.

I use it, it's fine. As a SKSE plugin, you can try it and remove it anytime, it's harmless. It needs some fine-tuning to blend in perfectly with each specific water/weather/ENB setup, which I haven't done because I'm lazy. I only reduced the size of the ripples and splashes which were too big for my taste - easy to do in the config file.

The Mysterious Disappearance of Solitude Trees Finally Solved! (Not really) Fellow community member @MisterMorden and I have been investigating a visual issue that has been plaguing bothering distracting us for a while. It's about trees that are visible in the distance on the mountain cliffs behind the north-side walls of Solitude, and then disappear as the player gets close. What we have managed to determine when DynDOLOD is not used: There are trees added by USSEP in the cells behind the Solitude walls inside the Solitude worldspace. There are no trees there in vanilla. They are neverfades (Persistent Is Full LOD references) so their full models are normally loaded and visible from anywhere in the Solitude worldspace. When adding DynDOLOD into the mix: DynDOLOD.esm UDR-disables those trees from USSEP. So the full models are never loaded/visible. This is apparently driven by USSEP-specific rules in DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. There are (object) LODs for trees that are visible from a distance, and unload when the player gets close. Screenshots to illustrate: USSEP Only Far View > USSEP Only Far View Disabled >USSEP Only Near View USSEP + DynDOLOD Far View > USSEP + DynDOLOD Far View No LODs > USSEP + DynDOLOD Near View Misc. additional remarks: The tree LODs present when using DynDOLOD are apparently for trees that are in the Tamriel worldspace, they're not at all related to the trees placed by USSEP in the Solitude worldspace. Both Mr Morden and I are using Ultra Tree LODs. The Solitude Exterior option of DynDOLOD Resources makes no difference, with or without. Mr Morden is using an unknown version of DynDOLOD 3 Alpha, with LR Bugs Workarounds, while I used Alpha 118 without LR Bugs Workarounds for the tests and screenshots above. I've seen this issue for as long as I can remember since I started using DynDOLOD, going back to Alpha 60 or thereabouts. Questions: Can you confirm our findings and would you agree this is an issue, or at least an unexpected visual behavior. Is this the way it's supposed to be, or have we messed up somewhere? What would be a solution? What if we duplicated all the tree references from Skyrim.esm in Tamriel worldspace to their corresponding cells in Solitude worldspace, as normal, temporary references? Thanks. Full logs here if you need them: https://drive.google.com/file/d/1fSSsY4qewQzm7ygNqgYUYGHO4eGYhC7t/view.

Ok, done. Thanks.

There appears to be a gap issue at the junction between cells -38, -3 (00007605) and -38, -4 (00007624) in the Reach, between Smooth Shores which changes the landscape of both, and Landscape Fixes for Grass Mods, which only changes the landscape of the former, and wins in load order. This is mostly noticeable when crossing the river coming from the north. Circled in red in screenshot below. The landscape of either cell is not covered by the 'Smooth Shores - Landscape Fixes for Grass Mods Patch', as far as I can tell. I can write a bug on Nexus if you like, though I'm hesitant to do so until someone else confirms the issue. Thanks.

You posted your questions/issues in the STEP Guide forum. Are you following the Skyrim SE STEP Guide or not? If you are, there should be no need for you, or way for that matter, to generate the grass cache. I'm asking to better understand the context. If you are not following the STEP Guide, which instructions are you following to generate the grass cache, if any? Are you using the 'PreCache Grass' plugin in MO2? Which version of Skyrim SE are you using for playing? Are there files named Tamriel*.cgid in your grass cache mod folder? Do you get full near grass (i.e. not grass LOD) in Tamriel? We need a lot more information in order to help you. If the grassprecache.txt file still exists, the grass precaching has not completed. Skyrim SE by way of NGIO automatically removes this file upon successful completion. When the completion is successful, the MO2 'PreCache Grass' plugin displays a popup saying "Grass precaching completed. - The grass caching operation was completed successfully". This popup is displayed only when the grassprecache.txt no longer exists. If I'm not mistaken and I'm remembering correctly, there are 2 popup messages at the end of a successful precaching: one from Skyrim SE itself (I don't remember the exact message off the top of my head), and the other one from MO2's 'PreCache Grass' plugin. Each one has a button to dismiss them. You need to dismiss the Skyrim SE popup first, then switch to MO2 and dismiss its popup. It can be confusing at first because Skyrim SE popup message is often hidden behind other windows, or it's visible but it doesn't have the focus, so can't be clicked on. So I'd recommend keeping Skyrim SE in the foreground while generating the grass cache. That way you don't miss its popup message when it's done. If you still don't see it, minimize all windows to the taskbar so you can see the desktop. The Skyrim SE popup should be somewhere visible and accessible.

What is the bug that you're talking about precisely? The inability to block while dual-wielding is not a bug, it's a "limitation". The block control/key being the same as left-handed weapon when dual-wielding, it's not possible to choose between the two. The limitation is designed into the game from the start. You could blame it on the consolification/casualization of Elder Scrolls games, or on Bethesda's ineptitude - nevertheless, the game works as intended in that regard, it was never considered a bug. The mods you listed address different unrelated issues: Bash Bug Fix attempts to fix a bug where the damage calculation produced by a bash attack is incorrect. I'm not familiar with this particular issue. But it has nothing to do with dual-wielding. The other 2 mods remove the aforementioned limitation either by using a separate, dedicated control/key for blocking, or respectively, by using the same right-handed control/key for both left-handed and right-handed weapons, hitting randomly with one or the other.

Your interpretation of that xEdit script is mostly correct, but you're confusing the count of things with their values. And despite acknowledging DY's distinction between records and FormIDs, you're still apparently confusing between them. No, that's not right. The script checks these conditions: The number of FormIDs must be lower than 2048. The value of all FormIDs must be lower than 4096. If condition #1 is met, but not #2, the plugin can still be light by compacting the FormIDs (that is changing their values to be less than 4096). There is an important piece of code at the beginning, which you noticed and commented on: if not IsMaster(e) then Continue; This skips over any record that is not a FormID, and only continues processing records that are FormIDs. To summarize, a light plugin is a plugin with fewer than 2048 FormIDs, each FormID being in the range 2048 to 4095 (FExx x800 to FExx xFFF).

In addition to what's already been advised, after disabling the non-Step-2.2.0 mods, DynDOLOD Output, and DynDOLOD Occlusion mods, make sure all plugins are enabled in Mod Organizer's right pane. There should be no errors/warnings reported by Mod Organizer: the danger/warning sign at the top right corner of the UI should be greyed out. There is an option in BethINI to show/hide the Mods menu: BethINI > Interface tab > Mod Manager Menu checkbox. It's unchecked in the STEP guide on purpose: so that it's not shown and can't be used. Unfortunately it doesn't remove it from the Main Menu, for that requires a Main Menu replacer. The Mods menu must never be used when using an external mod manager such as Mod Organizer.

Hello Pavel, nice to see you here At the time I wrote my comments, the instructions for using FMWF with DynDOLOD 3 were different. They were provided by a user and were very convoluted: They've since been removed. Consequently, please disregard what I wrote earlier. The current instructions are simpler and clearer, however two alternate approaches are provided, which is rather confusing. Approach 1: Approach 2: Approach #2 is the correct one and really the only one that should be advised and followed. Please refer to the official DynDOLOD instructions for dealing with map mods: https://dyndolod.info/Mods/Maps-And-Map-Mods. Those instructions are generic so some of them don't apply to FWMF, but these are particularly noteworthy (emphasis added): Hope this helps. Take care.

The black face "bug" (it's not a bug) is caused by mismatch between NPC face configuration in plugins, and facegen meshes/textures. Facegen meshes/textures can't be simply replaced like other meshes/textures, as they're uniquely tied to their respective NPC record in plugins. For any given NPC record, matching facegen meshes/textures must be in sync with whichever plugin "wins" in the load order. In practice, black faces are displayed in these cases or combination thereof: Missing or not enabled, or incorrectly sorted, or wrong plugin(s) Missing or not enabled, or incorrectly sorted, or wrong facegen meshes/textures Mix-up between plugins and facegen meshes/textures from different mods Facegen meshes/textures out-of-sync with modified plugin(s) Facegen files are in [...]/meshes/actors/character/facegendata/facegeom/<plugin-name>/<NPC-ID>.nif [...]/textures/actors/character/facegendata/facetint/<plugin-name>/<NPC-ID>.dds where <plugin-name> is the name of the plugin defining (as opposed to overriding) the NPC <NPC-ID> is the form ID of the NPC_ record in <plugin-name> For a pure STEP guide installation, such mismatch shouldn't happen. If it does, it is necessarily caused by incorrect installation. Redo the installation of Simple Children and TK Children Make sure to remove/hide the TK Children plugins as instructed Make sure to remove/hide the TK Children meshes/textures folder as instructed Verify the only remaining files from TK Children are in meshes/actors/character/character assets Make sure the 2 Simple Children plugins are enabled Verify nothing overwrites the files from Simple Children If using any mod not part of the STEP guide, remove it completely Make sure the STEP CR patch is enabled Sort with LOOT Face Discoloration Fix is not really a solution. It's a brute-force tool that won't correct wrong plugin sort order, for example. Yes, the NPCs will get a "real" face rather than a black face, but it might be the wrong face. It's overkill for STEP, like using a bulldozer to stomp on a fly.

This is typical "shesonspeak" which tries to explain things assuming the reader already knows what he's talking about DynDOLOD plugins (e.g. DynDOLOD.esm) have a version number in the description field of their header: Sheson DynDOLOD.esm SSE Generated Plugin Master to work around game breaking bugs. Putting thousands of firstborns to work to add dynamic distant object LOD and switch them off when player is near Version 2.45 When using LR workarounds, version is 3.0. There are also data files under DynDOLOD Output/SKSE/Plugins, generated by DynDOLOD for use by its DLL or Papyrus scripts. They are not forward or backward compatible between current Papyrus scripts or DLL, and DLL NG (for LR workarounds). When not using LR workarounds, it's possible to switch back and forth between the PapyrusUtil (default) or DLL variants of the DynDOLOD "runtime" without having to re-generate DynDOLOD Output. When using LR workarounds, DynDOLOD Output can only be used with DynDOLOD DLL NG. PapyrusUtil runtime is not supported. It's not possible to switch back and forth, as there is only one option.

Correct. Same change applied to all 20 Sound Descriptor records in IHSS.esp.

Posting this in case it may be useful and relevant for inclusion into STEP CR Patch, as the STEP Guide now includes Immersive Sound Compendium (ISC). If already known and addressed, please disregard. I gradually became annoyed by the too loud horse step sounds and looked for a way to decrease their volume. I noticed the presence of a 'Horse Steps' volume slider in the Audio settings menu, however it appeared to be ineffective. This slider is added by ISC, but it's unused when IHSS overrides ISC. In vanilla, horse step sounds are assigned to the 'Ambience' sound category, ISC reassigns them to its own 'Horse Steps' category, and IHSS reassigns them to the 'Footsteps' category. In order to make ISC's 'Horse Steps' slider work with IHSS, the Sound Descriptors of IHSS need to be patched in xEdit to use ISC's 'Horse Steps' Sound Category. As shown in this example: (above needs to be done for each record under 'Sound Descriptor') This simple change makes the 'Horse Steps' slider functional, avoiding user confusion and improving equalization of horse step sounds.

No testing per se from me, but I've been playing with it for hundreds of hours, which is why I recommended it. Formally testing before/after with/without would be a very tedious and time-consuming exercise. It's good quality stuff, as all the other stuff this MA puts out, IMHO. As can be seen by the number of reported bugs compared to the number of downloads for this mod.

The record structures holding the data in the plugins are slightly different between the 2 plugins, but the data within are identical, hence it is considered an ITM by xEdit. When viewing records, xEdit highlights only the differences that actually matter. Form version doesn't matter in determining whether records are different or identical. The size difference is a byproduct of the different form versions. CRC32 is reliable to verify the integrity of files. It's specifically designed to detect errors in data storage or transmission. The CRC32 of my copy of Skyrim.esm from 1.5.97 is AF75991D. The CRC32 of Skyrim.esm from 1.6.640 (current Steam version) is 66212483. Navmesh 001020DA in MrissiTailOfTroubles.esp is seen as an ITM when compared with either version. The current version of SSEdit is 4.0.4. I finally found out the reason you're seeing navmesh "differences" in xEdit, highlighted in yellow/green: you're using 'Simple records'. You need to turn this option off to properly visualize and compare NAVM records and other complex records: Bottom line: these navmeshes are definitely ITMs and are correctly cleaned/removed from the Mrissi plugin.

I don't know what to tell you. This navmesh [NAVM:001020DA] is an ITM and is displayed as such in xEdit: With 'Hide no conflict and empty rows' option turned on: What is 'MrissiTailOfTroubles_test.esp' in your screenshot? The original, genuine plugin name of Mrissi version 1.7 for SSE is MrissiTailOfTroubles.esp with checksum 881934D2, as reported by xEdit: [00:08] Background Loader: loading "MrissiTailOfTroubles.esp"... [00:08] Background Loader: [MrissiTailOfTroubles.esp] Loading file [00:08] Background Loader: [MrissiTailOfTroubles.esp] File loaded (CRC32:881934D2) Seems to me you're not looking at the correct plugin in xEdit.

I didn't mean the issue doesn't exist, I meant it may not be visible or noticeable, and therefore is not an "issue" from a game player perspective. As described on https://dyndolod.info/Help/Large-References: Sorry for not being clear enough. I'll rectify my previous comment.