z929669

This post was moved from the DynDOLOD DLL topic. See my original post for context. Please recognize that I know this.... of all people, I know this. My questions preclude log files, as I had no issues other than missing HTML files that are normally generated. Sorry, I pasted the incorrect path from my saved logs location. When running DynDOLOD, a HTML summary of warnings and issues appears. Surely you know this, since you implemented it. The HTML files are created at: ..\DynDOLOD\Summary\. These files are not created nor automatically presented in the default browser at the end of DynDOLOD run when the "Large reference workarounds fix" check box is ticked. The LO hasn't changed, so the warnings are expected regardless ... or a Summary indicating that NO errors exist is expected (maybe because they do not apply when the LR fix is toggled? Please explain). Logs and output AND Summary for each run: "Large" toggle unticked "Large" toggle ticked Notice the lack of a HTML Summary in the latter. I repeated my test to confirm with "Large reference workarounds fix" toggled, and no Summary HTML messages are created even though the same LO is used and the same issues are inherent to that LO. This is an inconsistency. "Our tree mods" are EVT and Aspens Ablaze. These are vanilla tree replacers defined by non-ESM plugins that override vanilla records. Vanilla records are defined by ESM. SO ... will ticking the "Large" box add these trees as large references if the TreeLargeRefSize is greater than the 400 minimum set by default in DynDOLOD_SSE.ini? And from the doc (again, I post this): This is what I want to understand through asking directly rather than discovering indirectly though blind testing and assumption. Feel free to move this to the Alpha 3 topic. I thought that the new "LR fix" functionality was tied to the DLL and not DynDOLOD Alpha, so I posted here.

Fixed for me in Alpha 108

Got it. I generated using same LO and TexGen output with/without LF fix toggled in DynDOLOD GUI (and saved logs/outputs). I will do some testing with these outputs as time permits after the holiday. First finding is that the Summary report isn't generated with the LR fix toggled on: ../DynDOLOD/Logs/LR%20Fix%20Off/Summary/. Perhaps this is intentional and mentioned in the doc, but I missed it if that's the case. PS: I have not been ticking the "Large" box, due to this in the doc: Our tree mods are not using ESM, so I don't expect this toggle to apply to our LO. Am I interpreting this correctly?

Understood that it's hidden on purpose. I assume for testing purposes? I can report that the new LR workarounds and DLL scripts are working fine in terms of processing LOD and in-game visuals as expected. What exactly would you like to see as evidence for adopting the NG version as the new standard? I'd like to begin updating our process and linking to the NG DLL but don't want to do that until this file and it's progeny are available as normal. Thanks

See the Nexus MO mod page for where to submit MO feedback. I will say that your "Install and activate" idea is problematic in that there is no way to prioritize the installed mod. It just gets installed to the bottom of the left pane (highest install priority) and activated, which isn't useful. You would still need to prioritize it manually. Additionally, activating a mod is as simple as one click to check the box (or you could install all and activate all mods in one fell swoop using the right-click context menu from the left pane on installed mods). It sounds like you are following a guide and ordering the installs according to the guide maybe. Regardless, installing in sequence and enabling all at once in left pane alleviates the need to activate each one independently. Not sure why you would want to hide downloaded files. There's already plenty of ways to remove redundancies and sort that list without hiding them (which itself isn't useful, IMO. Hiding them creates new issues when you need to reinstall a mod).

ENBoost doesn't apply to SSE. Just use ENBSeries

Then I am clearly wrong that AV warnings are not an issue. I guess it can be, depending on the AV/security on the OS. I use ESET under Windows 11 and never ever had an AV issue or warning with BethINI, so you are likely running Windows Security defaults or an aggressive AV, because your AV is probably quarantining the EXE (probably due to a recent Windows update). You will need to figure out how to tame your AV and whitelist BethINI and any number of other EXEs related to modding. The first couple of posts on this topic may still apply.

After reading your posts about your issues, it's not at all clear to me what you did or are trying to do. You haven's supplied sufficient detail, and any number of things could be causing your issues. Rather than post back and forth, please read the OP carefully as well as the associated documentation. Your issues are almost certainly related to your configuration of xLODGen ( x - LOD - Gen ) and/or your modding environment. Careful reading is required as is taking a deliberative approach. Correct configuration of your modding environment is a prerequisite to using these and other modding tools. Read through this guide to get your environment sorted. It links back to this OP and all relevant documentation that you will need to carefully read. Doing your part to RTFM and all relevant documentation saves people that can help a lot of time by alleviating the need to do guess work and respond to posts that would likely not be made in the first place

False alarm virus warning? That's not normal. What game/version are you modding? Install the latest versions of BethINI and MO into paths not under Windows UAC control. See our System Setup guide for details on configuring your modding environment.

Just delete your INIs and start the game via the Steam launcher at whatever quality applies, and they will be regenerated properly. Then use BethINI for LE to get all the evidence-based, recommended tweaks.

Two minor USSEP text forwards I found while going through my rather meticulous patching process. These are tiny changes by the USSEP to those first two records that could be forwarded next update. One removes an improper hyphen, and the other a double space after the period. These are among the 'correct' changes to text made by the USSEP. The hyphen removal is a correction to a clear spelling mistake, while the double space after a period is stylistic but corrects an inconsistency. I'm inclined to always forward USP records, regardless of 'correctness' just for consistency; TLDR Other grammar and spelling changes the USSEP makes elsewhere are NOT correct but WERE originally correct. A good example is one that someone decided to make everywhere without verifying, like: I'd like to go, too. --> I'd like to go too. (USSEP incorrectly removes the comma in these cases). In other cases, the USSEP incorrectly adds commas or removes them. Example: stringing two complete sentences together with a conjunction should include a comma before the conjunction ... I remember this from the third grade. I was going shopping and forgot the potatoes. (incorrect USSEP change pattern) I was going shopping, and I forgot the potatoes. (correct in the original) If the USSEP team is going to police the grammar of the dialog, they should really do their homework first.

This seems like a game INI problem, but I've never heard of this. Try running through our recommended BethINI setup.

Not sure about all that as being applicable to moving marksman perks from thief to Warrior Stone. Thieves, by definition, aren't warriors. Combat isn't the thief's forte ... evasion is. But thieves need to defend themselves at times. Such a person wouldn't wield a close-combat weapon (including daggers) but rather a ranged weapon like a sling or a bow. This is fairly common knowledge where D&D and the roots of RPGs are concerned. The mod I linked gets it right, and the USSEP change doesn't, IMO ... at least with respect to the marksmanship buff.

Anything messagest at the top of the LOOT panel when you have ENB Light enabled? Running this version? Also read the description and installation requirements on ENB Light mod description.

So no LOOT warnings when you sort? LOOT often has messages in yellow that help sort out issues. Is your ENB working fine without ENB Light? You should be able to get the ENB GUI using Shift+Enter while in game to confirm.

Is the crash reproducible? If so, disable ENB Light and test to confirm that you don't get the crash. Then check that your ENB binary is the correct version and installed properly. Sort with LOOT and check warnings.

SSE Display Tweaks resolves the havok bugs, uncapping the FPS issues with that. It's an SKSE-dependent mod.

Seems like a USSEP overstep, but hard to say without seeing all of the changes it makes to the Stones. There's this mod, which would provide a convenient comparison.

If you installed MO per the guide instructions as 'instanced', then you want to point to your MO profile. Per the guide: My example: Also, you may want to update BethINI or be certain that you have the most recent version. Note that mine has a version check and looks a bit different.

Testing the Optional File, Thieves Guild Reformation - Taking Care of Business, per AYOP topic.

Discussion topic: Majestic Mountains Double-Sided Patch by z929669,T4gtr34um3r Wiki Link MM double-sided meshes created specifically for Step and maintained by Step.

Mod compatibility is a huge issue. It effectively promotes child worldspaces. Aside from that, it doesn't fit the Step Mandate and is a significant deviation from the vanilla game. Even DynDOLOD is trickier with open cities.

I would check to be sure that DLL is not also in your SSE game folder. After confirming that it's not, try a system reboot. Then try scanniing for corrept windows files )run a command prompt as admin and type: sfc /scannow Then try updating Windows. If all that still fails ... Validate your Skyrim against Steam to ensure you don't have any corrupt files. If you are running a previous version of the game line 1.5.97, you may need to re-downgrade.

Oh, yeah ... duh. My guess is that it's a mesh causing the crash and not ENB. Maybe there is a prepass shader defined in your ENB causing the crass, but I wouldn't bet that ENB is causing the crash directly or indirectly. Just a 'feeling', no evidence or use cases I am aware of though.

As I mentioned previously, I strongly suggest you begin by using BethINI to clean up your game INI files and set them properly. Then test things with a new game as mentioned.