z929669

No, but depending on if it's LOD or not in your screenshots, it could be a DynDOLOD problem (or less likely, an xLODGen problem). In that case, it's best to troubleshoot with sheson on the DynDOLOD support forum. Use tll in the console to toggle LOD and determine what is LOD.

We don't run LE since SSE was released, so our LE guide has been retired and is no longer maintained. That said, I suggest replacing MM Darkside with MM Lightside to see if this resolves your issue. It could also be LOD issues if you run xLODGen and DynDOLOD.

See my previous comment: We just haven't gotten around to implementing the margin. I have fixed the first couple of spoilers to demonstrate how it works. I never really worked on this, due to the game having been updated several times since 1.5.97, and the work required to maintain this as a result of each update.

Actually, I forgot that I had updated the guide to current standards after releasing the latest Step SkyrimSE guide, which uses the latest methods. I've now also corrected this.

Are you testing using the same playthrough/savegame each time you change the mod list/LO? If so, it's possibly an issue with your save. If not, then you likely have a DLL or runtime mod in your game folder (or virtual game folder) that you missed removing when changing your mods.

From my own perspective, there's no telling how Wunduniik IV is supposed to be installed. My guess is that it's the location of the MO instance/profile/mods directory. In that case, there is no EXE to configure for that. You must create a MO instance based upon it. Your DynDOLOD EXE setup obviously works, or else you would not get far enough to achieve a DynDOLOD error in the first place. I cannot speak to how Wabbajack is used. Here, we provide the instructions and resources to manually create a working mod build. I recommend going that route, as automated installations are not possible to troubleshoot until you understand how it all works. That's precisely why this site and guide exists. DynDOLOD is just another layer atop that.

Read the first few posts of this topic, as the typical solutions are there. Since you are installing some pre-defined mod list using Wabbajack or some other pre-defined configuration, it's most likely that your file paths do not match that of the creator's. DynDOLOD, TexGen, etc. are usually launched via the mod manager (or directly) by invoking a path to the executables with command-line switches. See this instruction we use for MO. We don't know what mod manager you are using or how you are running the application(s), but you probably need to edit the path(s) to use your actual drive letter and folders. Use double quotes around your paths, because you have spaces in both of those paths. spaces are usually interpreted as line breaks, so double quotes prevent that.

You don't need to worry about this. If you are not making CG-compatible grasses, then ENB users should know this and NOT enable CG in their ENB preset. I suggest your design your grass for non-ENB users. ENB can be tuned to make it look good, but most ENB users will want CG anyway. If enabled, CG has 'basic'/'fake' settings for non-CG grass, so that's probably what you are seeing in your screens.

The Data tab shows the files and the mod providing each file. If the mod name is red, it means it is overriding the same script from some other mod: If you hover over the file, MO confirms which mod provides it (winner) and which other mods provide it (losers). Simply right click the script, and select 'Hide' from the context menu to allow the other mod with highest priority to provide it instead. You can do similar things by double clicking the mod of interest and selecting the Conflicts tab.

My first suggestion is to use BethINI to ensure you have the correct INI settings for distant LOD with Ultra trees. Try the Ultra preset. This will ensure your view distance settings are correct in addition to other settings affecting visuals. Then test using your ultra trees DynDOLOD output. If this doesn't resolve your issue, post with logs on the DynDOLOD support forum to troubleshoot.

I'm still not sure you are seeing what I mean. Save like this: If this is what you already did and this is a DynDOLOD issue, apologies. I've worked with these exact textures using NVIDIA TT with 'good' results in LOD and full trees. In fact, HLT has the recolored textures I modified (if you are using any of the alternate snow textures in the FOMOD).

You are ticking Cutout Alpha and NOT Scale Alpha in this screenshot. And do upload the logs as requested please. They allow proof of any issues beyond what we're discussing. In this case, you are likely using HLT, and the original models/textures do work properly. PS: the NVIDIA TT interface is different, because you have CUDA support and I'm on AMD, so I do not, but the main functions of relevance are the same.

No, don't use cutout alpha. I figured you were using it. Try replicating all the settings I posted. Iteratively subtract 16 from the threshold and retest if trees are too skinny.

PineAtlas.dds obviously works properly until you resave it, so you are either changing the alpha or saving it incorrectly. Are you ticking Cutout Alpha when resaving?

Generally, these are the settings you should use for most diffuse DDS textures when resaving (when the alpha is 'correct' and as the mod author intended). Note that for foliage in particular, you need to scale the alpha for mipmap coverage. DynDOLOD should already do this automatically unless 'usemipmaps' is in the NIF branch shape name. In that case, the original mipmaps of the texture are used. Again, this shape string should be used only when the texture mipmap alpha is scaled correctly, which sometimes isn't the case, which is why DonDOLOD does it by default. By matching the threshold to the NIF NiAlphaProperty, you are probably capturing the (black) background in your mipmaps. Scale using 127 or 128 as a starting point always. Then test the result and add/subtract 16 to fine tune.

It's almost certainly related to missing textures or snow decals, but if you want to verify it's not ENB, just toggle ENB off/on using Shift+F12. If this doesn't fix it, then it's not related to ENB. It could be related to parallax, in which case you should be running Auto Parallax. We don't use parallax in Step, so I cannot provide any relevant guidance beyond this. To test if it's LOD or full textures, use 'tll' in the console to toggle LOD. Use BethINI to configure your game INIs. Take a screenshot using Game Bar or Skyrim/Steam

If you follow the guide and have all of the correct plugin versions installed as instructed --no more and no fewer-- LOOT will always sort them in an order consistent with the overall result (resulting winning records) being identical to anyone with the same list of plugins. The actual order of each plugin can vary whilst still providing an identical winning-conflict result. This is because most records have no conflicts. The sort order depends on only certain key plugins in relation to others with which they conflict. Granted, it's easy to make one or two mistakes when following hundreds of different instructions, but there's really no easy method of verifying the final result other than validating that each plugin in your LO matches the expected list of plugins. I think some mods have > 1 plugin of identical name but with slightly different records, depending upon the options chosen during installation, so a list of plugin names possibly wouldn't necessarily guarantee an identical result either. This should not be the case, but I'll wager it happens. It certainly happens among different versions of the same mod (plugin name identical with variation among records). That said, such variation is similar with respect to mod assets (files that are not plugins). All you can do is follow each instruction carefully. That said, there's always the possibility that the guide itself has an overlooked mistake amongst those hundreds of instructions. Mods are always getting updated, and the final target is itself dynamic. One quick, albeit imprecise, method is to compare the contents of your plugins.txt file with a reference plugins.txt (and loadorder.txt, modlist.txt, archives.txt) in the MO profile folder. This would be painstaking though, since the files will almost certainly be different. We don't provide those for these reasons.

I'm not sure, but EVLaS provides shadows when sunlight (or sky lighting) is occluded by double-sided meshes. You can see this under some of the dirt cliffs in your first screenshot. The darker grass could be shadows caused by whatever sky/fog mesh you are using (shadows on the terrain but not the LOD grass). Sheson may know if my hypothesis is inaccurate/impossible (I'd like know either way).

Thanks. We must've forgotten these, as they were last-minute additions after adopting Moon & Star. Added to changelog.

DNF is a mod with a plugin and a bunch of pregenerated traditional LOD (BTT files). You are probably also using the meshes/terrain, textures/terrain, and billboard atlas files that come with it. If you want to use this file, ONLY use the plugin as mentioned on the mod and file Descriptions if you are using DynDOLOD. You must also use a vanilla tree replacer of your choice, like SFO, EVT, RAT, HLT, etc. Aspens Ablaze might work too. Then you must also use any DynDOLOD add-ons those tree mods require. Just make both plugins active, sort with LOOT, and run TexGen/DynDOLOD.

Nice work!

If you are following the Step Guide, you will not get any "Textures Do Not Match" warnings in the DynDOLOD summary, so your issue is related to your mod list prioritization and/or LO prioritization or mods you have installed that are not in the guide. To discover your issues in this case, it's better to post on DynDOLOD support with your logs, since there's no evidence that it's related to this mod.

If you look at the bottom of the log you posted, it tells you that you have no TexGen output. First generate data using TexGen, and place that output into a new mod (and enable it) so that it's available for DynDOLOD to use. TexGen is packaged with DynDOLOD, and you run it first.

First, as the OP states, any posts here require the relevant log files. It's not clear from your images where LOD grass begins. Use tll in the console as a reference (and the very first image) in image sets like this. This toggles LOD off/on. If you are referring to the dark-ish grass in the mid distance of the first image, this appears to be full grass, IMO. The LOD grass matches further back. I would guess it to be a cloud shadow (or some other shadow effect). You can test it by toggling cloud shadows in ENB or by changing similar settings in the ENB GUI.

Then there's something else in your build that deviates from the Step build other than TCIY, which has no impact on NPC appearance.