z929669

Yes, but why not just use BethINI to do it so your current settings get backed up as normal? Then it also gets applied to the correct INI. EDIT: ... and let us know the values you find if it works.

They were wrong on many of these subforums. I fixed them all and parents where applicable.

The 2.2.0 guide instructs use of DynDOLOD DLL NG and links to the proper file. If you do not want to use the NG version, then that's not supported by the DynDOLOD reference images in the guide, but it will work.

If grass base records do not have object bounds defined in the plugin, then they don't get LOD. This is not an issue for Veydogolt Overhaul or Veydogolt - Green Whiterun Tundra Grass (it's just textures for VO), so the issue is as DY stated: TexGen Direct/Ambient tweaks. The current Step 2.2.0 settings should be very close for VO, but since it doesn't have complex grass, you should be using "Grass" settings shown here as a starting point. I would leave Direct at 100 and test with Ambient = 10|5|25, since Ambient has more impact: Be sure to also set grass tint for non-complex grass same as for CG: You should be testing difference between loaded/LOD in clear weather on the tundra at around noon ToD. Generate DynDOLOD only for Tamriel worldspace and keep Dynamic LOD UNticked for faster generation (just for testing grass lighting). Once that matches well, you can also play around with other settings in DynDOLOD_SSE.ini for grass billboards, and test at dusk/dawn on tundra also in clear weather. Grass LOD does not receive shadows, so these settings help to adjust LOD grass to match loaded when the sun is low in the sky: ; Billboard templates to use for grass LOD done in static object LOD ; alt1 = without backlighting ; alt2 = with backlighting ; alt3 = softlight/backlight using diffuse - for shader development - do not use GrassBillboard1=Internal GrassBillboard2=DynDOLOD_flat_2x2alt1_lod.nif GrassBillboard3=DynDOLOD_flat_2x2alt2_lod.nif GrassBillboard4=DynDOLOD_flat_4x2alt1_lod.nif GrassBillboard5=DynDOLOD_flat_4x2alt2_lod.nif GrassBillboard6=DynDOLOD_flat_4x2alt3_lod.nif ; Billboard template to use for grass LOD billboards created from "normal" grass without normal map textures ; 1 -> Billboard1, 2 -> Billboard2, 3 -> Billboard3 etc. GrassBillboard=1 I would first check using the default GrassBillboard=1. This setting probably ignores backlighting and is default, so if grass matches pretty well at dusk/dawn, nothing more needs to be done. If not, try GrassBillboard=5 with GrassBacklightMask=25|50|75|100 and check disk/dawn matching. For these compares, you can create a save on the tundra and reuse that for each changed DynDOLOD output, since only the textures are changing and DynDOLOD plugins should otherwise be identical (don't change any mods between DynDOLOD runs). Keep in mind that EVLaS will not work properly when reloading the save, so I suggest disabling EVLaS for all testing. Once you have ideal TexGen/DynDOLOD_SSE.ini settings, regenerate DynDOLOD again as normal (with dynamic LOD) for all worldspaces using those settings. This process usually requires at least 3 DynDOLOD test regenerations and could require many more, depending on how fast you find the correct settings.

VO has all grass object bounds, and the INI is what grVulture had prior to my modifications. All I did was edit the plugin to calculate object bounds for all trees and grasses and got rid of all the redundant textures and meshes. Then I created new tree LODs and generated a grass cache. iMinGrassSize should be whatever you like. 52 seems fine. I only see one hidden file: \meshes\architecture\solitude\sbridge01.nif.mohidden I don't recall hiding that one, so I must've missed it. That mod essentially combines many other mods into one with some custom assets grVulture made I think.

It's always best to create your own grass cache if you know how to do it. It's really not too hard, but setting it up without having a 1.5.97 profile is a headache. I thankfully never had to mess with it, because I backed up my complete 1.5.97 game folder just ahead of that breaking 'upgrade'. I just rename my game folders when I want to use it. That area with the red x is just landscape with no grass, so no grass loaded there at all. It looks like you have a landscape-grass mismatch. Maybe VO doesn't have a green tundra, but I recall it was greener than CL when I was working on it. Maybe I'll revisit that mod again to have a closer look. I've been wanting to strip out all but the landscape, grass, and trees anyway. It looks like Veydogolt - Green Whiterun Tundra Grass does account for the landscape/terrain colors, so maybe you need to ensure it overrides VO ... and check the asset conflicts between the two to be sure.

I tend to agree. Not worth supporting all of the ways it could go wrong for some people. We'd need to add special instructions for configuring MO and again broach the BSA extraction subject, which is an additional headache. Too bad, because the consolidated skills UI is super nice. I'll be running it in my personal game for sure. It was surprisingly easy to set up DDDM with all optionals.I went with the font update strictly for the monospaced font in the console. Works great with Font Overhaul too (just let that one mod override). Still working out the overall config, but alas, Extended UI is a bit of a support headache with no simple solution it seems. Tried that as well but I didn't look too deeply. I don't want to turn off these features but rather get back to what a new user might see.

This^ Just unfold each of the menus and scroll down to find them.

I created a vanilla-esque grass cache for that one available for download, so you can give it a try. The plugin also gives all grasses object bounds. It's nice, diverse grass but has a green tundra and no complex grass.

In short, don't change these settings. They are perfect as they are, given game units and other related INI settings. DY has already done all of the testing and validation of these settings (and other settings BethINI changes via preset choices).

Yes, I installed Extended UI using MO. I believe MO threw a warning about the plugin being LE, which led me to investigate and ultimately to find the Extended UI - Settings Loader mod, which resolved that bit. I found the only_alternate_source boolean setting to be quite misleading and unintuitive. I long ago got tired of being prompted to "extract BSA" for every mod that had one, so I checked the "Remember selection" box and clicked [No] waaaay back then to make it stop. I assume this changed my own only_alternate_source boolean to 'false'. If that's correct, I would have named this boolean install_prompt or likewise, because that name is totally misleading and makes me think it's referring to mods installed outside of the API-mediated automation. <-- my assumptions here were incorrect. The boolean hover description: "Only trigger BSA extraction for alternate game sources (default: true)" ... regardless, this plugin's behavior doesn't change for me if I change the boolean or disable the plugin entirely (and restart MO): I still have the Archives tab in right pane, I can still extract BSAs from there, and I still never get the "Extract BSA" prompt dialog under any circumstances related to this plugin or it's settings. This is an LE mod (per the downloaded file metadata). I get the same behavior with LE and SE files under my SSE MO instance. Something's not working correctly. The MO2 team should have left this at 'false' by default, as some users will "Enable archive parsing", which I presume opens up visibility to this default dialog (I haven't verified) After verifying, I found that this 'Workaround' has nothing to do with the BSA Extractor plugin.: Due to the headaches caused by people extracting BSAs and unwittingly subverting expected asset-load behavior of the game, we avoid the subject entirely these days, given that "Enable archive parsing" is disabled in MO2 by default (IIRC) and the potential confusion is circumvented. Furthermore, the default is 'No' as you indicate, which is a good thing in all cases but this particular edge case where the BSA isn't SSE compatible evidently. Unfortunately, the Extended UI mod's Nexus attributes require permission to alter it's assets, so the Extended UI - Settings Loader MA doesn't fix this problem (I presume for that reason). I've reached out to the MA, but I don't expect Mr Jack is active on Nexus for the past several years. To use this one will require a viable workaround, and none of the present options seem convenient. UPDATE: Well, testing that boolean set to 'true' doesn't bring back the Extract BSA prompt for me even after restarting MO, so I have no clue what it does or how to revert that dialog so that it appears for me again. UPDATE2: I was also wrong about "Enable archive parsing" having anything at all to do with BSA Extractor plugin. The former only allows MO to scan BSAs for asset conflict compares ... I guess I should have known. UPDATE3: Disabling the BSA Extractor plugin has no impact for me. I still see the Archives tab in the right pane and still have option to extract BSAs. Now I'm guessing that it's broken or behaving unexpectedly do to my using an instanced MO installation. Maybe @GSDFan knows what's up with MO2 in my case ... see updates and yellow text.

For the record: Posting questions separately is beneficial and encouraged, especially for straight-forward, singular questions like this. They go into a Q&A forum just like this one. Then you as the poster are expected to mark the "best answer", which bubbles that post to the top just beneath your question. This makes it easy for others to find answers to a similar questions both here and from the internet. Normal forum icon: Q&A (support) forum icon: This question ideally would have been posted in the BethINI Support forum.

I misread your question for some reason. Ignore that statement Just run BethINI and look. The settings from your current config are backed up by BethINI, so you can easily restore them. %LOCALAPPDATA%\ModOrganizer\{instanceName}\profiles\{profileName}\BethINI Cache\YYYY DDD MMM DD - HH.MM.SS

There's no way to only impact trees from a given mod using the global game INI settings. FYI: I run BethINI on Ultra rather than High. It's definitely better for visuals if you have a powerful rig (which I do, see sig), but it comes at the price of the game being unplayable in certain conditions. I just don't care, since I don't play much aside from situational testing. Because I run at QDR resolution (2560x1440), even my system averages only about 40-50 FPS with Step SSE ... in some areas, I max at maybe like 20-30 FPS. I'm not upgrading my GPU to a higher tier until prices are way down from current. I just can justify spending $900+ as a matter of principle.

I moved this post the the Q&A SSE subforum so that @Mousetick's post doesn't go to waste (I selected it as the 'best' answer). We normally don't advise people to this level, since most people won't bother going to the trouble implementing (or creating the post), and it's pretty technical to tweak at this level. But if the work is put in writing it up, then it should be more visible, IMO.

So you didn't change DynDOLOD at all but only these INI settings to fix it? As DY mentioned, Using BethINI ensures the settings are (with Ultra settings): [Display] fMeshLODLevel1FadeTreeDistance=12288 fMeshLODLevel2FadeTreeDistance=16384 fTreesMidLODSwitchDist=16384 [Trees] uiMaxSkinnedTreesToRender=200 These settings should be proportionate when using BNethINI High/Medium/Low settings. The only reason a lower setting for uiMaxSkinnedTreesToRender might cause the strange trunk/leaves pop-in is if you are at the max draw calls your hardware can handle, and a lower value throttles this to a range you can handle with your setup. Remember that Veydogolt Trees are relatively demanding with many more triangles (and draw calls) than most other tree mods. With your fully-modded setup, your draw calls are probably quite high with DynDOLOD, so even a really powerful system can be brought to its knees. We resolve a lot of this with our Performance Tuning advice in the Step SSE guide. You should try following that advice maybe (in terms of ENB and DynDOLOD) EDIT: DY ... he makes a good point that most points on the map don't include 120+ trees, but it really depends on your uGridsToLoad setting, which should be 5. If you are higher than that, the loaded area will definitely exceed 120 trees, especially if you are also running Veydogolt - Extra Trees. Even at uGids=5 you can exceed this in Falkreath and several other other areas. Another possibility is the game itself being a bit buggy. Sometimes a PC restart and reload of an area or relaunch of the game can fix these things (due to hardware/software stuff)

I think we already have the best texture replacers for weapons and armor ... and clothing, etc.

Reverted back to testing, since Dear Diary (also in testing) renders this redundant if we go with that mod.

Discussion topic: Extended UI - Settings Loader by MaskedRPGFan Wiki Link Testing Currently under testing due to: Installation Install the Main File Merge the update from Optional Files Companion mod to Extended UI that solves two of three problems with that mod, due to it being an LE mod: Adds MCM Helper support Updates the Extended UI plugin to be compatible with AE This mod does not solve the BSA incompatibility issue of Extended UI.

Updated wiki

Just change the ENB hotkey in enblocal.ini and use that then.

Fixed, thanks

Is rain scripted? Not sure, but I doubt it is by default. With WoW, it is for the splashes and other effects. That said, Step SSE is light weight with respect to scripts, so I doubt it has anything to do with script lag.

Yeah, I get it and see the value of ESM for anything at all touching landscapes or objects inherent to landscapes (like mountains/ice/glaciers but not so much plants/trees or most various other objects I'd speculate). Prioritizing later is usually not wanted. However, we traditionally solved this via LOOT masterlist submissions.

That's a good point I hadn't considered. Simplifying to a single texture does make good sense, since textures bloat files more than other assets.