z929669

test again

test

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.

I assume those are not LOD trees, since they only appear in the foreground. It's most likely a combination of the textures and the normal faces of those areas of the mesh. You can try changing the branch textures you are using with that mod.

If you are using Step, you already have the mod needed. You just need to configure it to your liking. We don't offer suggestions: Skyrim Skill Uncapper for SE and AE

Cool. let us know what you find. I'll also be testing ERM with several different texture replacers to see what works best. All that matters is that the texture resolutions are standard units 1x1 or 1x2, etc. so that the UVs map correctly. Any textures with lots of striations may be inconsistent on any rock/mountain mesh, but I'm curious if the ERM UVs serendipitously are more consistent in this respect.

Yes, this would replace MM. This mod is highly compatible as a vanilla replacer, but MM makes changes to landscape and other vanilla stuff. Evidently, MM uses double pass on the snow shader to support parallax, but ERM uses single pass, which I'm told is more compatible, performance friendly, and generally looks as good or better in most situations. This is part of why MM requires patching where ERM doesn't. ERM also has it's own LOD, whereas MM relies on vanilla for most LOD (which then use the MM textures). In fact, ERM LOD can be used for just about any mountain mod as a LOD upgrade as long as the mountain mod's texture paths are vanilla. ERM LOD can technically be used without ERM to upgrade vanilla LOD. MM also has lots of conflicting striation patterns in the texture UVs (i.e., one boulder will have horizontal striations and another one nearby may have vertical). This happens more/less with vanilla and other mods, but it's worse with MM. Compatibility is one of the things that makes ERM attrractive. EDIT: ERM will also complement (or be complemented by) RWT.

From reading the long list of CTD issues on the Nexus Bug Report for this mod, it does seem that this is an issue with NPCs ... particularly when other mods are adding or changing 'races' (including non-anthropoid). This approach would be confirmation to a good degree. A more robust approach would be to blacklist all non-anthropoid races, but the MA should also implement a whitelist to simplify for end users with tons of NPC mods. These two toggles are essentially broad blacklist/whitelist categories, and 'NPCs' should at least be broken into two other groups: animals and hominids (vanilla character races). For Step, blacklisting should be relatively simple, but I'd rather the MA handled things for vanilla (resolving probably all issues WRT Step build)

I was going to suggest looking at landscape edits as well. So LaWF author may not address unless vanilla also has issues here. Can you pinpoint this location on the map? I'll check it out in our setup.

Thanks for those insights. This helps to clarify.

I think ERM is way better in most of those shots, particularly the map. The rock shapes are also better. You can test with different textures. I used the optional textures in those shots, but you could try vanilla. I've always like the vanilla rock textures as long as the UV isn't messed up. Also, two things this mod does that I like: blends the stark edges where rocks meet the ground texture makes many of the sprawling flat 2D rocks 3D I also told Sparrow that more sharp edges and cracks would be good.

Oh yeah. I forgot about that. I always thought of that one as a performance-enhancing mod, but it's nice for thwarting "rock grass" too.

see Greg's post^

The game can be buggy. Starting a new game can also possibly resolve.

Revisit Unequip Quiver install instructions and make certain you are using the correct version. Also pay attention to the note about Scrambled Bugs, and see the MCM instructions toward the end of the guide. This is all assuming that you followed the guide exactly and have not installed any additional mods or skipped required mods. We don't support deviations like these.

Yes, it should be native resolution. I'll correct that.

Revisit this step of the guide. You are only smoke testing and not actually loading the game for play at this point. You are only testing that the you can load the game and COC to Riverwood. Nothing more.