Mousetick

No I didn't try with with CL brighter snow because at the time I wasn't aware of its existence. I shall try it when I get the chance. Any tree that have snow on them, painted or piled, or on the trunks. Look at the texture atlases in textures/landscape/trees/Northern Hemispheres, e.g. DeadAtlas.dds, PineAtlas.dds, SnowBark_Atlas.dds.

Hello DY Have you had a chance to try ACMoSaOW with the latest xLODGen beta (90) and DynDOLOD alpha (73) and DynDOLOD Resources alpha (20)? I'm experiencing 2 issues: water/terrain z-fighting and trees missing on the map. I'd been using xLODGen beta ~85 and DynDOLOD alpha 64 with ACMoSaOW 2.1.1 up until recently, and everything was fine. After updating to the aforementioned versions, it's broken. I'm wondering if I did something wrong on my end or if the problem is elsewhere. I've double- and triple-checked my DynDOLOD INI config and rules, re-generated all the LODs several times to no avail. I'd like to get a second opinion if possible from you if you can reproduce the issue(s). Thanks. Edit: trees are working, was a luser mistake. z-fighting occurs when scrolling the map.

It doesn't really make sense to merge Position and Rotation X/Y/Z fields, they both should be treated together as a cohesive whole in the context of their respective mod. Pick the version from the mod you want to win and copy both the whole Position and Rotation fields to your patch, without mixing Position or Rotation or X, Y or Z. It's easier and better. In general there are 3 possible reasons for mods to change the position/rotation of an object: a) to fix an issue, b) to cosmetically "improve" the scenery, or c) to make space for placing their own objects or as functional requirement for their own purpose. As a rule of thumb, you'd want to keep the version from the mod that's the most impactful and important for your gameplay, that is in order of priority: (c), then (b) then (a). If several mods conflict on the Position or Rotation and have the same level of impact, the rule of thumb is not good enough and it'll likely be necessary to visually inspect their respective changes in-game or in Creation Kit, in order to make a decision on which one should win. In your particular case, you'd probably want to keep the Position & Rotation changes from BDA. And since BDA is probably sorted after SMIM by LOOT in your load order, there may be no need to patch the conflict in the first place.

Confirmed with Alpha-69, which is the latest I've used since 65. Can't keep up with all the updates

The first 2 characters are the load order index of the mod if it's an ESP/ESM (if it's an ESL-flagged ESP/ESM or an ESL, the load order index is specified in the first 4 characters "FE nn"). Make sure your load order is exactly the same between in-game and in xEdit. Not only the list of mods, but their relative order in the list. If they're different, the IDs won't match. An ID 05000832 means the object comes from the 6th plugin in your load order (including the vanilla plugins). You can install More Informative Console to get a lot more information in-game than with the vanilla console.

Oh wow, that certainly makes things easier. Not any safer, mind, but it does exactly what the OP had in mind. I'm with you DY. I think it's a good idea in principle, as it solves both issues mentioned in the OP, but it could be troublesome in practice. My knowledge of references is quite limited, but my understanding is: Persistent references are permanently loaded in memory as soon as the game starts and never released until it exists. Temporary references are allocated and released in memory whenever their parent cell is loaded or unloaded respectively. All references loaded from an ESP plugin (vs. ESM) are treated as persistent by the engine, whether they're defined as temporary or persistent in the plugin. So making an ESP plugin into an ESM could expose "use-after-free" bugs in some plugins. For instance a Papyrus script triggered by a background quest could (incorrectly) access a temporary reference while its parent cell is not loaded. In an ESP this would not be an issue since the temporary reference is actually persistent in memory. Once the ESP is loaded as an ESM however, if the parent cell is not loaded, the reference could point to another object, causing unexpected behavior, or in the worst case cause a memory access violation CTD. I'm assuming CK has checks in place to ensure all references potentially used outside of their parent cells are made explicitly persistent in the plugin. However there might be cases with manually written scripts accessing references directly without using properties/aliases or with plugins manually edited in xEdit, where such validation checks are not enforced. In the best scenario where the plugins and their scripts are defining and accessing temporary vs. persistent references properly, it should make no difference whether they're loaded as ESP or ESM. That being said, it's probably a bad idea to switch ESP to ESM mid-game, due to potentially unknown differences in how temporary vs. persistent references are stored in a save file.

In theory this should work. I've flagged a few mods as ESM in xEdit to fix the overwritten large reference issue with LODs, but only on an as-needed basis. If you can make a tool that automates the ESM-flagging to the whole load order that would be useful. The problem with flagging mods piecemeal is that one needs to keep track of which ones have been flagged, so they can be re-flagged in case they're updated later. I don't see how it would be necessary to redo and undo this process every time the game starts and quits. What would be the purpose? It could be done once and for all.

Not necessarily. If there are 2 (or more) folders containing Skyrim SE/AE, and the registry entry is currently pointing to one of them, the Skyrim launcher will not update the registry, even if it's run from a folder not specified in the registry. If you then click "Play", the Skyrim launcher will relaunch itself using the executable in the folder specified by the registry. It's a confusing catch-22. Been there, done that This may be what happened to the OP. Perhaps they copied their Skyrim installation folder somewhere else, leaving behind the original within their Steam library folder, instead of moving it.

Yes it's the easiest and most compatible approach if you moved Skyrim to a non-standard folder location and you're not a "power user". All the tools will just work with the new location without further tweaking necessary.

Very nice comparison shots, thanks. As an alternative to Luminosity and to provide darker interiors, I've been using Ambiance - A Vanilla(plus) Ambient Lighting Overhaul (by TheMilesO). It only modifies ambient lighting templates to make interiors a bit darker or much darker depending on the environment (e.g. cave vs. farmhouse vs. palace). It also tweaks interior fogs to make them less opaque and less bright. Everything else remains untouched and vanilla. There is an optional plugin which I'm using too, to make lights a little warmer than vanilla, but not as orange as Luminosity. This mod is rated well for stealth balance by RAID's MA (bottom of chart). It works well in combination with Relighting Skyrim since they do different things, except when they don't. For instance, RLS removes some ambient lighting in the Thalmor HQ in Solitude, which makes it as dark as a cave with Ambiance. There are some caveats though: the MA seems to be MIA and the mod is not maintained. So if updates are needed for AE CC content for example they won't be coming anytime soon. Also its user base is tiny, compared to more popular lighting mods (probably because it's not flashy enough). So there are no compatibility patches for new interiors added by CRF for instance or by other mods. It's easy enough to replicate the template changes in a custom patch by oneself if desired.

I installed this mod as soon as it was released. Up until now I had been using no weather mods. I had only a trivial mod to simply make the nights darker (aptly named Darker Nights), everything else vanilla. I haven't been using ENB and have no plans to use any kind of post-processing. I had previously evaluated a bunch of weather mods, including CW as part of the STEP guide, and I liked none of them. There was always something that wasn't quite right, being the lighting, the colors, the effects, the performance... But in general my feeling is that many weather mods like lighting mods tend to be "overdone" and seem mostly designed "for show". I'm not interested in a Disney World, I simply want an enhanced Skyrim. So anyway, long story short, I've only been trying this one for a few days. First impressions: I quite like it, it's very nice. It's going to be a keeper I think but it's too early to tell. Very small performance impact if not negligible, close to vanilla in terms of atmosphere, done in moderation. I haven't experienced the really strong weathers like blizzard or torrential rain, yet. My only gripe so far is the frequency of weather changes. I'm going to be playing this game for dozens and dozens of hours, I don't need to experience the whole catalogue of weathers in the first hour of gameplay I seem to remember the change of weather every ~15 minutes seems to be a common theme among weather mods. I don't get it. No big deal though, should be easy to patch. I've kept the galaxy and star textures from the STEP guide (i.e. 8K Night Skies - Stars and Galaxies - Cathedral Concept). I don't know how the ones provided with the mod look like. That being said, I wouldn't consider it for inclusion in a STEP guide. It makes the nights really, really dark. I don't mind myself, but this is a big difference from vanilla, and it makes the game less accessible to the average player, I think. With darker nights and overcast weather, it becomes even more important to tone down the brightness of landscape, flora and fauna, so mods like FML and similar mesh lighting fixes in other mods become a "must". At least for me. I can't stand the glow-in-the-dark stuff. I'd recommend you give it a try yourselves whenever you get the chance.

You're probably right. I don't know much about snow and I rarely see it in reality. So I wouldn't disagree. If I had been using ML all along I'd have been accustomed to it and I might have found that the snow on HLT trees looked fantastic, seamlessly integrated into the landscape. I could still keep CL and overwrite it with ML's snow I guess. But it's so blue in places sometimes depending on the light... My eyes are used to looking at "white" vanilla snow, so it's quite a shift. Nevertheless the issue remains: the snow on HLT snowy pines, as good as it may be, doesn't match any Skyrim snow other than ML snow. That severely limits the appeal and compatibility of the whole HLT mod as a result. Unless patches are made for the most popular snow mods, or unless users don't care about the mismatch, it's going to be an obstacle. It's easier to mix and match varying shades and brightness of white than to mix and match tints Shouldn't snow on its own be a neutral white, and change color depending on thickness, temperature, light and other environmental factors? The problem with T4's snow as I see it is that it's already intrinsically colored. When viewed in an image editor, the texture has a teal tint.

It took me a while to find a solution so this may be helpful to others. The problem: footprints don't work on a new game starting as a new character with the preset equipment. They work on NPCs, but not on the player. The solution: unequip shoes/boots and re-equip them. The issue is specific to this mod. It doesn't occur with the original Footprints mod used alone. Other factors may be involved, like using ASLAL to start - I don't know.

This mod uses custom unique meshes that would not be fixed by any of the aforementioned mesh fix mods. There is however a new recently released mod specifically to address the over-bright particle effects (speckles or strange "gooey" clumps of snow): Footprints Bright Snow fix (by TemplarSwift). There are 2 versions: One that makes the snow particles less bright One that removes the particles completely, leaving only the footprints behind It only modifies the human footprints on snow. Beast footprints and any footprints on ash are not covered, maybe it's an oversight, maybe they don't need to be fixed - I don't know. I did test the mod and it works as intended with humans on snow. There is another mod that extends footprints to sand and mud: Footprints Sand patch (by modal1 and Vai1lyn). I've installed it but not tested it yet.

One detail that I hadn't been paying attention to has become a big issue: the snow texture on the snowy "pines". It doesn't match whatever snow texture may be used for landscapes, unless one uses Majestic Landscapes from the same MA. I experimented with only using the snow and snowy textures from Majestic Landscapes, but the snow style is too strong for my taste: it's very bright and very "cyan". First, to eliminate any doubts about possible setup mistakes on my side, a simple comparison between vanilla snow and ML snow in a vanilla game: Vanilla > Majestic Landscapes Snow Now switching to a fully modded game, using STEP as the base, with HLT snowy "pine" trees replacing EVT. Hyperborean Snow is included in the comparisons because that's what I'm using. It's slightly brighter and shinier than Cathedral. Cathedral Snow (from Cathedral Landscapes) > Hyperborean Snow > Majestic Landscapes Snow The snowy pine trees jump out and look completely wrong unless ML snow is used. So why not keep and play with ML snow? It's very nice, but it's too far from vanilla, too bright and too cyan for me, and it gets worse when used with weather mods which alter the light. I've been testing RAID Weathers, so it's used in the comparisons: Hyperborean Snow + RAID Weathers > Majestic Landscapes Snow + RAID Weathers Under a clear blue sky, some light cyan tinting can be seen on the Hyperborean snow but it's very subtle. But look at the ML snow - it's almost solid cyan! Not good... I managed to hack the HLT snowy pine texture in Paint.net and replaced the large snow coat by cutting and pasting Hyperborean's snow01.dds texture, which gives pretty good results: Hyperborean Snow, Hacked HLT, No Weather > Same + RAID Weathers It's not perfect though, there remains bits of snow textures in the HLT atlas that would need to be replaced as well. They can be seen in the previous shots by looking closely. I'm not sure I'm going to be able to fix that with my very limited skills and tools. I may have to live with the remaining defects. On the matter of mixing HLT and Aspens Ablaze, there are no major issues. If both the HLT full set and AA plugins are used, LOOT sorts HLT after AA, so the resulting conflicts need to be resolved either by a small patch or by manually re-ordering the plugins so HLT is loaded before AA.

Ok, will do then. I saw someone made the same remark back in Nov. about the firewood texture in the comments section: The MA didn't respond. Another user did respond, suggesting to use another mod for the firewood logs, with yet a completely different look

I think the issue may lie in the fact that this mod was in the 1.0 guide, and it remains in the 2.0 guide with the same Medium / Medium setup, which may not be adequately balanced when used with the L&W mods. Medium / Medium was probably fine with vanilla lighting in STEP 1.0, however it may have been insufficiently tested in STEP 2.0 with the additional lighting mods (and possibly ENB). @steeleb is mentioning "Cathedral" several times so I'm assuming he/she's referring to Cathedral Weathers, which would mean following the STEP 2.0 guide and using all the mods in the L&W group. This mod's MA specifically recommends using Light Ext. with Catheral Weathers, and Medium Int. with Luminosity. It's unclear what should be used when ENB is combined on top. It's worth noting that both Cathedral Weathers and Luminosity are rated badly for detection balance and consistency by the MA in their evaluation. If you're not having fun throughout, you can uninstall this mod, or try the Lite version. Fortunately this is one very simple mod which can be installed and uninstalled at will without breaking your game. If you're having trouble with just this specific quest, try an invisibility potion or spell maybe?

I'm fine with it too. I'm not familiar with the specific type of scaly bark that was used, so it looks a bit strange and foreign to me, but it looks very much like conifer bark, so doesn't feel out of place. I like that 2 types of bark are used. Again it makes the world feel more natural and less like artificially carbon-copied objects to me. What bothers me (a little) is that for some reason the mod replaces the wood texture (firewood01.dds) of the firewood logs, but not their bark texture (treepineforestbarkcomp.dds). As can be seen in the previous screenshots, the firewood logs bark is the vanilla one, with a greenish tint. This inconsistency is jarring, since there are no trees in the game with this bark once HLT is installed.

That was exactly my thought too. The interesting 'Deleted references' warnings are drowned among the numerous vanilla masters. My comment specifically referred to the base SSE game vanilla masters (namely Skyrim.esm, Dawnguard.esm, Dragonborn.esm, HearthFires.esm and Update.esm), but sheson's response generalized the issue to CC modules and mods. It looked like the discussion would immediately devolve into one of those "should the vanilla masters be cleaned" endless debates, so I bailed out An "advanced" option to whitelist some masters in DynDOLOD.ini, off or empty by default, would indeed be nice.

Oh, it's xEdit's logger. I hadn't thought about that. But yes of course, makes sense. Well, never mind then No, once DynDOLOD.esm is saved, everything is fine. Both in xEdit and in game. No "missing an overriden record" in xEdit when loading DynDOLOD.esm. I'm not too worried about this warning since I can't see any negative effect in-game, but I mentioned it in case you'd want to know about it. Thanks for looking into it anyway. Let me know if you need more info or you'd like me to make specific tests. And thanks for all your answers, much appreciated.

Yes ideally DynDOLOD would generate a "blacklist" of overwritten large references. Then a DLL like SSE Engine Fixes or similar engine-level runtime patcher could read that blacklist and skip the RNAM entries while loading the ESM WRLD records. That'd be quite neat... Are you familiar with CommonLibSSE? I'm not, but it looks like it reverse-engineers a lot of data and APIs. Impressive stuff. For example, the in-memory data-structure of a Worldspace, including the Large References: https://github.com/Ryan-rsm-McKenzie/CommonLibSSE/blob/master/include/RE/T/TESWorldSpace.h. I thought this was related to updating the DynDOLOD plugins too, but it's actually not, as I've re-run it from scratch several times and the warnings are still issued. Using Alpha-65. Here you go for the logs: https://drive.google.com/drive/folders/1fQvv6PVQ5uC3w_lQuFlT0K29O6BkgAeO Please change your logger so that it overwrites logs instead of appending, or it appends a session timestamp to log file names. It's really annoying to have to scroll past past sessions to find the last one in the logs - both for your and your users' sake. There is only one session contained in the logs linked above. Thanks.

Bark bark bark bark bark bark. HLT and nothing else. No comparison shots, no time for that, sorry. As you can see there are 2 types of bark: smooth and scaly. Unique HLT marsh tree (left), which seems to be simply a taller/thinner version of tundradriftwood (right):

A solution to the large reference bugs could conceivably be to remove the affected references individually from the RNAM list in the ESM, right? It seems it would be a more efficient and simpler way to address the issue, rather than splitting mods into ESM for large references + ESP for the remainder, or than burying all large references in a cell + re-creating new identical but non-large ones. I tried this approach by removing one entry in the RNAM of Tamriel in a small ESM (RWT2.esm) with xEdit and that got rid of the corresponding DynDOLOD warning. Unfortunately xEdit is hardcoded to skip the RNAMs in Skyrim.esm, where most of the large references overwritten by mods are defined, so they're not viewable/editable. I'm going to try a workaround but I fear that xEdit's RNAM editor might explode due the very large RNAM of Tamriel. We'll see... Unrelated: what to make of the following warnings? "DynDOLOD.esm missing an overriden record" is not listed in https://dyndolod.info/Messages. Thanks.

Addendum: The 'Equip Echantment Fix' mod is supposed to re-apply enchantments for any actor at load. It can also recalculate the player's inventory weight at load, but this feature is disabled by default. You may need to enable it as well in your case. Refer to mod configuration settings in its INI file (SKSE\Plugins\EquipEnchantmentFix.ini).

You could try Equip Enchantment Fix. It may solve, or not, your specific issue.