Mousetick

Mod has received major update. Now offered in 3 main files variants, one of which requires OAR. OAR being N/A for current STEP Guide (2.2.0 as of this writing), it may be a good idea to clarify which variant can be picked in the wiki instructions.

Pretty sure Volumetric Mists wouldn't cause this. Volumetric Mists manually places mist/fog objects at specific locations in the world. Like clouds in the sky, except they're close to the ground, and they don't move. They're completely impervious to the weather or time of day. They're always there, like trees, streams or mountains. From Volumetric Mists: So I guess what we may see in your first screenshot is not distant fog but the mists from Volumetric Mists. In which case there is absolutely no dynamic, engine-controlled fog present in either screenshot, even though the lighting, saturation and other effects look like foggy conditions to me. Perhaps you should find out which weather is active when you get this effect, to confirm whether it's fog-related or not.

I updated the pictures showing the pattern in my previous post. I messed up the first time and we couldn't see what I wanted to show.

This washed out effect is present in foggy weathers. Only shapes can be distinguished through the haze obstructing the view. The second (daytime) screenshot doesn't look too bad. At least there is some fog visible in the distance. There is barely any fog in the first (nighttime) screenshot, so it looks weird. Instead when viewed at 1:1 pixel scale, one can see some kind of filter with a criss-cross pattern, similar to a film grain, which appears to be applied to the entire scene. Zoomed in 200%: (there are some JPEG compression artifacts, but the pattern should be clearly visible) A similar pattern seems to be present in the first screenshot, too. Zoomed out 55%: Is this grainy filter supposed to represent the fog? the fog particles? I don't use ENB, I have no clue.

A recommendation is not a requirement. The recommended rules must be added manually, if you wish to use them, because they're not present in DynDOLOD by default. You don't need to add them, they're not necessary for DynDOLOD or the game to function. Without them, DynDOLOD falls back to the default catchall '\' rule (the last one at the bottom of the list). Without them, everything works just as well, though mountain LODs may not look as good as they could when using those DynDOLOD Add-ons. The custom mountain rules affect mountain objects further away in the distance (LOD Level 8, LOD Level 16), not near distant objects (LOD Level 4), so you may not even subjectively notice a difference with/out. Same goes for MM. Visual quality recommendation ≠ functional requirement. If you're just evaluating ERM at this point, I'd suggest you test with DynDOLOD without the custom rules, in order to get the basics working correctly first. And so that you can compare apples-to-apples with MM you were using before without custom rules. Then you can worry about the custom rules later.

Yes. The 'Rule added by' field is not editable: you can't type anything there. Click the Help button for more info. Beware your custom rules created via the DynDOLOD UI will be lost when quitting unless you save a preset. And even if you reload a previously saved preset, they will be removed upon clicking the Low, Medium or High buttons. https://dyndolod.info//Help/Advanced-Mode: The recommended rules are just that: "recommended", for best quality/performance ratio. The same rules can be used with the Majestic Mountains DynDOLOD LOD Pack. They're meant to leverage the higher quality, more detailed custom mountain LOD models compared to standard/default LOD models. They're also meant to be used with the global High DynDOLOD preset. Otherwise you may end up with very detailed mountain LODs but crappy-looking everything else in comparison, which would look weird.

NPCs walk backwards after bumping into the player. You can hear Mila cry "Be careful!" in your video.

You can try to use Rebalancing Anniversary Edition - Quest Requirements. Set ridiculously high requirements for AE CC quests so that they never start, or adjust their requirements so that they start when you feel it's appropriate/balanced for your playthrough. Disclaimer: That mod has not been tested with the STEP SSE Guide (AFAIK) and is not supported by the STEP team. Use at your own risk. To the STEP folks @z929669: you may want to consider that mod for inclusion in the guide. The guide already includes a number of similar mods for the original SE content (Timing is Everything, At Your Own Pace, Not So Fast, ...) so it shouldn't be too much of a stretch to cover CC content, for consistency and balance.

Wikis are a pretty good reference to determine if something "unexpected" exists in vanilla or not. Such as Wylandriah's satchels. From Fandom: From UESP:

Because your story didn't make any sense. An .esp plugin can't cause the issue you described initially. In order to get this far, DynDOLOD had to start up and find and load the plugins. Which it failed to do initially. Now it's a completely different error with a completely different cause than what you were reporting originally. You conflated everything together.

Yeah, right. As soon as we ask for details the problem is magically fixed. Would you care to tell more about this mysterious plugin, its "invalid registry something", and how you fixed it? For the benefit of others who may be using the same plugin and may encounter the same issue...

It's referring to Skyrim.ini. That is not useful information, to us. We have no insight into what changed on your side, as a result of your (unknown) actions or other (unknown) factors. We need factual data points about your actual installation and configuration. Does xEdit launched from MO2 work? Provide a screenshot or transcript of the top of xEdit's Messages window, like this: SSEEdit 4.0.4 (103758D4) starting session 2023-06-27 16:52:10 Using Skyrim Special Edition Data Path: ... Using Backup Path: ... Using Scripts Path: ... Using Cache Path: ... Using ini: ... Using save path: ... Using Creation Club Content list: ... Using plugin list: ... Using settings file: ... Using language: ... Using general string encoding: ... Using translatable string encoding: ... Using VMAD string encoding: ... Loading active plugin list: ... I used ellipses (...) above, but your post should show the actual paths used on your end.

If you had followed the guide as you said, you shouldn't need to mess with the DynDOLOD command line options: Your -m option is linking to your MO2 profile. The only command line option necessary with the STEP guide is -sse. Skyrim SE is not even detected, DynDOLOD is falling back to Skyrim (OldRim). It looks like the Windows registry is not even properly initialized. Launch Skyrim SE from Steam, at least once, as recommended by Z above.

4294967295 (0xFFFFFFFF) is precisely the maximum value of an unsigned 32-bit number, or -1 converted to an unsigned 32-bit number. I wonder how it ended up in there

I'm unwilling to do these tests. I'm not going to regenerate Tamriel LODs for ~20 trees in a corner of Solitude, with any DynDOLOD version, old or latest. I've already spent a lot time of time reporting, researching and documenting the issue caused by the USSEP rules. @MisterMorden also researched the issue on his side and helped with our findings. It's unfortunate that the most important post slipped through the cracks, but that's ok. I'm a bit fed up at this point, though, to tell you the truth. The simple questions I asked were: I have no idea what this means pertaining to the specific issue at hand. DynDOLOD is a computer program - of which you're the developer - with a defined, expected behavior based on its algorithms and implementation. We should be able to have a rational discussion about predicted vs. observed behavior, or about predictable output based on specific input, without running tests to "see what happens". DynDOLOD is not a black box. I don't know, I haven't tried. Do you know? It seems to me if the USSEP rules are removed and the USSEP trees are left as is by DynDOLOD, then the Tamriel LODs will overlap with the full models of the Persistent, IsFullLOD USSEP references. In which case we'd be back to the original issue that the USSEP rules were intended to prevent. Unless DynDOLOD removes the IsFullLOD flag on tree references when doing ultra tree LODs. Does it? Do you know if it does? We should be able to predict the results based on the implemented logic, without running tests. Lastly, if you're affirming (rather than speculating) that removing the USSEP rules should just work with ultra tree LODs, without undesirable side-effects, why are these rules enabled by default and have been for a very very long time? It's still not clear to me after all the back-and-forth whether you agree the USSEP "delete" rules are an issue when used with ultra tree LODs. Thanks for your time and attention. I'm now going back to lurking in the corner, while playing the game with my "dirty" against-the-rules patch.

Thanks. This is puzzling. Sorry to be a pain but I have to ask whether you effectively performed the validation steps described in Verification 1. I can't tell whether you did or not based on your report. Please go through those steps and post a screenshot of the Explorer++ window showing the contents of %LOCALAPPDATA%\Skyrim Special Edition, for confirmation. If the plugins.txt is present in the folder, post the contents of that file opened from the Explorer++ window (right-click the file and select Open to view in Notepad or your default text editor). The reason I'm asking to go through this peculiar procedure is that the contents of %LOCALAPPDATA%\Skyrim Special Edition are virtualized when MO2 is used to launch programs. Browsing the folder through Windows Explorer shows its on-disk contents, not the virtualized contents. We need to verify the virtualized contents to understand what Skyrim "sees" when launched from MO2 and SKSE Launcher, hence the need to view the folder through MO2's built-in virtualized browser. Ancillary questions/remarks: Based on the xEdit screenshot you provided, it appears all your mod plugins are enabled? I previously requested that you disable all plugins except USSEP and Alternate Start (emphasis added): Have you done so or not? I understand your free time may be quite limited but if you can only spend 5 minutes per week to work on your modded Skyrim, at this rate you might be ready to play in a year or two. In the meantime you or I may lose interest or grow tired. So it's doubly important that you carefully read and follow the instructions I'm providing, so that we don't waste time guessing and backtracking. If there's something that's not clear or you need help with, don't hesitate to ask.

I'm not in the capacity to test the latest and greatest at this time, sorry. So to summarize, after reading very hard between the lines of your oblique answers to my simple, direct questions: the issue is caused by the USSEP rules which should not be used (when doing tree LOD as object LOD? unclear, not sure). Anyhow, reading https://dyndolod.info/DynDOLOD-Reference, specifically step #6 "Disable neverfades", gave me an idea. I made a patch that simply removes the IsFullLOD flag from the USSEP trees in SolitudeWorld. Problem solved. I guess that's what DynDOLOD would have done if I had run it without the USSEP rules?... It's not perfect though, I'm guessing because the Tamriel LODs cover more trees/cells than there are duplicates in SolitudeWorld, quite a few trees still disappear when getting closer, but at least the closest trees (e.g. the ones in cell -17,26) don't vanish so it's not as noticeable and jarring. Thanks.

I really appreciate your patience and willingness to respond, but I'm afraid we're still talking past each other The rules bug doesn't happen to me because I'm using Alpha 120. The USSEP rules are detected and seemingly applied correctly, as they've ever been since a long time ago: Forget about the current rules bug for a minute, assume it doesn't exist, and let me ask differently. I'm just trying to understand what is the expected behavior inside SolitudeWorld when DynDOLOD and the USSEP rules work as intended. What is supposed to be in the DynDOLOD plugin(s) exactly when the USSEP patch is working as intended? It's understood that the neverfade trees added by USSEP in SolitudeWorld are "deleted" by overriding them with UDR'ed XMarkers. Ok, that part is fine. But is that it? The trees are removed but not replaced by regular temporary duplicate references? Is it expected that the LODs for the "deleted" trees still be visible from SolitudeWorld then? Thanks.

I'm about to give up In fact I'd got tired of the runaround so I manually duplicated the USSEP tree neverfades disabled by DynDOLOD.esm into a custom patch plugin, as temporary references, in xEdit. So that I could see the full models. nth attempt to describe the issue: Cell -17,26 None of the references below are large references. [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26) USSEP adds [REFR:05063114] (places TreePineForestSnow04 [TREE:0005C06F] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26)) DynDOLOD.esm changes nothing, it only adds Tamriel_Worshipper_%17_26 [REFR:XX02F280] (places DynDOLOD_WorshipperActivator [STAT:XX000926] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26)) [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) This is the persistent cell of SolitudeWorld. USSEP adds [REFR:0506313E] (places TreePineForestSnow04 [TREE:0005C06F] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26) which is a neverfade duplicate of [REFR:05063114] above from Tamriel into SolitudeWorld. DynDOLOD.esm "deletes" [REFR:0506313E]: [REFR:0506313E] (places XMarker [STAT:0000003B] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26) This is the USSEP rules patch which may not be currently working, but it used to work, at least until Alpha 121. Just assume that it works for the sake of this description. [CELL:0004E3DC] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -17,26) Same cell position as [CELL:0000925A] but in Solitude worldspace. USSEP changes nothing. DynDOLOD.esm changes nothing, it only adds SolitudeWorld_Worshipper_%17_26 [REFR:XX02F632] (places DynDOLOD_WorshipperActivator [STAT:XX000926] in GRUP Cell Temporary Children of [CELL:0004E3DC] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -17,26)) End result: When [CELL:0004E3DC] is not loaded, the LOD of [REFR:05063114] is visible from inside SolitudeWorld. So far so good. When [CELL:0004E3DC] is loaded, the LOD of [REFR:05063114] is disabled, the full model of [REFR:05063114] is not visible since it's in another worldspace. But there is nothing to replace [REFR:0506313E], "deleted" by DynDOLOD, in SolitudeWorld. There is no tree reference in [CELL:0004E3DC] matching [REFR:05063114]. There is no tree where the LOD was showing...

Right. The issue is that the tree references are "deleted" in SolitudeWorld, but there is visibly nothing to replace them, in SolitudeWorld. When inside SolitudeWorld, looking from afar, the Tamriel LODs are visible, showing trees in the distance. Upon getting closer, the LODs turn off, and there are no full model trees where the LODs used to be shown, as I described in another, earlier post: I don't understand why it's so difficult to convey to you what's happening and what the weirdness is. It should be straightforward to reproduce: USSEP + DynDOLOD object LOD is all that's needed. Walk from Solitude catacombs towards Angeline Aromatics. Facing north, as you pass under the arch connecting to the windmill, see the tree LODs in the distance in the mountains behind the walls. As you keep walking in the same direction, see the tree LODs turn off, and an empty space where they used to be. Instead of full model trees. Perhaps. The question remains: is this weird behavior expected? Where are the carbon copies of the "deleted" references created, if they are created in the first place? Which worldspace? What are their refids and/or editor ids?

I reported an issue related to this a while ago: My post was completely ignored, for whatever reason. The report was based on Alpha 118, with USSEP 4.2.8, though the issue was noticed with much older Alphas before that. I haven't tested again with newer Alphas since 121. We were able to determine that the USSEP Neverfades in SolitudeWorld were indeed patched/disabled. But the carbon copy that's supposed to be created in Tamriel seems to be missing, or not visible for some reason.

No. Do not touch anything in there. Leave this folder alone. It's managed by MO2. I need to know exactly the results of the validation in order to make some progress. Please avoid vague statements such as "still have the issues when running SKSE" and simply provide specific, accurate facts. After removing plugins.txt and loadorder.txt: What was there in the %LOCALAPPDATA%\Skyrim Special Edition folder during Verification 1? Were there any files, which ones? Was plugins.txt there, if so what are its contents? What was the result of Verification 2? You previously mentioned that "all other programs (LOOT, SEEDIT, etc) apparently recognize my modlist". Please provide confirmation that is the case in the form of a screenshot showing the load order in LOOT and/or xEdit, when launched from MO2. The entire load order is not necessary, a partial view is enough.

FYI Ultrawide version available here: https://www.nexusmods.com/skyrimspecialedition/mods/93627. Requires the original mod (this one here). DDDM skin also available. Not tested by me, I don't have ultrawide.

If something isn't clear, you can ask for specific clarifications. There's no need for repeating your whole story verbatim. How things should work for everyone following best modding practices: There's no need for any manual ordering or locking in MO2 in order to override LOOT automatic sort. Custom 'Load After' rules are created in LOOT, nothing is done in MO2. LOOT doesn't know anything and doesn't care about MO2's locked order. LOOT is the only tool used to sort load orders. There is no split between LOOT and MO2. MO2 passively applies the load order sorted by LOOT. RTFM links: STEP System Setup Guide STEP SSE Tool Configuration STEP SSE Sorting Plugins with LOOT LOOT Editing Plugin Metadata As things are seemingly working differently and unexpectedly for you, you must be doing something different. If you don't care to figure out why, and are happy with your current situation, then there is no point in having this discussion. You can just skip the following. How do you sort with LOOT in MO2? Describe precisely the steps you use to do so. Which menu do you select, which buttons do you click on? What is the version reported by LOOT when you sort with LOOT in MO2? LOOT > Help > About.

Yep, good guess, looks like they are excluded indeed. There's a bug report about that: https://www.nexusmods.com/skyrimspecialedition/mods/59818?tab=bugs.