z929669

I took a look at this in xEdit, and it will need to be resolved using the CK. @TechAngel85 will be needed to assist or train the rest of us on tackling landscape/navmesh patching for VLC using the CK.

For now, we'll stick with v1.2.1, since we'd need to update our patches otherwise. Once we are in a position to either do that or update our guide to the next iteration, we'll probably opt for the latest plugin version of your mod, since we do the patching ourselves anyway. Thanks again!

Hey, no worries, and apologies if my post came off a bit harsh or misinformed. I was indeed going by a spot check in xEdit and awaiting someone to straighten me out if I'd misinterpreted anything. Your explanations are helpful, so thanks for jumping in here. I'll have another look in a day or two and go from there. We'll obviously still be recommending some version of your mod, regardless. Thank you for all that you do! PS: And I feel your pain with the Nexus-update-lag issue

It's a strange update. We don't want the SkyPatcher version, as that adds an unnecessary layer of complexity for guide users. The 'plugin' version is exactly the same as 1.2.1 but for the weirdly-added "No LOD Water" flag in a small handfull of new records touching Gerdur's house, Angas' Mill: Huh? This makes me wonder why this mod is messing with these types of edits. Seems like scope creep to me. Here's an 'oops' that seems to undo the USSEP change: This is the only relevant update (but only if the USSEP got it 'wrong'): Also, I don't get the mention the SkyPatcher version intended for SKSE users while the plugin version is not (who is running a mod build without SKSE??). We'll continue recommending v1.2.1, since it comes with the relevant patches for our mod list and doesn't have this small handfull of seemingly wild edits. The new version essentially eliminates the relevant patches and makes no other relevant changes that I can see. I only see a whopping 'five' changes --three of which are seemingly redundant in comparison to v1.2.1, another that steps on the USSEP, and one change that seems to appropriately modify an acoustic space (but this is arguable, since it's another deviation from the USSEP change to the same record). I'm guessing this update was made to obviate patch maintenance for the MA.

'Quality' is exactly as stated for all ENB quality settings. Zero is usually the highest quality AFAIK, but for some it's evidently negative one. I think you might be able to see some reference to this in the ENB GUI.

Read through this topic. We haven't tackled this issue for Step yet, but it will be best solved by using our own custom gradients/meshes. Feel free to use that mod in the meantime though.

No, those values are only for the 'tree' rule: You should match the rule shown for '/' in the DynDOLOD image.

I repeated the tests under a barebones modded vanilla, so vanilla weather and no post processing. The results are basically the same. As with the previous tests, the largest improvement is the revised normals; although, both using the default textures and higher Lighting Effect 1 very slightly raised the LOD crown brightness. I've also included a test with the 'Quality' version of the add-on. The result of that is essentially the same as I showed in my post just before my previous test post. This has an obviously better match with full trees and demonstrates that using the full crowns without optimization yields the best result. The only issue is that these crowns are too complex for LOD. LOD Reference 1_default-2048 2_normals-2048 3_normals-textures 4_normals-textures-effect 5_default-Quality LOGS 1_default-2048 2_normals-2048 3_normals-textures 4_normals-textures-effect 5_default-Quality

I will have another look. Thanks for testing.

You must set Level32=1 in DynDOLOD_SSE.ini and generate dynamic LOD in DynDOLOD to prevent stuck LOD bugs when using ACMoS. Revisit the DynDOLOD mod instructions and the LOD instructions (read and follow all of it carefully). Finalize the build before generating the LOD patch. If the LO and mod list change, you may need to regenerate LOD.

I've completed the tests. I also added two tests to account for the sparse aspen LOD foliage that I discovered was caused by the custom LOD textures having too low resolution at 256px, presumably due to my 4K configuration (2160p). The AA optimized 'Performance' LODs were originally tested under 1080p-1440p resolution and DynDOLOD settings. At the time, we had a good color-tone match between full and LOD. The shape match was satisfactory as well. As mentioned previously, the custom 256px LOD textures were created by extracting the corresponding mipmap from the original textures and saved without mipmaps. All I did for the additional two tests was extract the 2046px mipmaps from the original AA textures, saving again without mipmaps. These are only utilized by the LOD models, hence the different texture paths from the full models. The baseline test is 'default'. It's just AA Autumnal Variety with 'big' trees option + AA Add-On for this flavor without any of your changes. The effect of using the higher-resolution custom LOD textures follow, so that we can examine more apples-to-apples comparison for your tests, given we see the same color tones with the different branch texture resolutions: LOD Reference #1 default #2 default-2048 #3 normals #4 normals-2048 Now to the test compares. I'm using the '2048' variants in the following so that we don't need to 'unsee' the sparse crowns in LOD in the respective compares that use the custom LOD textures (default & normals tests). #2 default-2048 #4 normals-2048 #5 normals-textures #6 normals-textures-effect While there are some subtle differences, the color-tone mismatch remains in all cases. LOGS 1_default 2_default-2048 3_normals 4_normals-2048 5_normals-textures 6_normals-textures-effect @Dayraven PS: I see all the changes you made to the meshes, but how exactly did you change the normals, tangents, and bitangents for each vertex? I couldn't reproduce that in NifSkope using the tools I'm aware of.

I will also run these tests as well and let you know in the next day or two.

It seems like you probably had game-version-compatibility issues with these mods that caused the CTDs.

DynDOLOD Resources mod should always be active in the installed mods (there's no plugin for this one). It is typically installed at lower priority than everything besides the Uofficial Patch (USSEP). Keep in mind that this mod is for DynDOLOD and not xLODGen. But TES5-Terrain-Tamriel mod/plugin should only be active during terrain LOD generation using xLODGen. Then it can be disabled/removed (and the corresponding plugin disabled/removed from the LO). This one has no conflicts, so it really doesn't matter the priority it's installed as long as it's plugin is sorted early as a master (use LOOT for sorting).

Sorry again. I had forgotten to re-expose the LB tool/icon to non-admins when I made the other changes. Please try again.

I actually just finished checking treeaspen01 LOD and full models. The AA add-on mod is the 'Performance' version with optimized crowns that combine the three shapes of the full model crowns. It also uses a smaller 256px branch texture than the full model's 4096px using a unique path name and custom mipmaps. In fact, all of the 'Performance' aspen LOD models (not just treeaspen01 LOD) use this smaller branch texture. The textures match, as can be seen in the following screens comparing freshly-generated LOD patches for the 'Performance' vs 'Quality' versions of the AA add-on (Autumnal). While the mipmaps of the Performance version may need another look, the color tones match (the LOD are a bit darker for both). Remember that the Quality version has LOD models using the exact crowns and texture paths as the full models, since they are direct copies of the crowns/textures and not optimized versions. AA Performance Add-On (256) AA Performance Add-On (NiAP67) AA Performance Add-On (512) AA Performance Add-On (1024) AA Performance Add-On (2048) AA Quality Add-On Performance logs Quality logs Q-P branch textures @Dayraven PS: The textures\mx\autumnal.dds texture has no mipmaps, because we leave it to DynDOLOD to create them during processing. This texture is only used by aspen LOD branches. The LOD branches are a bit too thin though, so either the 256px texture is too small to begin with, or NiAlphaProperty for branches needs to be lower in the LOD models (128 now just like the full models). PSS: Changing NiAlphaProperty of the LOD model branches from 128 to 67 had no impact (see middle screenshot). PSSS: Changing the texture resolution to 512px and 1024px makes a significant difference, so the starting size of 256px is definitely too small for my resolution (2160p). I assume it's because mipmap 0 at 256px is not high enough. NOTE: All variants of textures\mx\autumnal.dds here and in the Add-on were created from corresponding mipmaps of the original extures\mx\birch03_n.dds and saved as BC7 without mipmaps. PSSSS: Finally, changing the resolution to 2048px yields slightly fuller LOD trees at this game distance (It's mid-distance LOD4). I presume that I will see no benefit at 4096px with my 2160p configuration, since this is the recommended texture clamp size at 4K. One additional consideration I hadn't considered until now is that I do set CrownBrightness=0.8 in my DynDOLOD_SSE.ini for better matching of EVT LODs, but that was for my old monitor and GFX card. I'm currently generating two additional compares of Performance and Quality at the default CrownBrightness=1 so that we can determine if there's really any issue that needs to be addressed. ... using default crownbrightness=1 LOD Reference AA-Performance (2048) AA-Quality The Quality version seems like a very close match. The Performance version is a bit darker but also quite close. I attribute the difference to the fact that the optimized LOD models have slightly different geometry and fewer triangles rather than a texture difference. textures

So I think this means that you are choosing "Autumnal Variety" in the Add-on, and "Autumnal" in the main mod. Choose the same type for both.

The new version has made some fundamental changes, so we'll recommend v2.2 until we can verify the latest version 3.1+

Update MO. Ensure your plugins are enabled in the MO right pane, and sort them with LOOT stand-alone. Are you running the latest version of the game? Is that what you were running before you reinstalled your OS? Assuming you are running 1.6.1170 version of the game, my advice is still to follow the SSG and all instructions in the Step guide through 02-Extenders. You may also want to check your SKSE and Papyrus logs.

You've determined that your issue is save-game related, yes. It's probably papyrus related. This save likely would have had the same issues before you rebuilt your OS. You can try save-game fixes like ReSaver, but I can't really provide much guidance beyond that: https://dyndolod.info/Help/Clean-Save

At this point, test with a new game and not from a save. We're taking broad strokes now to verify the source of the problem. 02-Extenders are the baseline mods that are executed at runtime in addition to SKSE and are all related to SKSE. Begin at Step 1, and take special note of reverting the game to vanilla, verifying integrity of game files, and initializing the game. Following the Step guide trough the Extenders group on a clean new instance will give you a foundation from which to investigate further. Once that is done, it's easy to move over the mods and begin testing those individually or by using binary iterations beginning with half of them. Just about any SSE build will work on the Step foundation as long as the correct versions of the runtime mods are installed to match your specific version of the game. Our guide assume 1.6.70 (and with the AU being necessary for many mods installed later the guide).

Yes, wrong move. The mods folder consists of the end result of installing the mods. It is not the source. The downloads folder consists of 7z, rar, and/or zip archives with metadata text files. In order to restore it, you will need to re-download each mod. That is not the reason your game won't load though. That is most likely caused by a missing or invalid runtime mod like SKSE, Engine Fixes, Address Lib, etc. I suggest that you disable all mods in your MO left pane except SKSE and Engine Fixes and try to launch the game via MO. If you still have issues, follow the Step 2.3 guide through 02-Extenders to get everything in working order. That includes the SSG.

See this post for where your old files need to be moved from and where they should be placed. You can copy over the modorganizer.ini file from your root directory as well to get back all of your original MO themes and other defaults. Same goes for the game INIs under Profiles. After moving these files properly, you can reinstall any mod again from MO Downloads, assuming you never deleted them. You will need to reinstall SKSE and SSE Engine Fixes into the game \Data directory.

Revisit BethINI Pie setup to make sure you are rendering grass in 'Environment' tab. If you are using the latest version, then the UI is a little different for this tab than what we have in the guide. It should look like this: Revisit NGIO config settings, and make certain that you generated the grass cache via MO.

You can absolutely stop at Step 6. Just finalize the LO at the end of Step 6, and complete the xLODGen part of Step 7. It will not cost you any FPS and will give you better distant terrain with proper shorelines (but re-enable the TEMP mod first and then disable it after). Skip the remainder of Step 7, and proceed to Step 8 to finalize the LO and MCMs. You can do Step 7 with performance settings, and it won't cost many FPS. Just use Low or Medium preset, and set Billboard 4 at LOD4. Community shaders will work just fine. It's probably best to install most of the post-processing mods if you do. It may cost some FPS but not as much as ENB, I suspect.