z929669

As has been said many times, please provide logs and information about what version of DynDOLOD you are running. Then post in the proper topic for that version. Recommended: DynDOLOD 3 Alpha 122 (if you are not running the latest Alpha, then update and regenerate. Post those logs in that topic if you have this issue.) Not recommended: DynDOLOD Beta 2.98

The mod in question is HLT with the 'Quality' version of the Add-On, I believe. reachtree0*.nif, not sure which one(s) It is possible that textures used by the model may not be as expected from HLT, but they would be also used by the full model.

What game version/variant/localization? Using Steam? If it's a standard, legal copy of the game and installed according to standards, then launching from Steam adds/updates the registry keys. You do this from straight vanilla. No mod manager or modding apps running.

Yeah, the crowns are identical. I'm sure it's optimization of the mipmapping and possibly also the NiAlphaProperty. Reach trees are a ***** with the fat trunks and teeny, broom-like branches (or little groups of leaves on fat branches).

Use DynDOLOD 3 Alpha? The 'old' beta version doesn't have many of the LOD texture autogeneration features packaged with the alpha.

This is pretty much what I was saying on Nexus. Reach trees are notoriously difficult to get to behave with respect to mipmap alpha threshold and/or the mesh NiAlphaproperty. In either case, it's something that would need to be fixed in HLT, but T4 isn't going to bother with it, since the full trees look fine. Fixing this would require messing with the texture alpha and possibly the mesh of the LOD model crown and regenerating that LOD with each change to check it's fixed. Either way, any changes would need to be checked in the full model to be sure it still looks right. THEN those changes would need to be made in the HLT mod itself AND the LOD tree would need to be re-made based on that. A lot of work that either T4 or myself would need to do unless a user provided the fixed files to us to verify ... after verifying the root issue is reproducible in mine and T4's mod builds (which are undoubtedly quite different, BTW) in the first place and not caused or exacerbated by other factors like weather mods, ENB, etc. I mainly wanted you to post here so that you could get suggestions from sheson about how best to investigate and sort it out in your build.

The DLL version you have installed is not correct. Disable Simple Offence Suppression and then in the Data tab in MO right pane, copy/paste ` po3_simpleoffensesuppression.dll ` into the filter at the bottom and see where it's coming from. If you don't find it, re-download and then reinstall that mod according to the instructions. If you still get this error, then you have an issue with mods in 02-Extenders ... then I would ask if your smoke test passed as instructed previously in the guide.

They work well together

OK, I tweaked those instructions again.

Thanks for the detail, but I think you forgot to post your logs as mentioned and as specified in the guidelines at top of this forum and DynDOLOD Alpha OP

Yes, this is correct. Specifically, all you are doing is going through the BethINI config again from scratch, completing all steps, but this time only changing the preset from 'High' (the original baseline) to 'Ultra', 'Medium', or 'Low' according to the FPS as mentioned in Performance Tuning. If this doesn't change your FPS benchmark, I'm very surprised, but it's possible if your FPS are capped still (which should not be the case if Performance Tuning instructions were followed ... "Benchmarking Steps" in spoiler above). I do admit that the statement you call out isn't clear and/or lacks specificity, so I will mull it over and make it clearer.

You could try Wider MCM Menu for SkyUI we run in Step. It has config settings you can adjust for different aspect ratios. Not sure it impacts the map though. I haven't seen this issue specifically, but I'm not as versed in general gameplay as other folks.

Yep, that guide was scrapped, as the info was very outdated and not maintained for nearly 10 years now. The z-fighting principle is fairly well understood now anyway, and almost always relates to duplicate models associated with full/LOD and/or material shaders. Using BethINI will alleviate any game INI sources of the issue, so it's really a matter of your mods and/or LOD transitions for large references. There's no "one-size" to fix it really. It's more of a hunt/kill process if you get my drift.

So you must click after reading the note for the mouse hover effect to work again? Seems like a very minor inconvenience and related to SkyUI inventory not having the focus (focus is still on the note subroutine). That's a problem for the SkyUI team and/or the author for one of the Interface mods we are using in the guide. I don't know offhand which one but maybe Convenient Reading or Better Container Controls. If my understanding of the problem is accurate, I don't think it's enough of an issue to spend time resolving, but if you do delve into that, please let us know what you find.

This sounds like an issue either with ENB or RWT or both in concert. I suspect it's an ENB issue for Boris to examine. I would message both authors and link them to this post for comment.

I would not consider this to be a 'mod' per se but a complete overhaul. It's not something we would consider for a Step build. I would install this in an otherwise vanilla game and add mods carefully according to the documentation provided by this overhaul. It's probably fine to use the latest Step SSE guide through installation of 02-Extenders, but I would stop there and install this mod (The Step build is essentially a "functionally upgraded" version of vanilla at this point in the guide). You also establish a clean and functional modding environment this way.

The test version fixed it. Thank you.

But rather maybe adjust the display in SSE Tweaks accordingly and just disable it to prove it's the cause.

Yes, thanks. Second link in OP corrected.

Did your smoke test pass previously? Are you strictly following the guide without any deviation like adding mods not in the list or skipping others? If the answer is 'yes' to both questions, then you missed an instruction somewhere. Most likely, you downloaded the wrong version of a mod or forgot to hide a plugin or not all installed plugins are enabled. There's too many possibilities to provide anything more specific without more detail.

Hey sheson, I'm hoping you can assist with an issue with constructing hybrids where I'm finding trunk billboards are not positioned correctly with the crowns. Backstory: I'm working with Veydogolt Trees, and this mod is interesting in that it is purely a mesh/texture replacer and relies solely on vanilla (or whatever) plugins for tree definitions (i.e., this mod has no plugin). So the replacement trees are not necessarily like those references being replaced. For example, treepineforest01 might be referencing a completely different custom tree using the model name defined by the vanilla plugin, so object bounds are going to be different between the NIF and the vanilla reference in most/all cases. This is what I think the problem is, but I want to verify with you. Link to assets - I'm providing all source, intermediate, and hybrid output assets for review. This particular tree is not a good candidate for flat trunk, but that's beside the point. I'm using this as an obvious example of the issue. I'm using DynDOLOD 3 Alpha 122. The billboards are not correctly aligned with the crown, and I'm assuming to fix would require a proper plugin be created with Tree overrides and object bounds properly defined. The crown adopts all of the xyz and positioning of the base model, and so does the trunk, but since the flat trunk is taken from the rendered trunk, the hybrid lacks any specific xyz and positioning defined by the 3D trunk. Can you sort me out?

See if you have bugreport.txt in your xLODGen folder, and also post SSELODGen_log.txt

Only if you have G-SYNC of Freesync-enabled hardware and your driversoft settings configured to support that. Explicit Vsync and frame-rate caps should be disabled everywhere that it can be enabled in this case to allow these NVIDIA/AMD features without redundancy or conflict.

Thanks for letting us know. You might want to post this for Sparrow-Cockerel and other users on the ERM Nexus page so that he can speak to the finer points of what's expected with parallax.

It's not clear exactly what files you changed for ENB or where you made the changes. ENB is manually installed in the actual game directory, and the binaries (DLLs) do not need to be changed. Only the preset files/folders need to be swapped (technically, only enbseries.ini is different among the presets). Just swapping this one file in your game directory shouldn't cause this issue. This is a DynDOLOD DLL error and has nothing to do with your ENB. Removing ENB files from the game directory should not fix this error. You have made other changes that we cannot know. It seems like you borked your SKSE or DynDOLOD DLL/Resources installation. Revisit the Extenders guide instructions to make corrections.