Mousetick

Wonderful. Thanks for clarifying and confirming this crucial detail. But I'm not a mod author, I'm just a mod user. What do you expect me to do to fix the actual problem, exactly? I have no control over the mod author's ability or willingness to fix the actual problem. I can't produce missing meshes or textures out of thin air. Well, I could produce dummy ones, but that'd be silly. The only options at my disposal, as far as I can tell are: Either make a mental note that some warnings are "hopeless" and ignore them - something that bothers me greatly; Or go in xEdit and get rid of all the references to the broken base records And the second option brings us back to a previous comment I made earlier and to which you replied: To be honest I didn't understand your answer, and I may not have expressed my thought clearly in the first place. In order to get rid of all the references to the broken base records, I have 2 options: Either remove them directly from the mod's plugin (right-click menu > Remove in xEdit) Or I can leave them intact in the mod's plugin and mark them as deleted in a patch plugin. A custom-made patch that is privately used by me only, and is not overridden by anything else. From an in-game standpoint, both approaches are equivalent: the references are no more, they're not there, they're never loaded, never used. The former approach is fine to operate on a dead mod, a mod which plugin is no longer maintained and will never change again. However it's not viable to operate on a mod that is updated regularly, because the references that were removed will come back with the next update, will need to be removed again, will come back again, will have to be removed again... The latter approach is still effective even if the mod is updated and the broken base records come back in the updated plugin. My custom patch doesn't change. It's a time- and aggravation-saving feature, it's more efficient. It doesn't get rid of the DynDOLOD warnings however, because deleted references are still counted for determining whether a base record should be scanned or not. So I'm back to square one, with warnings that I must ignore. Yeah that's fine, I can see which plugin is the actual culprit in xEdit, no worries. I just mentioned what looked to me like an unexpected diagnostic, because I wasn't sure if it could be indicative of a real issue. I beg to differ strongly on that point First, I'm not convinced that it's easy for the average user to "spot when checking the model and or the folder where the texture are expected", or that the average user knows intuitively that "other textures are missing too if the diffuse is missing". There is an apparent contradiction between the goal to validate assets and inform the user with easy to read/understand messages + helpful advice provided in the summary report, which is akin to hand-holding on one side. And then the decision to stop halfway through the validation, because "the rest is easy to figure out", which is akin to leaving the user to their own devices on the other side. Second, the fail-fast approach is not appropriate in this case, IMHO. It's not like the file-check operation is overly time- or resource-intensive to justify skipping it. Moreover, the validation phase is not a time-critical operation: it doesn't need to be completed as soon as possible. Nothing bad will happen if it takes a little while longer in order to be more comprehensive. Third, in case a texture is found, the validation will move on to the next texture in the set on the mesh. All textures need to be checked in the end, no matter what. Why not simply check them all, always, in a single pass? Doing it incrementally as a result of the fail-fast takes much much longer for the end user. Thanks. I hope you don't mind my comments and they're not interpreted as gratuitous criticism. My intent is to provide constructive/inquisitive feedback on my experiences using the tool, as well as to find ways to use it more effectively.

It seems that when DynDOLOD validates textures used by meshes, it stops at the first not found and reports it, then skips to the next mesh. Is this correct? For example, it gave a warning like this: Warning: File not found textures\texture1.dds. Used by meshes\mesh1.nif plugin.esm TreeEditorID1 [TREE:xxxxxxxx] So I provided the missing diffuse texture1.dds, expecting that that mesh would be good to go on the next run. But the next time I ran DynDOLOD, it gave a new warning: Warning: File not found textures\texture1_n.dds. Used by meshes\mesh1.nif plugin.esm TreeEditorID1 [TREE:xxxxxxxx] Same mesh but now it's the normal texture. It's done the same with several meshes. Can you confirm this is the intended behavior as implemented? If it is, may I suggest, as a possible improvement, to report all missing textures for a given mesh at once, rather than incrementally, as the current behavior can be a bit counter-productive and time-consuming. Unless the idea with the current behavior was to save processing time by skipping over as soon as a mesh is deemed 'defective'?

Thanks for your reply. I couldn't agree more, but the unfortunate fact of the matter is that some mod authors do not understand, or are not even trying to understand the value of DynDOLOD as a custom LOD generation tool, and as a validation tool. They get very touchy and jumpy, and tend to be dismissive. In that particular case, I suspect the mod author gave me a bogus reason just to dismiss my report. Right. I actually just did that and I still got the missing meshes/textures warnings. So either the objects are placed in vanilla worldspaces such as Tamriel, in which case the mod author is lying or has no clue how their mod works. Or DynDOLOD still validates all references even if they're in unselected worldspaces? I need to double-check in xEdit. It's not that I don't want to generate the LODs but if the mod author is not cooperating there is not much choice than blacklisting specific worldspaces or the entire mod. I don't want to see the DynDOLOD warnings if I can't do anything myself to fix them and the mod author is not going to fix them - it's just noise that drowns the useful, interesting messages. I have been getting these unexpected LR bug warnings with Alpha 106. Expected because they are indeed initially disabled LRs, but unexpected because the warnings refer to DynDOLOD.esm rather than the last overriding plugin before it in the load order. It's not a bug per se, as DynDOLOD.esm is indeed the last plugin to override these references (swapping the base for a NOFLAG variant), it's more of user interface / message clarity issue. Is this normal? Warning: Initially disabled large reference in DynDOLOD.esm [REFR:000D3F51] (places ImpExtRubble01_DynDOLOD_NOFLAG [STAT:7C025EA4] in GRUP Cell Temporary Children of WhiterunWatchtowerExterior [CELL:00009A26] (in Tamriel "Skyrim" [WRLD:0000003C] at 0,-4)) Warning: Initially disabled large reference in DynDOLOD.esm [REFR:000D54D9] (places ImpExtRubble01_DynDOLOD_NOFLAG [STAT:7C025EA4] in GRUP Cell Temporary Children of WhiterunWatchtowerExterior [CELL:00009A26] (in Tamriel "Skyrim" [WRLD:0000003C] at 0,-4)) Warning: Initially disabled large reference in DynDOLOD.esm [REFR:000D54DA] (places ImpExtRubble01_DynDOLOD_NOFLAG [STAT:7C025EA4] in GRUP Cell Temporary Children of WhiterunWatchtowerExterior [CELL:00009A26] (in Tamriel "Skyrim" [WRLD:0000003C] at 0,-4)) Warning: Initially disabled large reference in DynDOLOD.esp [REFR:000E43B7] (places Farmhouse05Destroyed02_DynDOLOD_NOFLAG [STAT:7C025E6E] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at -2,-2) Full relevant logs here if you want to take a look: https://drive.google.com/file/d/1nf_iChx9u8uXy1FxKzAe7A_etR3fMa_r/view * Only running DynDOLOD for validation and sanity checking at this stage, ignore complaints about TexGen textures missing etc. Not using LR workarounds.

Hello, I have a few comments and questions. I don't mind at all installing new DynDOLOD Alpha versions from scratch each time a new update comes out - that's an understandable, necessary part of the process to ensure a clean, up-to-date slate. I'm a bit annoyed by having to set up all options from scratch in Advanced mode after each update, though. So I've been cheating: I reload a preset saved from a previous version, which can be the default one (DynDOLOD_SSE_Default.ini) that DynDOLOD generates automatically. Is this bad, doctor? I have a suspicion that's it's not very good, because the preset file appears to contain rules copied verbatim from the "factory/built-in" rules. In case some built-in rules changed from one version to the next, the new rules would not be reflected after reloading the preset. If all REFRs to a STAT are marked Deleted in a patch, DynDOLOD still considers that the STAT has references and keeps validating it. So even if there are no more references to this STAT in the full load order, it still issues warnings about a missing mesh or texture, even though they will never be loaded by the game. I understand this is probably a byproduct of how xEdit works (as xEdit still counts those deleted references), but it's rather misleading. The only way to suppress the validation and warnings, is to completely remove the REFRs directly from the plugin. Which is fine if it's an old mod that's not been maintained in ages, but much less viable, compared to a patch, for a mod that's actively maintained and regularly updated (in which case the removals have to be applied again, and again). After I reported some issues with missing meshes and textures detected by DynDOLOD to a mod author, the mod author replied that I wasn't supposed to generate LODs for the new worldspaces in their mods, because some of them are unfinished (fair enough, thanks for not telling us) and the others "are too small for LoD to be an issue". Yet the mod is packaged with ../lodsettings/*.lod files for some of those worldspaces. What exactly is the purpose of the lodsettings file? I know DynDOLOD uses them to determine if they are eligible for LOD generation, and thus selectable in the list of worldspaces. But how are they used by the game? Are they generated on demand by the mod author in CK, or automatically by CK without the mod author's knowing? Is there a configuration file-based mechanism to tell DynDOLOD to ignore a whole mod or specific worldspaces? Preferably an ad-hoc external mechanism, not by editing ../Edit Scripts/DynDOLOD/DynDOLOD_[GAMEMODE].ini or ../Edit Scripts/DynDOLOD/Configs/DynDOLOD_[GAMEMODE]_mod_world_ignore.txt which are reset to factory state with each update (see 1st point above). And now for something that has nothing to do with DynDOLOD: What is the meaning of the 'Small World' flag on a worldspace, and what is its significance in regards to LODs, if any? I can't find any useful information online, other than "small world loads faster". Why is it a flag that can be set at will by a mod author, seemingly regardless of the actual world size, and why is it not determined automatically, either by CK or the engine? Thanks

I understand the need for visual compatibility with Majestic Mountains, aptly provided by the MM LOD Pack, there's no denying that. It's just that, each taken on their own, irrespective of their visual compatibility with MM or vanilla, respectively, many DynDOLOD Resources LOD models look better to me quality-wise than their MM LOD Pack counterpart. I'm wondering if using a higher resolution mountainslablod.dds texture would help reduce the fuzziness/stretching observed on some MM LOD Pack models? If so, is it possible to instruct TexGen to generate, say, a 1K mountainslablod.dds texture instead of 512x512? If so, could you tell me how to do it for testing purpose? I'm probably thinking about this wrongly and this is a matter of UV mapping more than resolution, but asking just in case. Thanks for your input.

Oh I see... Now sorted, and solved. Thanks for the quick response! Should I expect that Beyond Reach is going to have mismatched mountain/rocks lod textures then, as it seems the same mountainslablod.dds filename is used for 2 completely different source textures, whether Majestic Mountains or Beyond Reach? I have no idea how Beyond Reach lods are supposed to look, as I've never been "there" yet, so to speak. Ugh, I swear I looked at https://dyndolod.info/Mods, but I stopped at https://dyndolod.info/Mods/Useful-3rd-Party-Mods and didn't find anything, instead of scrolling down. I'm silly, sorry. Thanks for the confirmation. That being said, I'm a bit perplexed by the notable quality differences between DynDOLOD Resources and MM LOD Pack. Looking at several lod meshes available in both packs, those in DynDOLOD Resources look much better to me at first glance than the MM LOD Pack ones - they use higher resolution, full model textures, seemingly exhibit better UV mapping, and in some cases, they have more vertices/are more detailed. A few examples: DynDOLOD Resources > MM LOD Pack Putting aside the texture differences, it seems to me that the MM LOD Pack is a "downgrade" overall compared to DynDOLOD Resources. What am I missing here? I'd like to hear your take as you're familiar and involved with both. Thank you much for your attention and help, as always.

I'm referring to the LOD meshes for large rocks provided by MM LOD Pack. Mine look ugly compared to those provided by DynDOLOD Resources. A few comparison shots: DynDOLOD Resources > MM LOD Pack. /meshes/lod/rocks/rockl01_lod_0.nif /meshes/lod/rocks/rockl03_lod_0.nif /meshes/lod/rocks/rockl05_lod_0.nif Ignoring the difference in the textures themselves (which is a separate issue), and considering only the quality, the DynDOLOD Resources' version is much better. It's not really surprising I think, since DynDOLOD Resources' meshes use the full model 2x1K textures /textures/landscape/mountains/mountainslab02.dds, while MM LOD Pack's meshes use the puny 256x256 LOD texture /textures/lod/mountainslablod.dds. So what's the deal with MM LOD Pack? This is so confusing. I'm tempted to experiment with DynDOLOD Resources overwriting MM LOD Pack instead of the other way around. Please share your results/experiences if different, and your thoughts on the matter. Thanks.

Good for you I've had this issue for some time and have run several versions of TexGen since it started. Anyway I just reran it now just in case. No improvement, but I confirmed that the config files are loaded: Loading configuration files ... <path>\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_TexGen_noalpha_majesticmountains_landscapeesm.txt <path>\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_TexGen_copy_majesticmountains_landscapeesm.txt ...

Thanks for the tip. MajesticMountains_Landscape.esm is enabled at all times and has not been renamed. MM LOD Pack's FOMOD has options for 'Main' (normal), Darkside and Lightside to go along with the full model textures in the main mod. You may have chosen different options between the two? Here are my mountainslablod.dds, DynDOLOD Resources > MM LOD Pack > TexGen:

How should I go about troubleshooting this issue: textures/lod/mountainslablod.dds generated by TexGen doesn't match the full model textures at all. Relevant excerpt of load order (next overwrites previous): DynDOLOD Resources Alpha 27 Majestic Mountains Majestic Mountains DynDOLOD 3 LOD Pack TexGen Output mountainslablod.dds as generated byTexGen is overwriting MM DynDOLOD 3 LOD Pack's version (which itself looks good and matches the full model textures), and is looking like a brighter version of DynDOLOD Resources Alpha's vanilla texture. TexGen's debug log tells me: Creating <path>\TexGen_Output\textures\lod\mountainslablod.dds from 9 textures I don't know where to go from there. Before you ask: yes, TexGen is run with the same load order as above and same as used in-game. Also noteworthy, for example with meshes/lod/rockl05_lod_0.nif: DynDOLOD Resources's version uses the full model texture textures/landscape/mountains/mountainslab02.dds and it looks correct in NifSkope. MM DynDOLOD 3 LOD Pack's version uses the lod texture textures/lod/mountainslablod.dds and it looks wrong in NifSkope (due to the texture mismatch and overwriting by TexGen). There are related, repeated questions on the MM comments section that remain unanswered. Could we perhaps get a definitive answer: Is MM DynDOLOD 3 LOD Pack still relevant and up to date, or is it obsolete and should no longer be used? Which should overwrite what between DynDOLOD Resources Alpha and MM DynDOLOD 3 LOD Pack? Full DynDOLOD logs here: https://drive.google.com/file/d/1FRT_3cHSuexygEYiytyw-5RTk3SHhH4L/view?usp=sharing Thanks.

Designed for Lexy's LoTD modlist. Won't work with STEP. Requirements: OBIS, Omega, SkyTest Realistic Animals and Predators, USSEP, Serenity. But yeah, the potion distribution rules that EEOS provides are wacky. I didn't notice potions on dogs or horses as I don't fight them, but I was definitely bothered by pit wolves being given healing potions. Perhaps death hounds had them too, I don't remember. If you disable Potions and Shouts you can drop this mod entirely, as they're the only options that are currently used in the guide: Distributing potions/poisons to baddies' inventory is a good idea in theory. Besides its wacky distribution rules, the main issue with this mod is that unused potions remain after the baddies are dead: The default AI is pretty bad at consuming potions during combat to begin with. Stealth kills provide no opportunity for the AI to consume them. Either alternative, NPCs use Potions or Smart NPC Potions - Enemies Use Potions and Poisons, alleviate this issue by ensuring that potions/poisons are used during combat and/or removed upon death.

From SoS' FAQ: The main differences that I know of between SoS and others: It uses a non-single pass (which makes it a multipass I guess?) shader. No idea how that translates in practical terms, whether it's better or worse. It uses a very small plugin that doesn't edit any reference in the world, so it's compatible with any mod that edits the world. Compared to BDS for instance, which edits several hundreds references, and so requires patches with other mods, and workarounds for large-reference bugs.

To clarify: The NiAlphaProperty is on the wood nodes, not the bark. So it has no bearing when looking at and comparing effects on bark. These all look "shiny" to me. Maybe shiny is not the right qualifier, I don't know how to describe it well. It looks like the bark is made of metallic material, not of wooden material. Compared to the wood pieces, which are also covered in snow: those look 'dull' in comparison, not reflective, as would be expected of wooden material.

Jewelry: no idea. Potions: Enemy (R)Evolution of Skyrim. Over time I found that this mod tends to break the game economy and makes Alchemy a lot less useful. The vanilla game already sprinkles a lot of potions/poisons throughout the world. With this mod, looting corpses brings even more potions/poisons. To the point where I had no need to brew my own potions/poisons and I could make a lot of money from selling those I found and looted, I had so many of them. I ended up disabling the potions of Enemy (R)Evolution of Skyrim, keeping only the Shouts for NPCs. And I switched to NPCs use Potions which is a lot more sophisticated, and removes potions/poisons from NPCs upon death. It's so sophisticated that it may be a little too complex for its own good. But it works pretty well for the most part.

Hi sheson, Whenever it's convenient for you, could you please update the waterfall lod meshes in DynDOLOD Resources SE for the latest version (2.0) of Water Effects Brightness and Reflection Fix - Realistic Water Two Patch. The fxwaterfallbody*.nif models were updated and their CRC32 have changed. Thanks in advance.

I just updated to 1.04. Thanks for all the updates, Z. I hate to be a pain in the firewood once again, but I'd like to share a couple of issues I've encountered. They're not new, but I didn't want to report anything before I could spend the time to test and investigate, that is until now. All tests were made using 1.04. The following is quite long. Apologies for the flood of information, but I'd rather err on the side of too much than not enough. 1. "Shiny" bark textures on firewood piles painted with Snow material. First let's see what we're going to be looking at: FirewoodPileLarge01_LightSN: firewoodpilelarge01.nif using snowy bark texture and painted with Snow material shader. FirewoodPileMedium01_LightSN: firewoodpilemedium01.nif using non-snowy bark texture and painted with Snow material shader. Next, comparison screenshots showing different combinations of meshes and textures, and resulting more or less shiny bark. Vanilla/HLT mixed combinations look weird due to UV mismatch but they're provided for completeness. The shots were taken using Cathedral Landscapes' snow shader, Cathedral Snow 'Brighter' snow textures, and HLT's 'Alternate Snow Texture 2' snowy textures. From left to right: Vanilla mesh + textures > HLT mesh + textures > Vanilla mesh + HLT textures > HLT mesh + Vanilla textures The shiny effect can be more or less pronounced depending on weather/ambient lighting. (Differences of direct lighting in the shots above were caused by a guard who kept walking behind me with a torch in hand.) There are too many factors involved and I'm not knowledgeable enough to pinpoint the cause of the issue, but I suspect there may be some bad interaction between the HLT bark textures and the snow shading that is applied to it. I should note that the issue is present with the non-snowy (medium pile) and snowy variants (large pile) of the bark textures, as can be seen in the screenshots above, and that in my experience the bark doesn't look shiny on "normal" piles (i.e. not snow-shaded). 2. Compatibility of firewood pile meshes with Simplicity of Snow. Simplicity of Snow is the snow shader I'm actually using in-game, but I disabled it in the previous tests above to eliminate one more factor and avoid conflating multiple issues. The following screenshot shows that snow is not painted on the wood: Cathedral Snow Shader > SoS Snow Shader The issue is caused by HLT's firewood meshes which have a NiAlphaProperty. As explained on SoS' compatibility section: After removing the NiAlphaProperty in NifSkope, the results are correct: Before > After Is there a specific reason that the wood needs to have transparency in the HLT firewood meshes? If not, could this be removed so they can work with SoS? And now for something completely different... or is it? Have you seen this newly released mod: Happy Little Shrubs? It's a set of shrub meshes designed to work with HLT's textures. Check it out: Vanilla > Happy Little Shrubs Seeing the mod on Nexus got me excited, I thought it was a great idea, but after checking it in-game, I'm going to wait until it's improved. My concerns are: For some unfathomable reason, the shrub replacers are all much smaller than vanilla. There is too large of a gap in size between the shrubs and the grown trees, especially if using the larger trees. The snowy variants don't look too good, especially up-close. Trying to UV-map the original textures onto the shrubs must be hard and the results are pretty messy IMHO. That's all. For now... anyway... Thanks for reading.

I was doing some minor visual mod maintenance in my load order when I noticed something peculiar about this mod, to which I paid no attention until now. When used with Particles Patch for ENB - Loose Files + Custom Textures, this mod is completely useless: all of its 3 BSA-packed textures are overwritten. It's actually worse than useless, it's a waste of a plugin slot. I agree with the previous comment by kapebo: this mod using a BSA for just 3 textures, a dummy plugin to load the BSA, and a full plugin at that, not even an ESL, is the epitome of silliness. The STEP team can decide what they want to do with this mod, considering that: As things stand in the guide, it's useless and a waste. Particles Patch for ENB provides 2K textures vs. this one's 1K. The original version 1.0 of this mod for LE is still available, and comes as loose 1K files. DUST By Ramccoid may be a good alternative. It's a mesh + textures replacer that seems to be highly rated. Textures come in several resolutions: 256, 512, 1K and 2K. The meshes can be used with other textures. I have no personal experience with that mod but I may be giving it a try. I'd strongly recommend that MO's BSA-parsing feature be turned on, particularly for STEP maintainers and curators. You'll be surprised by how many conflicts you discover and didn't know existed before. It slows down MO to some degree, depending on how many mods and BSA there are, but it's absolutely worth it IMHO. MO > Settings > Workarounds > Options > Enable archive parsing (experimental)

The CR patch carries forward changes that don't require the parent mod plugin to be a master of the patch. For example, if several mods change the gold value of a vanilla item, this creates a conflict. The CR patch resolves it by carrying forward one of them so that it "wins". An item value is just a number, it doesn't require anything from any of the mods that change it. The only hard dependency is on the vanilla masters which contain the item (e.g. Skyrim.esm).

You can use the original OldRim version of the mod as-is: https://www.nexusmods.com/skyrim/mods/3589. Download and install the 'Natural Eyes High Res' main file. The SSE version of the mod appears to have been a lazy reupload of the original, without any changes (the file sizes/dates are identical), by a 3rd-party who may have violated some rules, hence its removal.

I went to the FWMF mod page and re-read the DynDOLOD 3 Alpha instructions. I was mistaken, it's not that they think it doesn't work at all, but they provide a convoluted procedure that doesn't fit at all with the STEP standard xLODGen + DynDOLOD procedure. So again, I'd recommend ignoring those instructions and sticking to the STEP instructions for xLODGen + DynDOLOD. The only deviation is to resolve the LOD32 Terrain meshes conflicts as mentioned before. Instead of removing/hiding the xLODGen meshes, you could sort xLODGen Output mod before the FWMF mods on MO2's left pane so that the latter overwrites the former. This may be a better, more foolproof, approach in the event you need to regenerate terrain LODs with xLODGen - otherwise you'd need to remove/hide the conflicting LOD32 meshes again. There are also LOD32 Terrain meshes conflicts between some paper maps (depending on which ones you pick) and Cathedral Landscapes. Again you need to make the paper maps win by overwriting Cathedral Landscapes.

I'm using FWMF with a bunch of paper maps along with DynDOLOD 3 Alpha and everything works just fine I think the warning about DynDOLOD on the FWMF page is misinformed/misguided. Some user, perhaps the MA himself, encountered some issue that they weren't able to resolve due to misunderstanding and lack of perseverance, and wrongly concluded, as is sadly too often the case, that it can't work at all. My advice: ignore the advice There are some manual steps to be taken to make both work together. Unfortunately I worked on that some time ago and I can't quite remember what I did... What I do remember for sure is: you need to hide or remove the LOD32 Terrain meshes (/meshes/terrain/worldspacename/*.32.x.y.btr files) generated by xLODGen Beta that conflict with the FWMF paper maps. The FWMF LOD32 Terrain meshes need to win, otherwise the flat paper maps won't be displayed. In any case, you should run DynDOLOD 3 Alpha on the entire load order, including the FWMF plugins, as is the standard procedure. I also have a custom patch plugin that I made in xEdit specifically for FWMF but I don't think it's related to DynDOLOD. I'll have to take a look at it again to remember what it does exactly. I'll get back to you later on that. In the meantime, my recommendations: Remove 'A Clear Map of Skyrim and Other Worlds', and 'Unique Map Weather Framework' from your load order, as you won't need or use them anymore. Install FWMF, the Throat of the World fix, Flat Map Markers, and your chosen paper maps. Keep xLODGen Output, hide or remove conflicts as explained above. Temporarily disable DynDOLOD Output and all its plugins. Sort with LOOT. If I remember correctly, you'll need to create custom sorting rules so that the FWMF and paper map plugins are sorted towards the very end of the load order, because LOOT doesn't know how to autosort these plugins correctly. I used the 'Worldspace Settings' Group, which gives the desired results: Test in-game that your paper maps work correctly, without DynDOLOD. Run DynDOLOD to regenerate the plugins with the new load order. Test in-game with DynDOLOD. If you run DynDOLOD again in the future to re-generate LODs, you can disable all LOD32 rules since you won't be needing them anymore (they're only useful on the 3D maps), which will save you a bit of processing time.

There are 3 fog size variants available: 20% size reduction (compared to original OMF), 10% size reduction, and no size change. I installed the -20% one. Now I can see the mountain peaks - much better IMHO.

It's either EnaiRim or SimonRim, you can't really have both at the same time. STEP went partly with EnaiRim, using Vorkrii and Odin - probably because they're closer to vanilla. So SimonRim was out. Off the top of my head, you'll need to remove at least CACO, Vokrii and Odin, and their associated patches, from the STEP load order, then remove those dependencies from the STEP CR patch(es). Then you can replace them with their SimonRim equivalent. Finally you'll need to add compatibility and conflict resolution patches with the other mods remaining in the load order, as applicable.

Obsidian Mountain Fogs Tweaked I haven't tried it or even looked at it yet, but might be a good option for STEP.