Mousetick

Thanks for all the extensive tests and the information you've gathered, that's very useful. They're in line with what would be expected. Actually, you and I are both using AMD So it would be nice if DY, Greg and Tech could test this solution on their side, since they're all using nVidia. Yes that's what I had in mind. This wouldn't change the BethINI setup part of the guide and only adds one (temporary) SSEDT configuration setting tweak to the Performance Tuning - Benchmarking Steps section of the guide. This also would also avoid going down the specific driver settings rabbit hole. They're showing the different ways (in DirectX lingo) the game engine's graphics buffers are handled and sent to the GPU. "discard" is used in Exclusive Fullscreen mode where the buffer is copied directly to the GPU, "flip_xxxx" is used in Borderless Fullscreen Window mode where the buffer is shared with Windows' DWM which can "compose" it with additional windows (like overlay widgets such as media volume control, game bar, notifications and so on). More details and other interesting tidbits in relatively plain English: SwapChain Science It's fine, it was my mistake to mention it initially as I misunderstood its significance. We can ignore it I think. My (limited) understanding is that it allows for offloading some of the DWM work to the GPU and may be necessary to fully support fancy scenarios like using Borderless Fullscreen Window at a different resolution than Windows' desktop resolution.

Looks like there is a better way after all that I'd missed and mistakenly thought would require specific hardware support. V-Sync can be turned off and framerate can be uncapped in Borderless Fullscreen Window mode simply with SSE Display Tweaks' configuration. Both settings are under the [Render] section of SSEDisplayTweaks.ini: Change EnableVSync from true to false: ## Enable/disable VSync. # # IMPORTANT: If you're using borderless mode and want to disable VSync, EnableTearing must be set to true. # # Note: This option overrides 'iVSyncPresentInterval' in SkyrimPrefs.ini # EnableVSync=false Change EnableTearing from false to true: ## Required for disabling V-Sync in borderless/windowed mode. Only works with a flip SwapEffect option. # # More info: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/variable-refresh-rate-displays # # ENB WARNING: Disable this if you have ForceVSync set to true in enblocal.ini, otherwise your game might freeze on startup. # EnableTearing=true You can try it if you like. It works for me. It should work with any GPU + driver combo that supports DirectX 11 or 12, and on Windows 10 Anniversary Update (version 1607, March 2016) Spring Creators Update (version 1803, April 2018) or later. If you'd like to test it for validation purpose, please ensure all nVidia/AMD driver settings are set to default or "application-controlled" to get the most generic non-customized setup. The log will look something like this: [Window] [0x4E0324] Message hook installed [Window] [0x4E0324] Window created [Skyrim Special Edition] (0,0,1920,1200) [Render] [D3D] Requesting mode: 1920x1200@0 | VSync: 0 | Windowed: 1 [Render] [D3D] SwapEffect: flip_discard | SwapBufferCount: 3 | Tearing: 1 | Flags: 0x00000802 [Render] [D3D] Windowed hardware composition support: no As a simple way to check if the framerate is unlocked and V-Sync is truly disabled, you can display the Escape pause menu while in game and the FPS should quickly jump to 300 fps (or whatever FramerateLimit is set to in SSEDisplayTweaks.ini). The framerate limit setting should be higher than your monitor max refresh rate to ensure nothing else may be limiting it. As a simple way to check if the game is in Borderless Fullscreen Window mode, you can Alt-Tab out to another smaller app window and the game should still be displayed in the background. Why this requires a separate configuration setting that needs to be manually toggled in SSEDisplayTweaks.ini is anyone's guess, it would have been more user-friendly to infer it automatically based on the other settings. But it's there, and it does the job. This method is better than switching to Exclusive Fullscreen mode for measuring performance because it remains in Borderless Fullscreen Window mode, while Exclusive Fullscreen doesn't have the same performance characteristics as Borderless Fullscreen Window.

What we learned is that in both DY and Tech cases, specific nVidia driver-level settings were used, making the SkyrimPrefs.ini and SSEDisplayTweaks.ini configuration settings irrelevant and circumventing the instructions given by the guide, or even doing the opposite of the instructions with G-Sync. You could either try to provide instructions and support to uncap framerates in Borderless Fullscreen Window for every combination of GPU, monitor, driver, and OS features. Good luck with that... Or simply configure the game to run in Exclusive Fullscreen mode and turn off V-Sync via BethINI (SkyrimPrefs.ini) or SSEDisplayTweaks.ini settings, which will work in every case - assuming driver settings are at default, i.e. "Let application decide". I don't think enabling or disabling G-Sync/FreeSync/Adaptive Sync/Variable Refresh Rate actually matters: VRR doesn't work if the framerate exceeds the supported frequency range due to V-Sync being off. It doesn't limit the framerate, it simply synchronizes the monitor with the GPU. If the monitor can't keep up, then it can't keep up, the GPU still outputs full throttle. V-Sync does the opposite: it synchronizes the GPU with the monitor, so the GPU can only output as fast as the monitor can accept. Edit: Adaptive Sync could be confused with nVidia's 'Adaptive V-Sync' feature which is something else unrelated to VRR display

In order to compare experiences/results/configurations, I'd suggest you include your SkyrimPrefs.ini, SSEDisplayTweaks.ini and SSEDisplayTweaks.log to provide objective unambiguous information. Moreover, SSEDisplayTweaks.ini has configuration settings in the [Render] section which can override SkyrimPrefs.ini if they are un-commented, which can lead to confusion about which display mode is actually being applied. Hence the need to look at the log. Moreover, ENB may also have its own display mode settings which may or may not override SSEDisplayTweaks.ini and/or SkyrimPrefs.ini, leading to even more confusion. I don't use ENB so I don't know whether it's relevant or not.

Not that I know, but you can get the list of records with errors: in xEdit, right-click on the plugin in the list and select 'Check for Errors' in the menu. You can then enter the Form ID of a record with errors in the search box in the top left corner to quickly jump to that record.

When does it crash exactly: before displaying the main menu, when starting a new game, after a while while playing?

This is expected, no surprise here. This applies to any game on Windows 10 and later, it's not specific to Skyrim or SSE Display Tweaks. In Borderless Fullscreen Window mode, the game's window is controlled by Windows' DWM (Desktop Window Manager) which always uses (triple-buffered) V-Sync, so the framerate is capped to the monitor's refresh rate. The VRAM is also shared between the game and Windows + the other running apps, which makes task-switching and using multiple monitors seamless in Windows. 60 is not a magic number, it's simply the refresh rate of your specific monitor. If you use a high refresh rate or variable refresh rate monitor, the cap will be different: e.g. 144 fps, 240 fps, ... No matter what the in-game or driver settings for V-Sync are set to, Windows DWM enforces V-Sync, so V-Sync is always enabled in Borderless Fullscreen Window mode. In STEP SSE's case, this includes the Skyrim INI setting and SSE Display Tweaks configuration. In Exclusive Fullscreen mode, the GPU and screen are fully controlled by the game which can disable V-Sync and render frames at a pace exceeding the monitor's refresh rate. This causes long pauses and "black-outs" or "flashes" when task-switching in Windows as control is transferred from the game to the OS or vice-versa, and resources are swapped in and out of VRAM. Those of you using a high refresh rate monitor may think the framerate is uncapped because you can get higher than 60 fps, but does it actually go higher than your monitor's actual refresh rate? For example, if the monitor is 240 Hz and you're getting 120 fps, that doesn't mean anything: V-Sync is still enabled via DWM and frame rate is capped at 240 fps. There is a special DirectX rendering mode (in DirectX 11 and later I believe) that allows a game to render at uncapped framerates (without V-Sync) even in Borderless Fullscreen Window while maintaining seamless integration with DWM in recent Windows 10 and later. This requires specific GPU and driver support, which may not be available depending on GPU grade and age. This also requires that the game engine is designed to leverage this mode, so only games released in the last 3-4 years might support it. SSE Display Tweaks can theoretically use this special mode if supported by the hardware, in which case its V-Sync switch should be effective even in Bordeless Fullscreen Window mode. I can't confirm whether it works or not in practice, but users can look at the log (in Documents/My Games/Skyrim Special Edition/SKSE/SSEDisplayTweaks.log), towards the end there will be some messages relating to Swap Effect and Desktop hardware composition. Here for example an excerpt from my log, showing that my crappy hardware doesn't support it: [Window] [0x9E02EA] Message hook installed [Window] [0x9E02EA] Window created [Skyrim Special Edition] (0,0,1920,1200) [Render] [D3D] Requesting mode: 1920x1200@0 | VSync: 1 | Windowed: 1 [Render] [D3D] SwapEffect: flip_discard | SwapBufferCount: 3 | Tearing: 0 | Flags: 0x00000002 [Render] [D3D] Windowed hardware composition support: no In summary: results will vary depending on each user's specific hardware setup and the only way to ensure that framerates are uncapped for benchmarking purposes in all cases is to switch (temporarily) to Exclusive Fullscreen mode. I had pointed out this fact back while beta-testing STEP SSE 2.0 and commented on it in one of the Admin topics (Skyrim SE INIs / BethINI / Performance Tuning), but it didn't resonate nor "stick". I hope the above is clearer and more convincing than my initial comments. Further reading: Demystifying Fullscreen Optimizations (Microsoft) For best performance, use DXGI flip model (Microsoft)

Using BitDefender? Windows 11 + BitDefender + SKSE = Crash on save. See this topic for the solution towards the end (read backwards to save time): SKSE CTD on Save.

Haha, another dialog mod! Yes, I've done the same as you BD. It's pretty good so far but I need to quit the habit of rushing to murder bandits and take the time to listen to their more varied banter and comments. Still can't get enough dialog? Check out More to Say (by abramcf). Caution: this is not a simple dialog expansion mod, it makes a few other changes to some existing NPCs and followers, adds a few other features, and it uses scripts (the large majority of them being unique to the mod, so no conflict). I've recently installed it and I like it so far. I think it's pretty good and well integrated into the vanilla game/lore.

The following is long and broad, so feel free to move the whole conversation into a separate topic if you think it doesn't belong here. Are you saying that CK can properly detect overwritten large references and notify the user, but mod authors disable this option? I know very little of CK. I just looked at it and played with it a bit, I couldn't find anything related to large references. I also tested moving a large reference and saving the overwrite in an ESP. CK happily obliged without a blip. I understand your position. It must be very frustrating to be dealing with those issues as long and as best as you have been. However I'm not sure it's fair to put the blame on the mod authors for being ignorant or on the mods for being defective. 1. There is no indication in xEdit or CK that a reference is marked as large in the master, there is no error or warning triggered in those tools when such reference is overwritten either. So mod authors are "blind" to large references. How can someone tell beforehand that modifying a particular reference that looks like any other is going to cause problems? The RNAM list is hidden by default in xEdit, and even if the option to show it is turned on, the information available is unusable by a mod author. It's a huge "blob" that is stashed away in the parent worldspace, disconnected from the references themselves, and impossible to humanly parse or cross-reference with the references in a given cell. Would you agree with this, or am I missing something? 2. From an anecdotal perspective as a casual mod user, it seems that more often than not, I'm sorry to say, mod authors are not familiar with DynDOLOD. Looking at the posts in the comments section on Nexus, user questions like "Do I need to re-run DynDOLOD with this mod?" or "Does this mod work with DynDOLOD?" receiving answers from mod authors like "What is DynDOLOD?" or "Maybe, I don't know since I don't use it" is a pretty common sight. Why that is, I don't know. In an ideal world, everyone involved in modding Skyrim should be familiar with DynDOLOD But that's not the case, for whatever reasons. Perhaps the large reference issues would be better known if they were considered and publicized separately from DynDOLOD. They exist independently of DynDOLOD but mod authors may be confusing them as a DynDOLOD-specific or DynDOLOD-induced issues. 3. On second thought, I realized that the suggested "best practices" for mod authors dealing with large references (splitting mod into ESM+ESP, burying them, creating new references...) don't appear to be a viable solution. They're merely workarounds, and pretty complicated to implement at that. Beside the extra care and work required, this scheme creates its own set of problems in regards to compatibility between mods and conflict resolution. For example, ModA and ModB each modify the same large reference. Let's say the object is a big boulder: ModA disables it to place its own building at that location, and ModB changes its dimensions and position slightly for "enhanced" landscaping. Following best practices, both mods bury the original boulder, and ModB places its own new boulder. Now what happens when both mods are present in the load order? There is ModB's boulder clipping into ModA's building. What used to be a simple load order priority conflict, becomes a complicated issue requiring visual inspection in the console or in CK to figure out where does the boulder come from and what to do with it, in order to resolve and patch the conflict. The complexity increases exponentially as the number of mods increase, since with this scheme, all mods "win" with their new references. Furthermore, the workarounds are not readily applicable to dynamically swapped references, such as with Base Object Swapper. I'd love to know your thoughts on the following ideas: 1. Would you consider making the "preflight" validation phase of DynDOLOD a separate tool that could be used independently of DynDOLOD? I'm talking about the validation phase that DynDOLOD performs after loading all the plugins and before generating the LODs and plugins per se, which is then used to produce the HTML diagnostics stored in the Summary folder. This would include the Large Reference Bugs warnings of course, but also all the other useful warnings. I often find myself wishing to be able to get these diagnostics but renouncing because they require running the full DynDOLOD tool and immobilizing my PC for a while. I did try running DynDOLOD and checking off boxes to speed things up, but all I got was nothing: DynDOLOD simply quit, saying something like "All done, thank you, bye" I think such tool could become an essential part of the modding toolkit for mod users and authors alike, similarly to Mod Organizer, xEdit, LOOT or BethINI, but without the pretty steep learning curve of the full DynDOLOD suite. It could also serve as a "trojan" to help familiarize people with large reference issues and to promote DynDOLOD via messages like "DynDOLOD can automatically fix this issue", with pointers to more information and downloads. 2. It would be helpful if xEdit could visually indicate large references by displaying them in a different color or style, so that mod authors are no longer blind. 3. As previously discussed, a more robust and generic solution to the large references issues would be at engine level, via a DLL runtime patcher, by automatically skipping overwritten large references, from a list previously generated by DynDOLOD. Pushing this idea further, an even better and cleaner solution would be for the DLL runtime patcher to build the in-memory RNAM list of large references from scratch on the fly (and maybe cache it if it's too expensive to do it every time the worldspaces are loaded). In other words, it would work a bit like your xEdit script, but at runtime rather than at plugin creation time, and it would automatically skip those that are overwritten by ESP plugins. With this approach, large references would always be correct and "clean", no matter the load order, no matter the final dimensions of the overwritten references, it could work cooperatively with Base Object Swapper, and finally there would no longer be a need for DynDOLOD to verify or attempt to fix them. It wouldn't matter if mod authors are aware of them or are specifically working around them. It might also make large references on the fly for ESM plugins that don't explicitly define them. It could make fLargeRefMinSize a runtime configuration setting rather than a fixed setting. Thanks for reading and again, sorry for the long post. I hope this provided some constructive food for thought.

Thanks for the quick answers. Yeah but CK only shows a static view of the cell I was looking for a way to check if a PlaneMarker is loaded and from where, at runtime. I managed to fix the PlaneMarker weird loading issue by applying a combination of the same remedies with xEdit as other large references: 1) flag the ESP as ESM, 2) overwrite the REFR in a custom ESM patch and bury it underground, and 3) copy the REFR as a new record in a custom ESM patch so that it's no longer an overwritten large reference. This particular overwritten large reference looked suspicious: the ESP overwriting it not only resizes and repositions it, it also puts it within a different parent cell. I suppose the engine may have been quite confused by this hence the weird behavior. Which brings some new remarks and questions: The whole large reference system looks pretty fragile and not at all compatible with modding. Mod authors should be a lot more aware of it and avoid overwriting large references, opting to bury existing ones underground and create new ones instead. The issue is how can mod authors be more aware of large references when they are not clearly made visible by the tools like xEdit or CK? If mod authors want to take advantage of the large reference system, they should create new references in an ESM and use your script to generate the RNAM list of the worldspace, rather than modifying existing large references. Overwriting large references creates more issues than just LOD unloading: What if the plugin resizes it so that its bounds no longer satisfy the "large" criteria? We end up with a unnecessarily bugged "small" reference. What if the plugin moves it to a different cell? Which cell is now bugged - the original one, the new one, both?

Hello, I'd like to get some clarification on a couple of Large Reference Bugs topics: 1. Large References to PlaneMarker (occlusion plane) STAT objects. It seems strange that PlaneMarkers would be large references. What would be the purpose? They don't have models, neither full nor object LODs, right? Is this used as a way for the engine to load them outside the uGrid? Is there a way to inspect PlaneMarkers in the console? In cycling through all the objects, I can get the door, wall, building, clouds, underside etc. but not the PlaneMarker, even though I'm right in front of the occlusion plane: I'm experiencing very weird behavior with at least one PlaneMarker which is a large reference, flagged by DynDOLOD as overwritten. Warning: Overwritten large reference in Occ_Skyrim-Legacy_of_Dragonborn_patch.esp [REFR:0010C31B] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeBluePalaceCourtyard [CELL:00037EE2] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -13,24)) Warning: Overwritten large reference in Occ_Skyrim-Legacy_of_Dragonborn_patch.esp [REFR:0010C31C] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeBluePalaceCourtyard [CELL:00037EE2] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -13,24)) It's defined in Skyrim.esm and overwritten by 3 plugins in the load order: Skyrim.esm places the PlaneMarker. LegacyoftheDragonborn.esm disables it. Occ_Skyrim_Tamriel.esp (from eFPS - Exterior FPS boost, ESM-flagged "out of the box") re-enables it, resizes it and changes its position. Occ_Skyrim-Legacy_of_Dragonborn_patch.esp (from eFPS - Official Patch Hub) re-sizes it and changes its position again. Without #4, the PlaneMarker is in the wrong position and obscures a building. With #4 everything looks ok. I tried to flag #4 as ESM in xEdit, which suppressed the DynDOLOD warning, but now the PlaneMarker is in the wrong position again, as if it were loaded from the wrong plugin - which one? I don't know since I can't inspect it with the console. Strangely, it's bugged only when I enter Solitude from the Tamriel worldspace. If I exit from a Solitude building (interior cell) directly to the Solitude child worldspace, the PlaneMarker is not bugged, it's like everything is loaded correctly. Note: This behavior is observed with or without DynDOLOD plugins enabled in the load order. So the issue is not related to DynDOLOD. DynDOLOD only comes into play because it helpfully warns about the large references. 2. Scope of Large References Bugs. I want to confirm and be absolutely clear on this point from the online doc: Let's say a cell contains 2 large references, LR1 and LR2. One of them, LR1 is overwritten by at least one ESP plugin, the other, LR2 remaining untouched. LR1 will trigger the LOD bug for both LR1 and LR2. Is this correct? From this we can conclude that even though an ESP plugin may overwrite only one large reference, its effect may be potentially far more visually "damaging" than one might think if the affected cell contains many large references. In other words, the number of "initially disabled" or "overwritten" warnings issued by DynDOLOD for a given plugin is not a good indication of how seriously bugged the LOD may become because of it. Is this correct? Thanks.

Except for More Dialogue Options and BUVARP SE RE, they're lightweight script-less small tweaks. Unfortunately some of them (Quiet Arcadia, Shut Up Brynjolf, Windhelm Segregation) are regular, not "light" plugins, so you'll need to ESLify them to fit in your load order, but it's safe to do so. A couple more of the "shut-up, don't interrupt me" kind: Fugitive Piss Off (by tarlazo) No Nagging in Taverns (by tarlazo)

That's my thinking as well. And even if some LR bugs do manifest in game, the worst that can happen is some z-fighting between LOD(s) and full model(s) in affected cells. It's not like they cause the game to crash or anything game-breaking. It may be in a cell that users may visit once or twice, or perhaps never, in a playthrough and therefore are unlikely to notice or be annoyed. I'd suggest using a finer set of criteria than simply "trigger DynDOLOD LR warnings or not" to decide whether to keep a mod: How many cells are affected by the LR warnings How many LR are there in the affected cells* (i.e. how likely are LR bugs to noticeably manifest in those cells) Are there visible defects with the LRs in the affected cells^ How frequently is an affected cell visited by an average player (e.g. is this near a town or in a remote mountainous area) How "important" is the mod in the whole build (*) Admittedly this is impossible to determine without dumping the RNAM records of the parent worldspace in the master plugins and cross-referencing them with all references defined in a specific cell. Can't be done by a human being so some kind of xEdit script would be needed to automate the process. Perhaps sheson can provide some advice on that. (^) The LR bug affects all LRs in a given cell. The DynDOLOD warning doesn't necessarily indicate that the LOD will be noticeably bugged in game for that specific overwritten reference. Other LRs in the same cell could be however. I reckon the proposed list of criteria is too complex and time-consuming to be of practical use. So perhaps going with #1, #4 and #5 in a first pass may be good enough, and then go with #3 (and ideally with #2 first) in a second pass to make a finer assessment if needed.

Yeah you may want to take a closer look. And perhaps double-check before dropping mods too quickly. There are a bunch of other mods in the guide that do trigger large references warnings from DynDOLOD and there is the question of what to do with them. I have this list from my notes but I can't guarantee its accuracy: Landscape and Water Fixes Cutting Room Floor Realistic Boat Bobbing Obsidian Mountain Fogs Embers XD Hearthfire Extended Oblivion Gates Remade SMIM Aspens Ablaze Butterflies Unchained Smooth Shores Farmhouse Chimneys Likely any new location mod such as Arthmoor's villages which I don't use. I was able to keep using all these mods and get rid of the DynDOLOD warnings by flagging them as ESM in xEdit (as well as their requirements in the load order as the case may be) and by splitting my CR patch into an ESM and an ESP (as the CR patch can also create large reference bugs). I'm not suggesting that the guide should instruct users to flag plugins as ESM, as that complicates things and presents its own set of pitfalls if one is not careful. I'm just saying this is an effective solution. I can't say for sure as I don't really have any point of reference for comparison and I don't run before/after performance benchmarks. All I can say is that I've been using it all along since I started implementing STEP 2.0 last fall, and it has not caused any readily identifiable issue for me. So it doesn't seem to hurt, and it probably helps too since there is less stuff for the engine to render.

Where do you see large reference bugs created by this mod? Can you show the specific warnings from DynDOLOD? I don't have any warnings for this mod with DynDOLOD alpha 74. The large references that this mod disables are automatically patched by DynDOLOD in DynDOLOD.esm so that they are buried underground without being disabled, which works around and avoids the LOD bug. There are some large references that are disabled by this mod and then overwritten by Realistic Boat Bobbing in the load order, which re-enables them and changes their positions. These overwrites by RBB trigger the LOD bug and are reported by DynDOLOD. Which I solved by flagging the RBB plugin as ESM.

I've been using this mod in my current playthrough, along with TTaH. Simplest Horses is very good IMHO: no fluff, no specific UI or added spell/power, only a simple but very convenient keyboard shortcut to do everything. No compatibility issues to report, works well with vanilla and custom followers. I wouldn't recommend including TTaH into the guide. While I like it very much and think it's great, it strays too much from the vanilla game mechanics and requires additional care (described previously in this topic).

I've been using this in my current playthrough (based on a modified STEP 2.0 build), so far so good after ~200 hours. Overlaps/conflicts with: Guard Dialogue Overhaul: I let GDO override it, as sorted by LOOT. TCIY: LOOT sorts correctly so TCIY wins as it should. USSEP: Like the original RDO, this mod uses the vanilla capitalization of words in the spoken lines rather than USSEP's. I don't bother to patch those. Hunters not Bandits: Keep using the version compatible with RDO. ASLAL, AI Overhaul: One or two conflicts here and there in the dialogue conditions with very minor differences. I patched some of them but it's entirely subjective. I've also been using and I'd recommend these dialogue tweak mods which complement or refine RDO and TCIY: Falion is Rude (by Parapets) Misc Dialogue Edits (by GOsteW) More Dialogue Options (by GOsteW) Quiet Arcadia (by Whitefang37) Relaxed Bards (by tarlazo) Relaxed Vendors (by tarlazo) Respect for the Legate (by tarlazo) Scene Tweak - Roggvir's Execution - Restored Dialogue (by AndrealphusVIII) Shut Up Brynjolf (by Whitefang37) Windhelm Segregation - Stay at New Gnisis Cornerclub (by Parapets) Last, I've been using Barely Used Vanilla Actors Recycle Project Special Edition Revamped (by AndrealphusVIII) which can be considered as an alternative to RDO's added NPCs and followers. This takes a different approach, by reusing existing vanilla NPCs and in doing so is simpler, more compatible and better integrated into the vanilla stories and world.

I don't think you could hope to achieve anything in xEdit for resolving navmesh conflicts at a relatively fine granularity level, since the raw data available can't be readily interpreted in practical terms. It's necessary to use CK to visualize the data in "geographical" terms in the context of specific game cells and their contents such as walls, paths, doors, obstacles etc. So you can either try to use CK to manually edit the navmesh in order for it to work with all the mods involved. Or you can resolve the conflicts in xEdit at a very coarse level by simply choosing one the mods involved and letting it "win" over the others by copying its entire navmesh into your patch overriding everything else. Again you can use this prioritization rule of thumb: the mod that has the most impact on the game should win.

Probably not.

I'd recommend switching to RDO Lite which had already been suggested before. This slimmed down "lite" version keeps all the dialogue changes while removing all the cruft from the original mod. I've been using it in my modified STEP 2.0 build. Very little to no conflict resolution patching necessary when sorting with LOOT. Separate compatibility patches are not needed either (not even the AI Overhaul compatibility patch despite what the mod description page tells us, at least in my experience).

Conditions are trickier. If they're not merged or conflicts are not resolved properly they can break dialog, quests, scenes, etc. Try to find existing compatibility patches between your mods if possible. Be mindful of AND and OR logical operators when merging conditions to follow correct precedence rules. By default conditions are ANDed together, unless OR is explicitly specified by the condition (eg. "Equal to / Or"). See this and that for more details. In some complex and relatively rare cases you may need to change a condition in your patch from AND to OR or vice-versa and re-order them. If a mod doesn't require USSEP or its description doesn't mention compatibility with USSEP, it usually means that it was made without caring for USSEP. I don't know what the dialog topic is in your particular case, but it's probably safe to merge both conditions, so that the line is spoken only when Mralki (NPC) is not dead, and only when the NPC speaking the line is located in Rorikstead. It helps to read the dialog to get some context, rather than blindly merging conditions.

Your patch is ok: CCOR removes the vanilla Amethyst, replaces it by a Garnet for arbitrary "balancing" reasons in the mod author's mind, and adds a bunch of its own stuff. CACO keeps the vanilla Amethyst and adds a bunch of its own stuff. The merged list combines both mods own stuff, and replaces the vanilla Amethyst by a vanilla Garnet, which is the correct interpretation IMHO. It's fine. You can keep both Amethyst and Garnet if you want, or just one or the other, it won't break the game, it'll only affect the type of loot you can find at level 1 and above. CACO and CCOR mods were made by the same person but they are inconsistent in this case, only they know the reason for that, if there is any. You can use your own judgement and decide which one is "right": replace the Amethyst by a lesser gem, or not.

I experienced this same strange and annoying issue which has disappeared since I've rebuilt my mod list and changed Skyrim's INI configuration several times. I have zero clue what may have caused it, sorry. Pretty sure it's not DynDOLOD though. I've been using DynDOLOD 3 on and off a lot for testing various things, and that has made no differences. The issue is gone for whatever reason, and hasn't come back in several hours of play using DynDOLOD.

I don't know why you'd want to skip them with mod groups. Mod groups hide all conflicts between mods in a group, not only leveled item lists. You can use Wrye Bash to create a Bashed Patch for leveled item lists, but the results can be incorrect so they need to be reviewed and manually tweaked if necessary. Since you already know how to make a patch to resolve conflicts in xEdit, you may as well want to do the same with leveled item lists and skip Wrye Bash. It's pretty easy: General rule: merge all lists from all mods by copying their items to your patch, so the resulting list is the union of all lists. Exception 1: if a mod removes some items from the vanilla list, it's on purpose, and those vanilla items should not be copied to the merged list. Exception 2: be mindful of duplicates. If several mods add the same item to a list, you probably want to keep/copy only one of them. Exception 3: changes made by mod compatibility patches. If a patch removes/adds/replaces an item from a mod's list, the same change should be reflected in the merged list. It's not a big deal if the lists are not perfectly merged. If in doubt, put the item in the merged list. The worst that can happen is you'll find more stuff on NPCs and in containers than would be expected, or you'll find multiple copies of the same or very similar items. Basic tutorial for merging leveled lists in xEdit for Fallout 4 (works the same for SSE): Fallout 4 modding tutorial: How to merge Leveled lists manually with FO4Edit (YouTube).