Mousetick

Are you currently using USSEP? If yes, are you using the English version or a translated version for your language? What does your load order looks like? The controversial changes made by USSEP are very few and far between compared to the huge amount of bug fixes, balance and consistency enhancements it makes. The people who complain loudly and madly about USSEP are making wild generalizations and exaggerations. They're primarily motivated by a vendetta against the main USSEP mod author, and the redditors are prone to mob mentality. In the list of mods you linked to: Is completely undocumented. You're going to blindly trust that this mod is more correct than USSEP? Is in English language. You wouldn't notice the difference if English isn't your native language or you're not fluent in written English. Restores the original Ebony mine. But it's not more or less correct than USSEP. The vanilla game itself is inconsistent in the lore about the mine and it contradicts itself. Is not useful, unless you like to cheat and use exploits that make the game unbalanced. This particular exploit allows for ridiculous overpowered effects that were most likely not intended by Bethesda to happen. Ditto. Ditto. Restores the original hair color of one NPC. But it's not more or less correct than USSEP. The vanilla game itself is inconsistent in the lore about the NPC's hair color and it contradicts itself. Is itself an arbitrary change that is not faithful to vanilla. Completely inconsequential from a lore or story perspective. You can decide to use USSEP or not, it's your choice. But don't take what you read on reddit for granted.

Seriously? Are you trolling? If you're playing a localized version of Skyrim, why do you care about the English version of USSEP? Good luck with that. The mods referenced in the reddit post you linked are not going to make the game any closer to "the story Bethesda released" (whatever that means), especially if you use other mods. And the main ones like Vanilla Plus Writing Purity Patch are in English. Are you playing Skyrim vanilla or with mods? I'd suggest you simply play vanilla if you really want to get the purest experience.

There is actually very little overlap in terms of record conflicts in the plugins between USSEP and SLaWF, so it's not even necessary to "triage" the changes between the 2. As I mentioned previously, SLaWF is built on top of USSEP and is designed to complement it. Not to replace or compete with it. There are no serious conflicts such landscape or navmesh between the two. Most of the conflicts between USSEP and SLaWF are caused by the farm crop ownership set by SLaWF, if that feature is used. What actual, concrete, problems are there today? If I'm correctly understanding and following Tech's reasoning, the problem is that this mod makes changes that should be in USSEP. How is that a problem? How does it matter where, in which specific plugin, those changes are? The end-result in the load order and in-game is exactly the same whether they are in mod A or mod B.

I don't get what all the fuss is about. What is the problem that this mod presents exactly? What are the tangible, concrete issues it creates for mod users or for players in-game? This mod fixes cosmetic issues that are not in USSEP precisely because USSEP doesn't address them soon enough or won't ever address them as they're considered out of scope for USSEP. Nowadays USSEP updates mainly addresses gameplay, "lore" and UI issues. Both mods together complement each other nicely. This mod requires and is built on top of USSEP. We can argue whether some of its changes are necessary/arbitrary/subjective, but the same can be argued about USSEP. I'd rather this mod exist than not, as it's more convenient than using a bazillion tiny fix mods. And fixing this type of issues is painstaking, boring work that few modders are willing to do. So I'm glad someone is taking care of it. The updates may be beneficial for donation points, but if you care to look at the comments instead of badmouthing, many changes/fixes are in response to user reports. They're not done in a complete vacuum, just for the sake of putting out updates. Lastly, in regards to conflicts, whether the same changes were in USSEP instead of this mod, wouldn't change anything. So this argument doesn't stand. The whole bashing on this mod sounds more like politics than serious technical discussion. Please provide actual tangible points to demonstrate how/why this mod is bad. My 2 cents.

DynDOLOD 3a155 SSE - Combine Worldspaces for LOD About a month ago, I used Combine Worldspaces for LOD to put Skyrim LODs into Solstheim. When I initially set up and incrementally tweaked the DLC2SolstheimWorld_Combine.ini configuration, I used minimal DynDOLOD options to speed up generation for testing. Everything looked as expected in-game. Then once I was finally happy with the Combine.ini configuration and results, I re-generated all LODs for all worldspaces with DynDOLOD, using a larger set of options - including Underside. The final results in-game were unexpected and disappointing, to say the least. I didn't understand what could be causing the visual defects. But I had spent so much time making the Combine.ini "just right" for my taste, I didn't feel like troubleshooting and just postponed it until later... Then I saw your recent comment: Which gave me an idea. What if the underside was the culprit? So I did a quick test: Without | With /meshes/terrain/dlc2solstheimworld/dlc2solstheimworld_underside.nif In the picture on the right, you can see parts shaped like the original/vanilla DLC2SolstheimWorld terrain from Dragonborn.esm. Does the underside mesh generation take into account Combined Worldspaces for LOD? It looks like it does not. Underside log: LODGen_SSE_DLC2SolstheimWorld_TerrainUnderside_log.txt DynDOLOD log and debug log: https://drive.google.com/file/d/1ssrM9OwD-gSECDe9VrwLA5Szcdawq535/view Combine.ini: DLC2SolstheimWorld_Combine.ini Note: If the issue is caused by either a bug in DynDOLOD or a fault on my side, I'm not available for testing/troubleshooting at this time. But I'd appreciate getting your input on the issue. Thanks.

Which version of DynDOLOD are you using? Assuming DynDOLOD 3 Alpha... See https://dyndolod.info/Mods/Waterfalls. Make sure you're using the latest version of DynDOLOD Resources SE 3. Make sure the waterfall LOD meshes from DynDOLOD Resources SE 3 are used. They should win/overwrite other waterfall LOD models, if any, in your load order. If they're not, reorder them or hide/remove the others in mod manager. Regenerate DynDOLOD if you made changes to correct the previous 2 points. If problem persists, report it and ask for assistance in the DynDOLOD 3 Alpha support forums. Read OP before posting. The bright water issue exists with vanilla waterfalls. Water Effects Brightness and Reflection Fix fixes the issue for vanilla waterfalls.

Yes. The FOMOD in the Main Files section, which was lagging far behind, was updated with the latest/current version of each individual patch. In addition, there are some new or updated individual patches, as listed in the Changelog's first paragraph: new Adamant T&B, Reliquary of Myth - ICH WACCF, Survival Mode (CC) - USSEP CACO, Visual Animated Enchants 2-023; or updated: Beyond Skyrim - Bruma CCOR, Bonemold Weapon Pack WACCF, Cannibal Draugr on Solstheim CACO, all Guards Armor Replacer WACCF/CCOR, Ordinator CACO, Skyrim Revamped WACCF, Survival Mode (CC) CACO, and all Thaumaturgy WACCF/ACE/AMB. I'd suggest you continue to ignore the FOMOD and check the new/updated individual patches by sorting the Miscellaneous Files section by: Date Uploaded, Descending. Pick the ones that apply to STEP or to your specific load order.

Your question and example are contradictory: if AE is prescribed, it means it's required. If it's required, it cannot be unnecessary. Please do not piggyback an existing topic with unrelated questions/issues. This topic is about changing a master, but you want to remove a master. Search this forum or the internet at large for related discussions and possible answers. For example: Remove Masters from a Plugin. Or create a new topic describing your specific problem/question in details if you can't find answers. Thanks.

To download CNO 2.1.0 which is no longer available on the CNO download page, click the link provided on this mod's page.

Yes, either this or you don't get any icon at all. The best working combination at the moment seems to be: CoMAP 4.0 Overwrite with CoMAP 3.4.2 CNO Temporary workaround (in CNO optional files) CNO 2.1.0 And if using DDDM, add: DDDM This mod (which is compatible specifically with version 2.1.0 of CNO)

Install as loose files. Pick iHUD compatibility option (I'm not 100% certain it matters, as I no longer use iHUD). Pick Vanilla HUD (pretty sure any preset you choose doesn't matter as DDDM uses its own SkyHUD configuration). Make sure SkyHUD scripts overwrite iHUD scripts if you picked iHUD compatibility option. Make sure DDDM overwrites SkyHUD (DDDM must overwrite everything else UI-wise in general). Don't bother customizing the SkyHUD config file. DDDM provides its own SkyHUD configuration. You can customize DDDM's version of SkyHUD configuration (skyhud.txt) if you wish. * This should really be discussed in the SkyHUD topic instead of here.

Correct. Though it's not this patch per se which is incompatible: Compass Navigation Overhaul 2.1.x itself doesn't work correctly with CoMAP 4. This mod is just a reskin to match DDDM style. The core functionality is CNO.

It's a requirement for Compass Navigation Overhaul by the same MA. It's meant to be a framework / modder's resources for UI mods, but so far nothing else uses it beside CNO. DDDM does not use and does not require Infinity UI.

Not quite. Ticking "Remember selection" causes entries to be added under [DialogChoices] in Modorganizer.ini. Settings > General > Reset Dialog Choices causes the [DialogChoices] section and all values under it to be removed. I believe so too.

SUCCESS! Whatever was changed in this version, has fixed it. I fast travelled back and forth between Whiterun and Windhelm a couple times, approached the watchtower by foot in between fast travels, and fast travelled from Whiterun to Markarth. 7D3022EC was disabled at the fast travel destination, when coming back to Whiterun, it was enabled again, it disabled properly when approaching the watchtower and re-enabled when moving away. The other dynamic LOD references that were failing before along with 7D3022EC all appeared to work properly (just visually looking at the EWWDSB objects at the watchtower, I can tell the dynamic LODs are properly fading when the watchtower cells attach). I didn't check them exhaustively but there is no reason to believe they all wouldn't be fixed as well. Log for info: DynDOLOD.7z Thanks. Glad you were able to nail it.

Sorry for being vague. In TEST1.log, starting at line # 1004, disables are all reported as failed, until line # 1155, when enables and disables of other references are not reported as failed anymore. At line # 1668, disables are all reported as failed again. But it looks like those are retries of the same previously failed ones starting at line # 1004. The affected references that fail to disable never work properly again. Ever since we started this troubleshooting, and in all my tests, I always check the state of 7D3022EC (which is one of the references that fails to disable, but not the only one) in the console at each step. It has never been disabled after fast travelling, as shown in the console, with any test version of DynDOLOD.dll so far. Except in the cases where I "hacked" DynDOLOD_NG_Tamriel.txt to change the list of [Objects], as I reported before. If 7D3022EC is successfully disabled after fast travel to Windhelm in one future test, you can be sure this will be the first thing I'll tell you. I have a small human brain so I can only keep track of 7D3022EC in the console. There are dozens of dynamic LOD references that are enabled and disabled after fast travel. I look at DynDOLOD.log to get an idea of what happens to the other references. Yes. Ok, thanks. Let me give it a try, I'll keep you posted. I'll also try resetreference if needed, as you suggested.

Not in the second instance (after fast travel). So no change from previous. But you can ignore that, because the results from the latest test version are much more interesting. I switched to debug=true which produces much bigger logs so I'm attaching them rather than copying them inline here: DynDOLOD TEST1.7zDynDOLOD TEST2.7zDynDOLOD TEST3.7z Test 1: Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables. Test 2: Load clean save. Exit Whiterun meadery. Run in a large circle around Whiterun. Stop in front of the meadery. Test 3: Use DynDOLOD_NG_Tamriel.txt edited to contain only EWWDSB entries. Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables. My comments/observations on the logs: In Test 1, after landing at Windhelm stables, all the enables/disables initially succeed. Then one disable fails (7D30226D, which happens to be associated with EWWDSB). Then all the following disables fail, affecting dynamic LOD references from multiple sources, but mostly from EWWDSB. The last one in the first failure sequence (7D3022F7) is associated with a vanilla reference from Skyrim.esm (0D3F85). Then everything works again, until it doesn't. This repeats a few times. At one point the failure sequence affects both enables and disables equally, again from multiple sources, including vanilla references. For example, 7D3020C6 is the dynamic LOD of 0E94A9 and it fails to enable. In Test 2, everything looks good mostly. Except at one point there is a string of continuous enable failures. Some or all, I didn't check, of these references were already enabled earlier. In Test 3, the log is clean. The failures followed by successes followed by failures and so on, each happening in continuous "bursts", make me think the issue could be DynDOLOD.dll might be trying to enable/disable references when the engine is busy or in a state incompatible with manipulating references "behind its back" so to speak (e.g. Papyrus VM running). I had "Autosave on travel" enabled. I disabled it but it made no difference. I don't think another mod could be interfering. It can't be a plugin. Nothing overwrites DynDOLOD.esp. It can't be a Papyrus script, as if it were, it would fall into the "Papyrus VM running" category. It could very well be another SKSE plugin that's interfering. I have a boat load of them. So my next test is going to disable all of them. Although I don't think I can disable Engine Fixes. The game probably can't even start without it (too many open files). Suggestions for DynDOLOD.log in debug mode, if possible: Print the cell FormID or X,Y coordinates of the current cell on each cell change to make it easier to understand the flow. Or print the cell FormID or X,Y coordinates of the cells that attach and detach. Or both Whichever is easier / you prefer. Print the type of event received. Print the EditorID of each enabled/disabled dynamic LOD reference. This would be mostly useful for you to read the logs since you don't have my load order to look up the reference IDs in xEdit: without the EditorID you can't tell what the reference ID corresponds to. Thanks.

I made another test. I edited DynDOLOD_NG_Tamriel.txt and removed all [Object] entries except those associated with 'Environs - Whiterun Watchtower.esp'. 7D3022EC was successfully disabled and re-enabled on fast-travel. Upon coming back from the fast-travel roundtrip and looking at the watchtower with its cell(s) attached, all the dynamic LOD associated with EWWDSB was correctly disabled. I don't know what happened to it while fast-travelling back and forth since DynDOLOD.log only logs one ref at a time, but I'm assuming it was disabled and re-enabled successfully like 7D3022EC. My DynDOLOD_NG_Tamriel.txt is fairly large. There are 6237 [Objects] entries in total. EWWDSB alone has 142 entries. That's quite a few references to keep track of. Is it possible we're hitting some kind of limit, or a performance bottleneck? My PC is a potato by today's standards. Also, is it possible that DynDOLOD.log is not telling the truth when it says "Disable XYZ" or "Enable XYZ", and internally DynDOLOD.dll actually tries to disable/enable some bogus non-existent reference for whatever reason? Thanks.

Disables are not logged anymore: Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt Enable - Reference 7D3022EC Base 5A231849 Flags 40010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif Enable - Reference 7D3022EC Base 5A231849 Flags 48010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif # There should be one Disable here Enable - Reference 7D3022EC Base 5A231849 Flags 40010C0A/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif # There should be at least one Disable here

Annotated DynDOLOD.log: Note there is one occurrence of 'Disabled failed?' Yeah, that's a good idea, but I'm going to pass. Unless you'd like to try to keep troubleshooting with more debug versions of DynDOLOD.dll, I'm going to put this whole issue aside for now. It appears to be isolated to EWWDSB, and may be specific to my load order or configuration, so I don't think it's worth spending that much time into it. Aside from the dynamic LOD references remaining always enabled and the resulting visual glitches, there are no game-impacting side-effects. Perhaps I'll tackle your suggestions later when I have more time and nothing more important. I have to say it's really strange and puzzling though. These references are defined in DynDOLOD.esp. I'm pretty sure absolutely nothing else touches or uses them. And they're no different in how they're defined in the plugin, compared to other dynamic LOD references. I even tried disabling some big engine-level SKSE plugins (NetScript Framework, Bug Fixes SSE, Papyrus Tweaks NG, powerofthree's Tweaks, Scrambled Bugs, ...) which made no difference. Thanks for your assistance. Dynamic LOD failing to disable on fast travel (Continued) I edited DynDOLOD_NG_Tamriel.txt and removed all 'Environs - Whiterun Watchtower.esp' entries, except the one for 3154668 (hex 3022EC). Now 7D3022EC disables and enables successfully on fast travel and DynDOLOD.log shows all 'Disabled success?'. I'm going to add them back in batches until it breaks again. I don't understand why everything seemingly works fine when changing cells while moving by foot but doesn't when fast traveling. Is there a difference in how DynDOLOD.dll handles these 2 cases? Are dynamic LOD references disabled/enabled serially or all in parallel? If they're processed serially, is the order in which they are disabled/enabled always the same or random? If the order is constant, is it the order in which they are listed in DynDOLOD_NG_Tamriel.txt? Thanks.

I started a new game with ASLAL in Breezehome. Initially all the stuff from Environs - Whiterun Watchtower Doesn't Stay Broken (what a mouthful, let's abbreviate into EWWDSB) is all OFF. In its place, there is all the stuff from Whiterun Watchtower Doesn't Start Broken (WWDSB), which does the same thing in reverse for the early game (before the dragon attack and the tower is destroyed). The WWDSB stuff is initially all enabled and then gets disabled during/after the dragon attack on the watchtower (Dragon Rising main quest). The dynamic LOD of WWDSB is successfully disabled when fast travelling. I then manually enabled the Enable Parent of the EWWDSB stuff in the console. The dynamic LOD of EWWDSB fails to disable when fast travelling. I'm completely confused. This doesn't make any sense.

Fast travel from Whiterun with 7D3022EC enabled to Windhelm stables using the map: disable fails on arrival. Fast travel from Whiterun with 7D3022EC enabled to WindhelmBridge01 using the console: disable fails on arrival. Also, if I reload a save during the same session and the reference is already in 'failed state', it remains in failed state. For example, if it previously failed to disable so is still enabled, but the loaded save reset it to disabled, it fails to enable when it should. Is there some kind of handle/proxy/wrapper in memory that keeps track of the reference or some kind of locking mechanism that could get out of whack? Thanks.

I agree. There is nothing special about Environs - Whiterun Watchtower, it's a red herring. It just so happens that it produces a bunch of dynamic LOD references that are enabled and then fail to disable after a specific sequence of events and under specific conditions that remain to be determined. The same issue could probably be reproduced with any other enabled dynamic LOD reference, using the same sequence of events under the same conditions. This made no difference at all. Yes. Annotated DynDOLOD.log: No. Repeating the same travel again after "fixing" the reference by manually disabling it in the console, results in the same failure. Annotated DynDOLOD.log: Other points to consider: I chose Windhelm for my test, but I confirmed that the same failure occurred when travelling from Whiterun to the Solitude terminal. I suspect other destinations would fail in the same way. Once the dynamic LOD reference is in the 'failed disable' state, it remains that way forever (unless manually disabled in console) and its failed state persists in the (co)save files across sessions. If you can't reproduce there is probably another factor/mod/component involved. TBD. Thanks. Update: I just reproduced the issue by simply taking the carriage from Whiterun to Windhelm. Duh. I should have tried the simplest way to fast travel first instead of seeking the most convoluted one. My apologies for making you install Clockwork and wasting your time with it.

Test 1: Same as previous test 1 where DynDOLOD DLL attempts to disable 7D3022EC several times unsuccessfully. Papyrus log doesn't contain anything of interest: Papyrus.0.log.7z Any idea why the reference fails to disable? Then I made 2 new cleaned saves (one inside Honningbrew Meadeary, load-door within FarGrid, the other inside Frostfruit Inn, load-door outside FarGrid) and did all the tests you suggested. Everything worked fine and as expected, so I'll skip the details. I thought the issue is not with the initial enabling of the initially disabled dynamic LOD, rather at some point the dynamic LOD should be disabled but is not for some reason and this leaves it into a "wonky" state. Then I thought about possible scenarios that might cause this. And I was able to reproduce it from scratch, yeah! Make sure you're seated comfortably because this is a bit convoluted. I use the Clockwork mod. It provides a teleportation system in the form of access terminals at each city and a central hub. To fast-travel from one city to another, one enters the departure terminal, teleports to the hub, then from the hub teleports to the destination terminal. Each terminal and the hub are separate interior cells. The Whiterun terminal is located near the Whiterun gates. Its load-door is within the FarGrid containing 7D3022EC, but outside the NearGrid. The Windhelm terminal is located at the Windhelm docks. Its load-door is obviously outside the FarGrid containing 7D3022EC. The steps I used to reproduce: Load clean save with DynDOLOD plugins enabled, inside Honningbrew Meadery. Exit the meadery. 7D3022EC Initially Disabled -> Enabled. Go to the Whiterun teleportation terminal and enter it. 7D3022EC still Enabled. Teleport to Clockwork Hub. 7D3022EC still Enabled. Teleport to Windhelm terminal. 7D3022EC still Enabled. Exit Windhelm terminal. We're now in Tamriel on the Windhelm Docks, very far from the Whiterun Watchtower. 7D3022EC still Enabled. Re-enter Windhelm terminal. Teleport to Hub then back to Whiterun terminal. Exit Whiterun terminal. 7D3022EC still Enabled. Walk to the Whiterun Watchtower. 7D3022EC still Enabled. And same disabling failures as before: Enable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Enable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 lod\clutter\stockade\stockadegate01_lod_0.nif There are about twice as many disabling attempts compared to test 1 so I guess DynDOLOD tried to disable it on two occasions, but I have no idea when the first one occurred. Perhaps step 6? I guess I can rerun the test and quit after step 6 to confirm. Thanks.

Yes. When I updated my ongoing game to DynDOLOD 3a155 plugins from 3a140 I did it with a clean save in an interior cell in Solitude. So all DynDOLOD persistent references should have been removed from the save, prior to updating. I no longer have the clean save to verify. DynDOLOD DLL NG was not changed. I have no idea when or how 7D3022EC (and the other dynamic LOD references like it related to the same mod or Enable Parent) became "stuck" in that state.