z929669

I created LOD models for many stumps and small shrubs like TreeAspen4.in most of those I've done, IIRC (Myrkvior and maybe HLT, EVT, SRO). The assets are so small, I just created them for those that want that level of detail by using the INI settings sheson mentioned to lower the threshold for generation. You can test with these if you don't have a LOD model like TreeAspen04_CRC32passthru_lod.nif that match your TreeAspen.nif CRC32.

If you play the English version of the game, and you are not a mod author seeking to support translated text to the game, you don't need to worry about this one. Another mod we use (Who's Quest Is It Anyway?) requires this. I've not tested what happens with that mod if this isn't installed. Let us know if the mod relying on STPP-NG is borked though. If it is, you can just disable that one too.

FYI: ... probably trying to use the light master on and existing savegame rather than starting a new one as explained int he updated FOMOD instructions. Just choose the normal plugin option to resolve.

Nice catch

Avoid use of NMM. It's not reliable and has very limited functionality. Install MO / Configure MO (best support from this community) or Vortex as mentioned. Generate the xLODGen, TexGen, or DynDOLOD output in their default directory location on the OS and simply copy the contents of that folder into a mod folder of the mod manager using Windows Explorer. With MO: The mod will be at highest priority at the bottom of the list. Leave it there, and enable it. Right click the new mod, and ... Then use drag/drop from your ..\DynDOLOD\TexGen_Output\ directory or whatever method you like to move files.

It might be worth a look at some point for sure. Regarding Azurite, do you find it too bright without ENB? I ask because ENB must be tailored to the weathers specifically, so it may be that your ENB just isn't right for Azurite. Does Dr J recommend an ENB for it? I'd be interested in checking out his lighting, color, and weather mods together to see where it goes ... but not for a while!

I think it's a bulb alternative that seems similar to what Relighting Skyrim is doing. Ambiance and Luminosity should not conflict. I'd want to know what the MA is using for lighting colors. If you aren't' already, you may want to experiment with Azurite Weathers and Seasons, since I presume the MA uses that.

In fairness, it's an early beta release likely awaiting this kind of feedback. At the same time, I agree with your assessment, but I've always wanted the ability to see plugin conflicts in MO. For me, that's it's current usefulness ... just a quick snapshot of what's up in the Plugins tab without running xEdit. I also like the parallelism of conflict visualizations in the plugin context with that of the installed-mod context. Some of it is redundant, yes, but the contexts are quite different. I'm keenly aware that this seems to be reliant on LOOT metadata, which is curated and not real-time-factual (i.e., prone to human error and lag time for humans to add/correct it). Nevertheless, I like the insights it provides into LOOT logic. It's the 'groups' functionality and seemingly variable outcomes with LOOT standalone versus MO's integrated LOOT instance (which I've always disliked in comparison, since the latter is barebones in terms of its UI). Butch seems to get groups from LOOT standalone, but I do not (I only get them using the integrated LOOT, which I immediately disabled when it blew up the custom groups I created via this extension). Given what I think I've learned, custom group creation via this extension seems nonsensical and conflicting with it's apparent reliance on LOOT metadata. I've also been looking closely at the cyan/magenta "archive conflict" indicators and am seeing some inconsistencies for that. Some archive-conflict overrides trigger these indicators, while others do not, and I have yet to find the pattern that triggers it. Triggered: Not triggered:

I agree with you. It's the classic problem of 'logical' versus 'functional', which all gets really ILlogical when people make plugins that touch all sorts of record types (thus, the 'default', 'foundation', and 'misc' groups are born). It would all be simpler to manage logically if I myself were a computer ... but alas, I'm human and want to label and classify things logically AND functionally ... intuitively. It just can't be done without trade-offs. So many ways to skin the cat (sorry cat lovers, I am among your number and mean no offense to cats). I replied to you and the helpful jc43081 (jc-numbers). This is becoming another rabbit hole, and I should take solace that this plugin provides useful insights hitherto unknown before Then there's the whole argument that these game files should all be masters or light masters rather than ESPermanent ... too late! That would make sorting a bit more logical though.

Indeed, this looks great. I wonder how LOOT sorting works with the grouping, but I suspect it's intuitive (i.e., sort by group or by LO but sorting by both is impossible). I also wonder if gouops are or can be related to xEdit Mod Groups. <--Rhetorical questions. I will get my answers when I add this in the unforeseeable future EDIT: I posted on the Nexus Posts page with some findings. I can't link to the comment now that Nexus has uncoupled their forum integrations for Posts.

Step doesn't support downgrading the game and the mess of associated issues people have with that. There's nothing wrong with doing it, but we want to spare ourselves the headache and the labor associated with the majority of people who fail to RTFM. Others have provided reliable direction in this area, so go ahead and give it a try if you are so inclined. That said, I recommend reverting to vanilla and working with the latest version of the game (1.6.1170). REMOVE the game and all stored game settings and reacquire via Steam as instructed. You will likely need to revert all downgrade changes made to Steam manifest or reinstall Steam itself. Retain your MO mods and configuration for now (in case most of the mods you have installed are the correct versions and have been installed correctly). Our guides ONLY support the current versions of games to which they apply. THAT said, SSE modding is fairly broken ATM (thanks again Bethesda) and the current version of the game and available mods aren't straight forward to configure in any Step-guide-worthy manner. I've done my best to cobble some general instruction for running the latest version of the game in our 2.2.0 SSE guide, so read the newly-edited warning at the top of that and the changelog for more information. Also revisit the installation instructions for all mods noted in the post-release portion of the changelog. In particular, revisit SSE Engine Fixes instructions, as I've just updated them with a bit more clarity. I really don't want to verify exactly what version of SKSE and SKSE-dependent mods you are running, since that's too labor intensive for me at this time. Read the Nexus SKSE and SSE Engine Fixes sticky posts (and follow the links to more info). Also, the USSEP supports only the latest game version, and the same may be true for certain other mods (or selecting the correct version for some might not be as straight forward as we'd like). I've begun following all of my own advice^ myself, but my time is limited, and I haven't completed it ... no ETA.

And in the far recesses of my mind I knew this, but our instructions on need to better reflect it. It's easy to forget the details when it's only done once every year or two

39 is correct for 1.6.1170. We do note all possibilities, albeit, it's arguably TMI and convoluted. SE guide: SSG ("Verify the integrity of game files" instructions need minor update to Steam's updated UI): Back to the SE guide: It's easier to explain and support using Steam's validation to restore the files rather than instructing people one of the several ways of backing up files via the OS. Besides, it's always prudent to verify the integrity of the game cache via Steam when you're messing with the game files. UPDATE: I have my Steam Updates for SSE set to "Always keep this game updated". I had auto-updated to 1170 and cleaned all masters in the last couple of days, and all was kosher. At that time, LOOT flagged 39 masters as having ITM/UDR, so I thought I had cleaned them all, copied anew into my MO mod, and used Steam's "Verify the integrity of game files". Tonight, I was surprised to find that I only had 37 "cleaned vanilla masters" in my MO mod and my game Data directory. From Steam Lib while typing this post, I noticed that these cleaned mods were not considered in "Verify the integrity of game files", as they were still identical to my custom cleaned versions in MO. Further, I witnessed that "Verify the integrity of game files" was not reacquiring the original masters, I deleted the now 37 masters that I had cleaned from Data, but they still weren't reacquired. I had to actually launch the game via Steam, and click "Play" to invoke download of ALL apparently 74 CC masters. THEN, I had another look at the game Data directory and verified the timestamps of the now 74 CC masters. LOOT tells me that only 28 of them have ITM/UDR, so either LOOT data has changed, or the vanilla masters have changed in the last 48 hours. Spot checking the Created dates of some of those original 39 I had and had not updated in Data showed that the game's "Download" process reacquired those I had deleted and only 'touched' those I had not (all 74 modified dates were 'Today', but only the 37 reacquired ones had Created dates in the past). ... so I think we either need to simplify our instructions or add some additional ones explaining the additional steps and possible caveats.

Try switching to DynDOLOD DLL NG with the large ref workarounds if you are not already using it. All plugins that have them will need to be cleaned of UDRs for NG to function though. (About 40 vanilla plugins)

I forgot to note that lowest possible Ambient + higher Direct values with TexGen works best when using grass normals in LOD (CG/CS), but if using standard grass without normals, then higher Ambient and slightly lower Direct seems to work best.

This may not be relevant to TexGen and better suited for the xLODGen topic. See DoubleYou's response.

Did you disable the (TEMP) - Cathedral Landscapes - xLODGen before running TexGen/DynDOLOD as the guide instructs?

It sounds like his is an issue with FO4 LODGen using sheson's tools. Please post on the xLODGen topic for support, and let us know if the FO4 guide instructions conflict with any resolution you find.

In the Step SSE guide, we provide suggested settings that work well for Cathedral Weathers and Cathedral Landscapes with or without complex grass/ENB. We set the RGB values to a a uniform, moderate value to avoid tint bias and use TexGen direct/ambient to set a good exposure for grass LOD. TexGen ettings vary, depending upon weather and grass used, but the principle should work similarly. The idea is to reduce Ambient to the lowest value possible and increase Direct exposure whilst keeping RBG flat and unbiased (be sure to expand the Modify Grass Tint/Brightness spoiler).

Post moved from the MO support forum to the mod in question.

The SkyrimLE guide has been retired and is no longer officially supported, because none of our staff run LE these days. Use the SkyrimSE guide, which describes all the details needed ... but it's also outdated with the current Bethesda game and available mods made for the latest game version. We will not update the SE guide entirely until mod authors have updated the mods we plan on using in the next guide update. We want to give the modding community time to catch up with the latest Bethesda-update disruptions. Realistically, this may not be until sometime in Spring 2024 the way things seem to be going. Until then, post in the official SkyrimSE guide feedback forum if something isn't working. It's expected that you read and follow all of the guide instructions before seeking support.

Look at the images I posted. Also see the System Setup Guide. All of this exists in the Step SyrimSE 2.2.0 guide. Use the Tools Setup instructions and the table for reference (as in the second image I posted).

I've taken us off topic here, but thanks for the knowledge dump ... some of it actually makes sense to me

I agree with everything you are saying here. My epiphany was more to do with cause and effect. The effect I'm speaking to is degraded ability to retain information as I age (most notably somewhere in my early 50s ... I'm right behind you at 55, BTW). I'm proposing that one of the fundamental causes is lack of energy to 'focus' for long enough to gain and solidify comprehension. It's a bit of chicken/egg, since it's all intertwined, but I'm sure that my "engagement capacity" would benefit from an energy boost sufficient to get me past dozing off within a few minutes of encountering something new to comprehend ... just long enough to reinforce the new information by actually applying it ... it's just become noticeably different within the past several years for me. Of course, there's also historic knowledge acquired over past decades that likely acts as a catalyst if it aligns well with the new information. Responsibilities (or awareness of them) also piles up as I age, so this obviously contributes to mental clutter and a tendency to shut down. Time is consistent, but my perception of its passing is definitely accelerated the more I have under my belt. Exercise and naps are definitively increasingly requirements for me too. Unfortunately, both increasingly cut into my time to gain understanding. Gosh, I'm getting drowsy now just thinking about it

Taken from DynDOLOD FAQ: This last point is commonly the issue in my XP. I run AMD and routinely kill all AMD background processes while generating LOD or creating the grass cache. If I don't, then grass caching and specific DynDOLOD Alpha version run times dramatically increase for me. Not all DynDOLOD alphas of the past have had the issues on my system, so I just disable all of my GFX driver software now every time, which totally resolves the issue. Search this topic, and you will find many more posts and specifics on slow gen times.