Jump to content

LF111

Citizen
 View Profile  See their activity

  • Posts

    45

  • Joined

  • Last visited

  • Days Won

    2

Everything posted by LF111

  1. LF111
    Man I am SO sorry for dragging this on, setting the envLODfadestart/end settings in the custom ini instead of through console commands fixed the problem for me on the vanilla wheel. I should've tried doing it that way earlier. Between that and the new LODGen executable fixing the water reflection bug, all of my issues have been solved. Thank you for going back-and-forth for days on this.
  2. LF111
    Yes. It still fades out at further distances (about the point shown in the bottom pic), but it's probably not going to be noticeable when actually playing the game and not just testing (and as we've discovered, adjusting the envlodfade settings for some reason aren't doing anything for me). In any case, it's vastly preferable to the current situation, so whatever you did to the test.esp wheel is good enough for me.
  3. LF111
    Apologies, but what then is there for me to do to "fix" the problem (or at least get the wheel to match the properties of the one in test.esp)? (also, you probably don't need these, but here's proof that I actually am making these tweaks). Modify/create a rule during LOD generation? Or is this just some weird thing that I have to accept?
  4. LF111
    Setting all of the LightingShader settings to 20.00 with setini (and then verifying with getini) one-by-one until all were at 20 did not result in any change from the pictures in my last reply; the wheel still returns to the "dry" state at the same distance (though, again, it's much better than it was before).
  5. LF111
    I was testing the ini settings in-game with getini and setini, so they were making it in. The new water wheel created by the test esp shows up as wet much further out, see here. It still fades into the "dry" look at further distances, but it is significantly less noticeable. If you were in-game and actually running through Anga's Mill, you probably wouldn't notice the fade at all.
  6. LF111
    Played around adjusting all of the LightingShader settings, nothing worked. I was just curious as to what could've changed such that I could run Alpha 180 with the original LODGen executable on RWT 5.6 and get no issues whatsoever but running it on 5.7.1 - with no change in load order - gives me an issue.
  7. LF111
    I've uploaded some more thorough pictures here showing what the watermills look like at different distances with DynDOLOD on/off and CS shaders on/off. The only mod I have that affects the wetness effect is the Wetness Effects mod for CS. Interestingly enough, that's not what's causing the glossy effect, but it's rather the "lighting" shader in CS. As shown in the pictures, however, even with all CS shaders off, the DynDOLOD output being enabled causes the water wheel texture to change based on player distance. Up close, it's a lighter color. It appears that the darker/non-wet wheel is being activated by DynDOLOD and doesn't shift to the lighter/wet/correct wheel until I'm very close to it, whereas when the LOD output is disabled, the lighter/wet/correct wheel always appears. Skyland AIO is changing the textures for WoodWalkway01.dds. Neither adjusting the particle setting nor disabling CS shaders fixed the issue. I assume I'll have to forward the new executable to future versions of DynDOLOD as well, presuming RWT doesn't get an update that miraculously fixes the issue? I am really curious as to what's really at the root of this with RWT, because they haven't been able to find anything yet. Since I'm assuming the new LODGen executable is specifically to work around whatever weird issue I'm having, it means that there isn't an actual problem with DynDOLOD.
  8. LF111
    Tweaking [LightingShader] in the .ini did not work, and as far as I can tell, SMIM is the only mod touching that .nif Major edit: the water wheel bug persists regardless of whether or not bReflectSky is enabled; only disabling the DynDOLOD output fixes it. I misstated earlier that disabling ReflectSky fixed the issue. I checked whether testSky_e.dds was at fault, but Dynamic Cubemaps is the only mod I have that touches that and disabling it did not fix the problem. Also, just out of curiosity, what changed between the LODGenx64Win executables? I know I might not be versed well in all of this, but I'm curious what you found in the file I submitted.
  9. LF111
    That worked! I don't know what you tweaked, but the water LOD problem is gone, although the watermill problem remains. Here are some pictures showing what the console is telling me; turning DynDOLOD on swaps the model being used for the watermill and causes it to flicker between wet and dry based on viewing distance. The problem disappears when turning DynDOLOD off. The LOD model appears to always be loaded in. Is this another situation where I have to go through and start disabling specific mesh files until I get the problem to disappear, or is there enough information for you to have an idea of what is wrong?
  10. LF111
    I've identified three problem files causing the bug in the Tamriel BTO files: Tamriel.4.8.-8.bto Tamriel.4.-24.-12.bto Tamriel.4.8.-4.bto MB file size limit is preventing me from attaching the other two; let me know if they need to be attached at all or if it's enough to just name them. There's at least one more, but I am tired to the point of delirium right now and will find it later today. Tamriel.4.8.-8.bto
  11. LF111
    Here's what pops up for 00009BB5. I'm extremely unfamiliar with how to actually use xEdit, but obviously something's wrong from all the red. Hiding all of the Tamriel BTO files worked, so I'm working on narrowing it down right now. I suspect the problem is whatever xEdit's showing me, however. Although on second glance it seems to look the same as z92's from earlier.
  12. LF111
    All I know is that the watermill bug, as with the main bug I've been describing, goes away when I disable my DynDOLOD output (or disable bReflectSky), regardless of CS setup. I got a reply from one of the RWT guys and am testing regenerating LOD on a 5.7.1 version that has the DefaultWater.dds from 5.6, as that is what they wanted me to test after reading about the mod/plugin quirk. Hopefully (maybe) that works. I'll look around in xEdit if that fails.
  13. LF111
    Confirmation it's the bReflectSky bug: the Riverwood watermill (pics). AFAIK, this visual error is caused specifically by the sky reflection bug. So, to recap, running DynDOLOD on 5.7.1 causes the bug to act up (even though Sky Reflection Fix is supposed to fix it and has for me in the past) but only when the actual "DynDOLOD_Output" mod is enabled; disabling all three plugins but not the mod does not fix the issue, only disabling the mod or setting bReflectSky to 0 (which I shouldn't have to do with SRF) fixes it.
  14. LF111
    It appears to effect the distant edge of loaded water and not just LOD water, pics. Edit: Okay, maybe it is just LOD water (pics)
  15. LF111
    Grabbed some more pictures showing the problem from different angles here. Might be helpful in determining whether or not this is specifically the bReflectSky bug (though I'm fairly certain it is).
  16. LF111
    Interesting, although it is worth noting that the bug does go away if disabling bReflectSky. I'm using Azurite Weathers and Seasons (specifically Azurite Weathers II) with Community Shaders. Nothing changed about either of those when moving from RWT 5.6 to 5.7.1. And the bug only occurs when running DynDOLOD on 5.7.1; I did a test run on 5.6 (no other load order changes) and the bug didn't surface, so if it's a weather mod issue then there's some really funky interaction going on.
  17. LF111
    Man, now I'm even more confused. I've also done some more testing with enabling/disabling stuff, and I legit can't explain what's happening right now: if I leave the "DynDOLOD_Output" mod enabled in Vortex but disable the dyndolod esm, dyndolod esp, and occlusion esp plugins, the bug remains; the bug only goes away if I disable the mod. How is this any different from disabling the three plugins individually? Sorry if that's a stupid question.
  18. LF111
    Apologies if I'm misunderstanding your reply, but are you saying it's a load order problem or a specific problem within the newest RWT? My load order was unchanged during testing, only switching between RWT and DynDOLOD versions to identify the culprit. Generating LOD from scratch with a finalized load order containing RWT 5.7.1 results in the reflection bug occurring no matter what, while generating LOD from scratch with a finalized load order containing RWT 5.6 does not. Since this is true regardless of DynDOLOD alpha versions (something I only found out after making my initial post), it appears that the problem is entirely within RWT 5.7.1; somehow, running it through DynDOLOD causes it to not respond to doodlum's Sky Reflection Fix mod, whereas past versions were responsive. I trust that the problem isn't being caused by DynDOLOD itself as, as you said, DynDOLOD doesn't generate water LOD, but since the water bug only happens after generating LOD (without DynDOLOD, Sky Reflection Fix works correctly with RWT 5.7.1), I thought I'd ask to see if there might be something weird going on regarding mod interactions. Judging by a number of DynDOLOD-related complaints on the RWT page recently, I think the problem is on their end, or SRF needs a patch. I re-ran LODGen as well, but that did not solve the issue. Again, I don't think that this is a LOD problem, but a RWT problem that is somehow only surfacing after running DynDOLOD. Let me know if I misunderstood your reply, but considering I'm generating from scratch with a finalized load order, I don't think there could be an outdated worldspace record. Another edit: Using the tll console command to turn off LOD leaves the water problem intact (see here), so it's not just the water LOD that's messed up but the water in general, yet the bug only manifests after running DynDOLOD and enabling the output.
  19. LF111
    Update: I tested the current version of DynDOLOD on RW2 v5.6, and everything is fine. It's not a DynDOLOD issue, but an RW2 issue regarding DynDOLOD.
  20. LF111
    I've noticed an interesting effect on distant water LOD after updating from 3.00 Alpha 173 to Alpha 180. I use Realistic Waters Two for my water mod and I use doodlum's Sky Reflection Fix to solve the uh... sky reflection problem, therefore allowing me to leave bReflectSky enabled in Skyrim's .ini files. Yesterday, I updated from RWT 5.6 to 5.7.1 and updated DynDOLOD to Alpha 180. Generating LOD caused the reflection bug to return; you can see the images here. The only way to get rid of this bug is to disable bReflectSky in the .ini files, but this has negative impacts on water reflections and is something that I never had to do in the past. Using Sky Reflection Fix should prevent you from having to disable bReflectSky, but when generating LOD with Alpha 180, it no longer does so. Turning DynDOLOD off (while leaving bReflectSky on and not touching the load order) solves the bug, as does reverting to my previous LOD generation from Alpha 173. The problem appears to specifically be an interaction between Alpha 180 and either RWT 5.7.1 or Sky Reflection Fix. I haven't tried generating without either of those mods on, so I cannot confirm if it is solely a DynDOLOD issue (though I'd imagine there'd be a lot more reports if that were the case). Summary: Alpha 180 appears to be causing a water LOD reflection bug to appear that wasn't there before, holding load order and .ini settings constant. I've already reached out to the authors of both of those mods, but I thought I'd make a post here to cover all my bases. Log | Debug Log (I have no idea why the debug log is so massive, and since I was unable to get it to fit on Paste.ee, I've attached the link to download it on Ufile)
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.

  I accept