z929669

Again, you get that scripts error because you are using OLD LODGen ouput mods from the Step build prior to updating to DynDOLOD DLL NG. You did not generate that LOD output when DynDOLOD DLL NG was active in your mod list.

Exactly. This will set INI values for snow properly for SSE. Most notably, the "improved" snow shader should be disabled among other things.

Nexus does not enable update tracking of archived files. You must check the documentation for updates at present: https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements

First, read the changelog, particularly the top. Follow this advice if you want your savegame to work or to revert back to your previous build. You get the scripts error because your old DynDOLOD outputs are present. LOD will be completely regenerated, so xLODGen, TexGen and DynDOLOD output mods should be cleared of all files. Repeat reloading your save only after the entire guide is finished, including LODGen.

Atlas Map Markers must load last but before the CR patch.

Not since it's an archived version of the file.

OneDrive and the like will only be an issue if you have installed the game and your mod manager in the Windows UAC-controlled path(s) ... because I assume oneDrive in particular syncs those paths. You would benefit by following our guides (FO4 guide in production now), starting with the System Setup Guide, which applies to FO4 or any Bethesda games. This establishes a modding environment that is void of such issues. This basically means moving Steam and changing your mod-manager paths, so it's really not fun. However, your issues are likely MUCH more not fun, and reconfiguring will spare you all the pain you have been suffering through. PS: certain other defaults for these games point to %USERPROFILE% path, which is also likely synced by OneDrive, so you should be able to exclude those folders from your OneDrive sync in it's configuration. I like OneDrive on my work PC, but I have entirely scrubbed it from my Win 11 personal PC (Google disabling OneDrive in Win 11 if you want to do that)

Good find. This is a problem only discovered by the immersive player and is inevitably missed in cursory testing. Furthermore, said immersive player must perceive the inconsistency and investigate above and beyond that which most people would ever do. Such reports are a great benefit to us all Now, I'm assuming that this is true of ALL of those "NPCHorse*" editor IDs, even where ISC isn't involved so that all horse steps from any mod are impacted by the slider. You mention this, but I just want to be sure this is what you mean, so:

Yes, this makes sense. You should always delete all LODGen outputs and regenerate when the mod list changes as explained in the guide.

These statements make no sense to me. This will generate DynDOLOD plugins and data files with the version 3.0 instead of version 2.45 v3.0 vs 2.45 of what exactly?? DynDOLOD DLL version?? Where would this be indicated. how is it relevant to anyone? No context is provided. no data files for PapyrusUtil are generated and it is not possible to switch Not possible to switch what exactly?? I can switch anything I want, including DynDOLOD versions and DynDOLOD DLL versions. No context is provided. Use NG version and report anomalies to sheson on the DynDOLOD 3 topic (just as I think you have been doing). This is how it gets fixed and DynDOLOD 3 moves from alpha to beta. Step will always use the cutting edge release of DynDOLOD solutions for this reason. Progress > stagnation

Reading the changelog is not presented as 'optional'. It is prominently linked multiple times at the top of the guide and on the Nexus mod page

Honestly, it shouldn't make any difference at all. DynDOLOD has been in alpha for years now, and it hasn't posed any predictable savegame issues that I can think of. This is just another feature that benefits. Any change to plugins relating to a savegame can theoretically cause problems, but most do not. This is why we address it in the changelog introduction and how to avoid the issue if it's a concern. Technically, it's never a good idea to change a mod build during a playthrough that you really care about finishing. This is why MO has profiles and instances.

You should report these issues in the DynDOLOD alpha topic, posting all logs as indicated in the OP. If you are using Step, you are using the experimental Large Reference Fixes option, so reporting quirks to sheson with logs helps everyone.

Indeed. Mod list patches are too volatile to warrant reporting to LOOT.

Yes, this is why it's not indicated for selection. We want to avoid calling out what not to do and why in instructions. Else we would have a mountain of redundant instructions.

Staff don't get likes or kudos, but your can give one to Mistermodern, since he pointed to the NG download too

This is the NG version that is harder to find. We keep the link updated here until sheson makes this a standard part of DynDOLOD Alpha. Install priority you should use is in the guide mod list

The best way to fix AE issues if you are following our 2.2.0 guide is .... re-visit the 2.2.0 guide. If something isn't working correctly, you either did not strictly follow the guide, you missed or misinterpreted some instructions, or you added mods unsupported by the guide. All answers to fixing your issues are in the guide. In your case, you installed the wrong version of one of the 02-Extenders and 03-Resources mods ... probably Address Lib, but something in the SKSE stack.

The LR workaround is available now via DynDOLOD DLL NG. We use this in the Step guide, and it works nicely. You should be running uGrids = 5 and no higher. Otherwise, you get all kinds of glitching caused by scripts and other strange things due to too many cell references loaded at once. We advise to set to default 5 with NearGridToLoad at 11 (Default BethINI settings and DynDOLOD expectation). Using the DynDOLOD DLL NG with DynDOLOD 3 Alpha resolves most LOD flickering. When you TFC to LOD, it really isn't 'fair' to LOD. Most of the stuff from your screen is not visible in LOD and could actually be a result of using high uGrids. To use DynDOLOD DLL NG, you must clean all of your dirty plugins using xEditQuickAutoClean (QAC) for the checkbox to work in DynDOLOD. You can use LOOT to identify all dirty plugins. It takes about 30 minutes to clean all of the AE/AU CC plugins and other vanilla plugins. These are our DynDOLOD Alpha instructions, and you may want to try our BethINI settings too, which may resolve all of your issues with DynDOLOD.

This looks like visual glitching of materials or possibly as a result of bad loading in the cell. Regardless, you will need to provide more information. What makes you think this is LOD? Is this a screenshot of loaded objects or LOD objects? Did you COC/COW/TFC via the console before seeing this? Did you test on a new game? Did you use DynDOLOD?

These instruction sets are NOT identical, and the headings for each clearly delineate their application with/wo CG. Neither of these 'enable' CG, and I'm fairly certain that it is not implied anywhere that they do. TexGen detects CG based on the textures themselves. The second set from the grass LOD guide have incorrect CG settings, since they are all for 'red'. This will be corrected if it hasn't been already Also, please don't Google how to do things relating to the Step guides. You should ask questions here.

That mod has no influence on your issue. It's only a vanilla mesh replacer with no plugin, so your problem was related to something else. Maybe you hadn't sorted plugins with LOOT or some other small thing like that.

Changed tag to 1.0 to align with the new versioning.

I have updated those instructions and added the PP flag to that mod again for 2.2.0 All of the patches are ESL but for the main ones. Unless you are at your plugin limit and installing a bunch of mods on top of our 2.2.0 SSE mod list, you shouldn't need to do this. We don't do it for the CR patch to reduce incompatibility issues when the guide is updated, but it should be fine to do so for yourself.