S-Matrix

Sorry if I'm being obtuse, but just in case, I want to point out that the following is also written in the section where the rule of thumb is detailed: "Vice versa, do not check this option in case the large referene system is used - uLargeRefLODGridSize > uGridsToLoad >= 5" I've actually spent a fair bit of today doing general performance tuning that extends beyond tweaking DynDOLOD, so I'd need to do more controlled testing to know anything conclusively. That being said, after finishing up the DynDOLOD gen process earlier with the box left unticked, my exterior performance in the Rift had pretty noticeably improved during the play session I started up immediately afterwards (in regards to both average FPS, and smoothness/consistency over fast camera rotations). I personally didn't notice any change in visuals whatsoever (just eyeballing, so of course this also isn't conclusive) - I have my Large Ref grids setting at 9, and as you probably figured, I'm using the Large Reference workarounds implemented via the NG DLL. Again, it could definitely just be that it coincided with unrelated and more significant changes I'd made outside of DynDOLOD (at the moment I don't remember what else I might have changed specifically before that session), so this is really just me saying that my findings, as of now, aren't exactly reliable and that I'd need a fair bit of time to set up a good testing environment (regenerating LOD, running a test save, etc).

Hi! I typically use the current STEP Guide iteration as a baseline for everything pertaining to LODs, and I had a question regarding the optional DynDOLOD toggle "Upgrade NearGrid Large References to FarGrid". The DynDOLOD site (on this page: Advanced Mode | DynDOLOD) explains that, if the large reference system is being used, the rule of thumb is to leave this unchecked. However, STEP Guide 2.3 instructions involve setting the large reference grids to 9 in the BethINI section but also ticks this box in both of the DynDOLOD config instructional images. I know it's possible that one source might be less up to date than the other and as a result may not reflect the most current technical details of DynDOLOD; additionally, the principle is theoretically just a rule of thumb as opposed to a strict necessity. If it's the latter case though, what makes it a good idea to do this for the STEP Guide load order as opposed to following the rule of thumb?

Yup, same error. Let me know if there's anything else I can try on my end at the moment.

New error with test version exe, with different error line: [Main Instruction] Error: No VMAD for SkyrimSE.exe DynDOLOD_FirstbornActivator "ThouShaltBowToMaster" [ACTI:00000902] Debug log: https://ufile.io/o1bvpfim DynDOLOD_SSE_log.txt

Hi! Getting an error running DynDOLOD for alpha-183; attaching logs along with line describing error details: Error: Access violation at address 00000000011AD0A9 in module 'DynDOLODx64.exe' (offset CED0A9). Read of address 0000000000000000. Also, in trying to attach the debug log directly, I realized the text file is 144MB in size - would that indicate something like a system problem right off the bat? Let me know if there's a preferred place to host the large text file, as for now I'm using a file.io/limewire link. I'm gonna give it another run in the meantime and see if the exact error is repeatable. bugreport.txt DynDOLOD_SSE_log.txt

Using xEdit 4.04, I believe - I saw today that there's an update available, so it's probably a good idea to move to the newest version. Gonna be afk for an hour or two, so I'll post with news later in the day.

Here it is: https://imgur.com/a/7Df35ed Not sure if it's normal for there to be two instances of it appearing in the asset window search results, but the assets listed for both entries are the exact same.

That's correct. Here's the list of textures you asked for: https://imgur.com/a/aK9UYFE As you can probably see, we have a lot of conflicts; however, these conflicts are all (I hovered over each one to be sure) between Mrf's Solitude and Kartoffel's Cleaned Textures. This specific conflict is completely expected, as Kartoffel's mod covers every texture in the game and I'm using it as a base. The one exception to this, as you also probably noticed, is in the case of swindow01_g.dds (which I assume is a glowmap or something similar). TexGen Output takes precedence here, but that texture is also found in USSEP, the lighting mod "Lux", and then again in Mrf's Solitude. My amateur's hunch is that this may be significant, given that Wizkid's mod for ENB window glow was also implicated in the crashlogs I'd posted. Keep me posted with new things to look at and report back with.

Voila, that's fixed it! Thanks so much Sheson, and let me know if you need anything else from my end to figure out the root cause of this, or if there's anything else I need to do as far as generation is concerned now that the ESM is edited.

https://imgur.com/a/xNfWHAC Let me know if this is everything as you wanted it/if you need anything else at the moment, and I appreciate you sticking with this.

Hi sheson, thanks for the reply - as per your suggestion I checked to make sure the mesh would open properly in NifSkope, and it did indeed do so. Next, using MO2's "Data" tab, I was able to see each mod in my load order that was contributing a version of the mesh; the one provided by "Flickering Meshes Fix" was the overriding version, so I isolated and then deactivated that file from the mod, and returned to the problem area, but the issue persisted. Before trying CAO, I decided to try removing the version of the mesh provided by "Assorted Mesh Fixes", which was next in line in terms of override/use by the game, but the crash still occurred. I repeated the process one last time with the "Landscape and Water Fixes" version of the mesh, mostly as a sanity check - alas: crash. Honestly, I'm not the most knowledgeable about troubleshooting mesh issues, especially with a completed DynDOLOD output in the mix, so this was mostly just me trying to brute force possible resolutions without being able to parse/tinker with the DynDOLOD output itself. While it yielded no results on my end, maybe this info can help with your more seasoned diagnosis. It indicates to me (and again, I'm pretty inexperienced) that the construction of the mesh itself isn't the root cause of the crash, since even across multiple different versions of the mesh, sblacksmith.nif still appears in the crashlog. If it does end up being related to DynDOLOD, would I need to regenerate LOD in order to test solutions? Is there a "mini-run" I can do, localized to the Solitude region, to save on generation time, in that case? Let me know if anything jumps out about the issue, or if there's some other things I can try in the meantime. Thanks!

Hello, currently getting repeated crashes while attempting to cross the estuary separating Solitude from the marshes north of Morthal. Using Alpha-156. Here's the crashlog https://pastebin.com/sWkypg9V where DynDOLOD is being pointed to, and the corresponding DynDOLOD generation logs are attached. As always, thanks for all your hard work. EDIT: Forgot debug log, uploading now and will post it here. EDIT 2: Here's the debug log https://ufile.io/vzz9bnx8 DynDOLOD_SSE_log.txt

I'm not sure if that's the case either, but I do know that ERM has, for the longest time, pretty much sat in the lowest part of the left pane of MO2 (followed only by Icy Mesh Remaster, along with DynDOLOD Add-ons and outputs). I also found that, in returning to the same mountain ridge while using the NON-parallax ERM meshes and the same ERM texture pack I'd already been using, the problem was no longer present. This, along with the fact that the warping appears all over Skyrim (not just outside of Falkreath) is pretty much enough to convince me it's a parallax issue, not an issue with COTN - Falkreath specifically.

I wish it were that clear-cut, but unfortunately, the reason "COTN - Falkreath" appears to be the last overwriting mod is because ERM has no ESP file. More Informative Console only detects plugin priority, not accounting for loose meshes or textures. Your suggestion is a good one, nonetheless.

Here's one video demonstrating the issue, btw, in case the author does take notice - along with shots of the More Informative Console window pertaining to the problem model. P.S. I have no idea if the streamable link I posted is going to expire in the near future, I'm not really familiar with using that site. I have the video saved on my PC, so if it needs to be reuploaded at any point, lmk.