Farsveinn Posted February 26 Share Posted February 26 No, the flickering remains, it's a dynamic LOD problem. Static lods are fine. Link to comment Share on other sites More sharing options...
sheson Posted February 27 Author Share Posted February 27 21 hours ago, Farsveinn said: No, the flickering remains, it's a dynamic LOD problem. Static lods are fine. Replace ..\Meshes\DynDOLOD\lod\effects\fxwaterfallbodytall02_dyndolod_lod.nif from DynDOLOD Resources with this fxwaterfallbodytall02_dyndolod_lod.nif No need to to run DynDOLOD again. Just start the game test. Let us know if the dynamic LOD has less flicker now. 1 Link to comment Share on other sites More sharing options...
Farsveinn Posted February 27 Share Posted February 27 7 hours ago, sheson said: Replace ..\Meshes\DynDOLOD\lod\effects\fxwaterfallbodytall02_dyndolod_lod.nif from DynDOLOD Resources with this fxwaterfallbodytall02_dyndolod_lod.nif No need to to run DynDOLOD again. Just start the game test. Let us know if the dynamic LOD has less flicker now. Unfortunately, nothing has changed. Link to comment Share on other sites More sharing options...
sheson Posted February 27 Author Share Posted February 27 4 minutes ago, Farsveinn said: Unfortunately, nothing has changed. How about this version? fxwaterfallbodytall02_dyndolod_lod.nif Link to comment Share on other sites More sharing options...
Farsveinn Posted February 27 Share Posted February 27 No, it seems to have gotten worse (unless my eyes deceive me). Strange, a similar waterfall doesn't have this problem like fXwaterfallbodytall_dyndolod_lod.nif Link to comment Share on other sites More sharing options...
sheson Posted February 27 Author Share Posted February 27 10 minutes ago, Farsveinn said: No, it seems to have gotten worse (unless my eyes deceive me). Strange, a similar waterfall doesn't have this problem like fXwaterfallbodytall_dyndolod_lod.nif Doublecheck in xEdit that base record xx07607D in DynDOLOD.esm uses "dyndolod\lod\effects\fxwaterfallbodytall02_dyndolod_lod.nif" for the MODL - Model Filename Doublecheck in MO2 right window data tab that the winning file is the last one I uploaded and has 13,230 bytes file size. If all that is the case, are you sure it still flickers if you disable static object LOD with tll? If that is the case, "disable" the dynamic LOD reference xx0EB29F in DynDOLOD.esp that uses the base record xx07607D in DynDOLOD.esm in console. Is there anything else there? Link to comment Share on other sites More sharing options...
Farsveinn Posted February 27 Share Posted February 27 Double check that the size and path are correct. I compared the default and the latest .nif. The default is flickering with tll. The latest one stops flickering with tll. Disable 0EB29F removes strong flickering, only minor artifact remains. It turns out the problem is when I look through the waterfall at static lods. As I understand it. I would have thought I made a mistake in the generation, but no. I even tested by prioritizing static lods from xlodgen, but the result is the same. Link to comment Share on other sites More sharing options...
sheson Posted February 28 Author Share Posted February 28 15 hours ago, Farsveinn said: Double check that the size and path are correct. I compared the default and the latest .nif. The default is flickering with tll. The latest one stops flickering with tll. Disable 0EB29F removes strong flickering, only minor artifact remains. It turns out the problem is when I look through the waterfall at static lods. As I understand it. I would have thought I made a mistake in the generation, but no. I even tested by prioritizing static lods from xlodgen, but the result is the same. The "latest .nif" refers to the dynamic LOD model fxwaterfallbodytall02_dyndolod_lod.nif with 13,230 bytes? "The latest one stops flickering with tll" means there is no flicker if all static LOD is disabled? "Disable 0EB29F removes strong flickering, only minor artifact remains." means if only the the static is shown it still flickers a bit even with the fxwaterfallbodytall02passthru_lod.nif from this post https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-167/?do=findComment&comment=277418? If you disable both the static LOD with tll and disable the dynamic LOD reference xx0EB29F there is nothing left showing there? "static lods from xlodgen" refers to static terrain LOD? Since the DynDOLOD output does not contain any static terrain LOD files, there should be no conflict between the outputs. DynDOLOD output only contains static object LOD (and the disabled static tree LOD since you generated ultra tree LOD). Link to comment Share on other sites More sharing options...
Farsveinn Posted February 28 Share Posted February 28 8 hours ago, sheson said: The "latest .nif" refers to the dynamic LOD model fxwaterfallbodytall02_dyndolod_lod.nif with 13,230 bytes? "The latest one stops flickering with tll" means there is no flicker if all static LOD is disabled? "Disable 0EB29F removes strong flickering, only minor artifact remains." means if only the the static is shown it still flickers a bit even with the fxwaterfallbodytall02passthru_lod.nif from this post https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-167/?do=findComment&comment=277418? If you disable both the static LOD with tll and disable the dynamic LOD reference xx0EB29F there is nothing left showing there? "static lods from xlodgen" refers to static terrain LOD? Since the DynDOLOD output does not contain any static terrain LOD files, there should be no conflict between the outputs. DynDOLOD output only contains static object LOD (and the disabled static tree LOD since you generated ultra tree LOD). 1 - yes 2 - yes 3 - My mistake, I didn't use fxwaterfallbodytall02passthru_lod.nif for the last test. The small artifacts are completely gone 4 - Yeah, it's clean, nothing left 5 - Yes, I know, I just decided to do a test in case the problem is in the generated static objects, I also checked by disabling the terrain. Nothing has changed. As a result fxwaterfallbodytall02passthru_lod.nif fixed static lod flickering and the last fxwaterfallbodytall02_dyndolod_lod.nif (13,230 bytes) fixed flickering in tll mode. But in normal mode the flickering fxwaterfallbodytall02_dyndolod_lod.nif is not gone. Sorry if I write illiterate, it's not my first language, but I try. Thanks for your help. Link to comment Share on other sites More sharing options...
sheson Posted February 28 Author Share Posted February 28 2 hours ago, Farsveinn said: 1 - yes 2 - yes 3 - My mistake, I didn't use fxwaterfallbodytall02passthru_lod.nif for the last test. The small artifacts are completely gone 4 - Yeah, it's clean, nothing left 5 - Yes, I know, I just decided to do a test in case the problem is in the generated static objects, I also checked by disabling the terrain. Nothing has changed. As a result fxwaterfallbodytall02passthru_lod.nif fixed static lod flickering and the last fxwaterfallbodytall02_dyndolod_lod.nif (13,230 bytes) fixed flickering in tll mode. But in normal mode the flickering fxwaterfallbodytall02_dyndolod_lod.nif is not gone. Sorry if I write illiterate, it's not my first language, but I try. Thanks for your help. Replace Meshes\lod\waterfalls\fxwaterfallbodytall02passthru_lod.nif from DynDOLOD Resources with this fxwaterfallbodytall02passthru_lod.nif Start DynDOLOD in expert mode, select Tamriel and check Object LOD and then click the Execute LODGen button to update the object LOD meshes from the last generation. See https://dyndolod.info/Help/Expert-Mode Let us know if there is less flicker now when both everything is active as usual. Link to comment Share on other sites More sharing options...
Mousetick Posted February 29 Share Posted February 29 9 hours ago, Ylikollikas said: Alright, so my binary search lead me to "Tamriel_ShesonObject" cause. First I suspected it is not actually cause, rather removing the master activator would have prevented the real culprit from presenting itself. However, this was verified by removing all references in worldspace / cell records in dyndolod.esp except the "Tamriel_ShesonObject", which caused the crash to still remain. So it seems Tamriel_ShesonObject is the reference causing the crash. Basically the situation is: Only "Tamriel_ShesonObject" -> crash Everything but "Tamriel_ShesonObject" -> no crash nvm was too hasty, did few more rounds of death -> reload and the crash did happen I will investigate more. Also since if someone else who is getting similar crashes could also do similar binary search that'd be great. I don't think DynDOLOD (specifically, the DynDOLOD .esm, .esp, and Occlusion.esp plugins) is the cause of the crash. As we tentatively found in the other topic regarding this issue, based on analysis of various crash logs and Papyrus logs, the crashes appear to involve references to ACTI base objects with locally attached scripts. These references and/or activator base objects can come from vanilla or from mods. It just so happens that DynDOLOD places references in the world to its own ACTI with a locally attached script, so they seem to be affected too: they're the 'victim' of the bug, so to speak, rather than the perpetrator. Your test results seem to confirm that. Furthermore, the crashes are random over time and space, and the few Papyrus logs that were examined point to some kind of in-memory data corruption at runtime. Static data like ESP/ESM plugins, if they are free of any error in xEdit, cannot by themselves cause such kind of runtime data corruption. It's much more likely to be caused by buggy code: Either native code from SkyrimSE.exe (extremely unlikely or it would have been experienced by many more users a long time ago). Or native code from SKSE or NetScriptFramework DLL plugins (DynDOLOD.dll included). Or VM code from compiled Papyrus scripts added or modified by mods. Or a combination of several of the above. You may want to read the other topic (A new crash I am trying to diagnose) in its entirety, particularly regarding the WARNING messages in the Papyrus log, which may be used as an indicator of corruption and as an "early warning system" of an impending crash. In that topic I also try to offer suggestions for troubleshooting. 1 Link to comment Share on other sites More sharing options...
sheson Posted February 29 Author Share Posted February 29 4 hours ago, Ylikollikas said: Thanks for the directions on how to proceed. I'm a bit busy for the coming days, so I can't test this stuff soon, but I'll report back when I have time to test this stuff out. Also, someone I know said generating DynDOLOD with non-DLL version fixed the problem for them, so I might eventually test the same. Though staying on NG would be preferred to avoid the need to manually fix large reference bugs. Test and report back whenever you have the time. We will continue to troubleshoot until the problem is fixed. Ignoring or avoiding a problem is not a fix. Not reporting a problem here means the requirements to use and participate in the DynDOLOD 3 alpha test are not met. I share DynDOLOD 3 Alpha and the experimental large reference bugs workarounds publicly with the requirements to help with the testing and to report bugs in order to have them fixed for everybody. Whatever issues others users have, they can typically also be avoided by removing specific mods. 1 Link to comment Share on other sites More sharing options...
Farsveinn Posted March 1 Share Posted March 1 On 2/29/2024 at 3:08 AM, sheson said: Replace Meshes\lod\waterfalls\fxwaterfallbodytall02passthru_lod.nif from DynDOLOD Resources with this fxwaterfallbodytall02passthru_lod.nif Start DynDOLOD in expert mode, select Tamriel and check Object LOD and then click the Execute LODGen button to update the object LOD meshes from the last generation. See https://dyndolod.info/Help/Expert-Mode Let us know if there is less flicker now when both everything is active as usual. Yes, that completely fixed the problem! Thank you. Hope this helps someone else. Link to comment Share on other sites More sharing options...
kelvineppolon Posted March 1 Share Posted March 1 (edited) On 2/25/2024 at 8:15 PM, sheson said: Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Use the "Click on this link for additional explanations and help for this message" of messages to open https://dyndolod.info/Messages/Unresolved-Form-ID for further explanations and help for a message as explained on the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages Read https://dyndolod.info/Messages/Unresolved-Form-ID for explanations about possible causes and fixes of unresolved form IDs. See https://dyndolod.info/Changelog Support for plugins with version 1.71 has been added in Alpha 157 December 6th, 2023. DynDOLOD DLL NG has scriptless dynamic LOD and other fixes even if the large reference system is disabled. It always requires the large reference bugs workarounds checkbox checked. The IgnoreLargeReferences setting is irrelevant with it. DynDOLOD log : https://ufile.io/n1g7l9i7 SSEEDIT cannot properly recognize the header version 1.71 of The Serpent's Covenant - Quest Mod version 1.0.1 plugin (Warning: internal file FormID is a HITME), but the game itself runs smoothly. Edited March 1 by kelvineppolon Link to comment Share on other sites More sharing options...
sheson Posted March 1 Author Share Posted March 1 1 hour ago, kelvineppolon said: DynDOLOD log : https://ufile.io/n1g7l9i7 SSEEDIT cannot properly recognize the header version 1.71 of The Serpent's Covenant - Quest Mod version 1.0.1 plugin (Warning: internal file FormID is a HITME), but the game itself runs smoothly. DynDOLOD is a modified xLODGen, which is a tool mode of xEdit. DynDOLOD supports plugins version 1.71, because the current xEdit Experimental version supports it. Checking Serpents_Covenant_Merged.esp with xEdit reports no errors. I can view FExxx42D fine and the enable parent FExxx1DD SCHorseRuinedMarker shows correctly as well. I have no errors with just Serpents_Covenant_Merged.esp in the load order and generating LOD with DynDOLOD 3 Alpha 167. Are any other (patch) plugins overwriting any of these records in your load order? In particular mySerpentsPatch.esp which is not 1.71? if that is not it, test if it works when leaving IgnoreLargeReferences=0 at its default setting. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now