z929669

Can you comment on the visual difference or maybe post two screens of that fireplace with/wihthout the optimized vs high quality options, all other Embers options same as in the guide install instructions?

I would check your Skyrim.ini ... or use BethINI to scrub it of nonsense and configure it correctly if you aren't already (this is one of the the main reasons why we use it ... gets rid of all kinds of support questions relating to bogus or even 'harmful' INI settings from the main game INIs)

So I wonder if both references are mistakes, or just the extra one. I know that icebergs in Riften --even small ones-- are a stretch, but who knows what the intent is? Maybe in spring after a cold winter, you get a small iceberg in the lake?

This isn't really an xLODGen support question at this point and is probably more of a guide-related issue, so I will address here. Please check that the path in your MO config is accurate for your actual path to this folder (just paste this into your 'Run' commandlet or into your Explorer path or even your browser address bar). EDIT: Run xLODGen from inside MO and not from the xLODGen folder itself. xLODGen is totally independent of DynDOLOD/TexGen, which is a different app (installed to a different path and configured in a similar manner in MO)

So employing your method to this BDA UDR record (Dragonborn is the master, and SMIM overrides the BDA UDR): Is it a LR? (seems so, if I'm understanding that post correctly) If so, could I "Copy as new record into ..." from SMIM into my patch per your more recent, elaborated-upon instruction? EDIT: I am guessing I would also forward that record from BDA "as is" into my patch, right? That way, the UDR itself survives and the new reference essentially recreates what SMIM is doing?

I just saw "NiNode" and "BsMultiBoundNode" as well as indents rolling up to "IcebergSmall02:0", and those don't exist in that NIF either. So I have no idea why nodes that don't exist in the model are referenced by the report. Similarly, two flags are also not evident in the NIF (not ticked in the BsFadeNode flags) ... kRenderUse | kPreProcessedNode again, it's likely because I have little idea of what exactly is be referenced in these crash reports. All I know is there's nothing wrong with this particular Glaciers LOD Meshes NIF and DynDOLOD, so it must be some interaction with another asset or plugin reference with this NIF that is causing the issues reported.

Before using the 'Optimized' version ... Is this with a full Step install and iMaxParticles setting per our instructions in BethINI if so? Step Heavy ENB?

Havok bug is remediated by SSE Display Tweaks. It may not matter much, but you might want to revisit the mod instructions for that page and be certain you set things according to your 144 Hz refresh (141 cap). You don't need to set anything in any INI, display software or SSE Display tweaks for caps at 60 if you follow those instructions and our BethINI setup instructions. You might only consider setting frame caps in UI for SSE Display Tweaks

meshes\lod\ice\icebergsmall02_lod.nif from Glacier LOD Meshes should be fine, but your crash report references several nodes that don't exist in this mesh from that mod: [RSP+60 ] 0x26D7F12DC00 (BSTriShape*) Name: "IcebergSmall02:0" RTTIName: "BSTriShape" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kNoAnimSyncS | kRenderUse | kPreProcessedNode Full Name: "" File: "lod\ice\icebergsmall02_lod.nif" Checking User Data: ----- Object Reference: File: "DynDOLOD.esm" Flags: 0x00000009 kDestructible | kInitialized FormID: 0x190026F7 FormType: Static (34) Checking Parent: 0 Name: "IcebergSmall02" RTTIName: "BSFadeNode" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kNoAnimSyncS | kPreProcessedNode Full Name: "" File: "lod\ice\icebergsmall02_lod.nif" Checking User Data: ----- Object Reference: File: "DynDOLOD.esm" Flags: 0x00000009 kDestructible | kInitialized FormID: 0x190026F7 FormType: Static (34) Checking Parent: 24 RTTIName: "NiNode" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kAlwaysDraw | kFixedBound Checking Parent: 3 RTTIName: "BSMultiBoundNode" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kAlwaysDraw | kFixedBound | kPreProcessedNode Checking Parent: 15 Name: "ObjectLODRoot" RTTIName: "NiNode" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kAlwaysDraw | kFixedBound Checking Parent: 3 Name: "shadow scene node" RTTIName: "ShadowSceneNode" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kAlwaysDraw | kFixedBound Checking Parent: 1 Name: "WorldRoot Node" RTTIName: "SceneGraph" Flags: kSelectiveUpdate | kSelectiveUpdateTransforms | kSelectiveUpdateController | kAlwaysDraw | kFixedBound Name: "IcebergSmall02:0" I don't fully understand what the report is calling out, but meshes\lod\ice\icebergsmall02_lod.nif from Glacier LOD Meshes uses NiTriShape and not BSTriShape (among several other differences). Step also uses this mod and that specific mesh without issue. Are you sure there is no other model with that name in your mods? EDIT: looking at the Nexus source mod page, I don't see that this file is provided in any of the other files out there ... are you running the latest version?

Very good then. Thanks all for contributing your expertise on this subject. We now have a topic to which we can point to for those wanting to better understand this issue and methods to fix it. This will certainly help me to remember the relevant details as currently understood (I tend to forget things if I don't work with them routinely ... aging brain).

Probably, but there may be other records that plugin touches, IDK. It may need patching with others of our mods, so you will want to check conflicts.

That drop sounds about as I would expect. I have my performance changes in the guide now with all of those layers for reference. I'm on a powerful rig, but running at 2560x1440 native resolution is a huge performance hit for me. I'm not sure what Immersive Children is doing plugin wise, so I don't know. It probably is, since we tend to be fairly sparing with complex plugins and scripting (with one or two exceptions). Probably would require some patching and potential asset-override management. If you are following 2.1.0, then you may want to hold out for 2.2.0, which will be released in the next two weeks (I hope). There will be a few mod updates and updated patches.

The terminology clarification is appreciated. Nomenclature is a great point of misunderstanding in my experience, but most people tend to be fine with reading between the lines. I am not one of them. Sometimes I resolve simple misunderstandings related to this, and other times I'm the only person in the room with questions because of this Thank you The linked post instructions for determining LR is helpful as well. Now... at the risk of wearing your patience further (in which case, please respond per your inclinations), I'd like to broach the more complicated "overridden LRs" that are not initially disabled. And per your first version instructions invoking my question: So one would or would not create an entirely new record for this LR? I suspect not, and that one would simply recreate (copy with override into) the offending record in a new patch plugin (to accompany LRFix.esm) and modify with what I call "subrecord overrides" to effectively replace the offending subrecord values? (so basically a normal override-patching method to a record)? EDIT: on re-reading your original though, I guess I am thrown off by your idea of placing this into LRFix.esm (it must be a different record than the the original Skyrim.esm override, or they/it would be the same record in LRFix.esm). This makes me think that it is indeed a new record/EditorID pointing to the same reference, and I honestly don't have much personal XP do draw on here.

Mods with INI files can override specific game INI settings if they are defined. Not permanently though. You can simply comment such lines in a mod INI file using a semicolon preceding the offending setting. To see mods loading INI files, you can look at the plugins tab in right pane (plugins can load INI files): Right click the plugin > Open origin in Explorer, and edit the INI there.

If this is EVT, is it possible that it's due to certain branch texture options not being 'clean' on the UV map of the source atlas? or not being between 0-1? Then this causing mipmap artifacts? I believe that some of the EVT UVs of certain branch options may capture bits of other parts of the texture not under the alpha opacity of the atlas and wonder if this could manifest in such a way.

I'm glad taht my motive wasn't clear then, because you just confirmed my suspicion. Yes, that was added as a placeholder of sorts to that ESM. It is a hypothetical fix for the LR bug but likely not a LR or a LR bug for that matter. Tech can explain more, but my main concern is if it could be creating a potential LR bug if it were in fact a LR. And what if it's not a LR? ... It sounds like the only purpose this particlular record could have in the BDA_DisableRefs plugin is to create a problem rather than solve one ... but IDK, honestly. I'm probably misunderstanding, but .... I think literally, so to me: override = one has higher priority and 'wins' (non-destructive) overwrite = one replaces and 'wins' (destructive) Another potential point of misunderstanding (for me): A plugin record (xEdit left pane) has subrecords (or whatever the proper nomenclature; xEdit right pane). One must replicate the entire record into another plugin (or it must also exist in another plugin) for the subrecords to line up to make changes (I think of these as subrecord overrides inside a record override). It seems to me that you are saying "right click on Skyrim.esm in the right-pane header of that record, and 'copy as override into' the LRFix.esm and change the z coord on that record in LRFix.esm". Thus, the record in LRFix.esm overrides the record in Skyrim.esm, and they are identical but for the subrecord override(s) in LRFix.esm. Then in #3, you are saying to recreate this record (with a different EditorID) using BadPlugin.esp as the source? .... SO, we have two separate records now in LRFix.esm pointing to the same reference? (e.g., they will not align in xEdit right pane) (more on the rest later once I have made it over this cognitive hump ) Good explanation. Thanks for taking the time

I made this a bit less wordy, and I think it's clearer. 100 FPS loss is relative to what? If you are running at 200 FPS, that's a lot different than if you are running at 120 FPS and lose 100 frames. Also, there is no "Heavy FPS setting" I know of, so do you mean the Step Heavy ENB? This one costs about 30-40% of your available framerate on average, ish. As long as you end up with ≥50 FPS on average, you should be good.

I haven't noticed this on my system with our build, so I suspect it's related to INI settings, video drivers/software, and/or possibly monitor type/settings. Maybe SSE Display Tweaks has something for this ... possibly try capping all of your UI frame rates to native monitor refresh rate in that mod (I do this in my config).

If you really want to tax your system, run it upscaled. I use AMD, but I'm sure NVIDIA has this: https://www.amd.com/en/support/kb/faq/dh-010 Again, there probably isn't much headroom to do this unless you are running a powerful box with a good monitor and NOT our 'ultra' DynDOLOD configuration (which itself is a waste of resources)

I like that you must work to get it, but I would prefer if the very first treasure to which you are alerted is a map to the location of this book under a pretense of some minor 'real' treasure. Or maybe in a minor quest very early in the game using some other pretense. But I also understand wanting it to be effectively incorporated into your tool set at the start. I'd be OK with that. On the note of 'survivalness' ... I am an ultra-realism fan for RPGs (keeps them from feeling overly task oriented to me). I prefer Requiem for my own Skyrim gaming (on hold now for approx the past 10 years until EVERYTHING is ready ... maybe never). In my view, a really good RPG should take thousands of hours to complete for a single playthrough over maybe several years ... not at all unrealistic, I know. For a highly enjoyable psuedo-RPG XP in the interim, I always go to Dragon Age: Inquisition. What a rich world that is.

I have confirmed that the plugin isn't making any consequential changes with the update (using modGroups with CRCs in my dev setup), but there are a couple records we will be snuffing in our patch related to ownership and one or two other overreaches of this mod. Most of it is really just landscape edits if you install as indicated in the guide.

UPDATE: "Best answer" has sheson's succinct details and 'rules' for LR avoidance/fix as well as responses corresponding to this OP, but do see Mousetick's posts for a deeper dive into plugin-patching specifics relevant to resolving the LR bug. @sheson & @Mousetick have some very informative exchanges about the large references (LR) issue and it's mitigation, so that's why you are both tagged here. (search "large reference" and "large references" on the DynDOLOD alpha topic to find these posts). Example (follow the quote links to go up the convo chain) After spending hours reading through the DynDOLOD doc on this and about twenty relevant posts in the DynDOLOD topic, I still don't think the large reference mitigation methods are clear. I'm creating this topic for posterity and as a placeholder for anyone to understand methods to fix and their limitations. The issue itself and why it happens is clear in the DynDOLOD documentation. It's the mitigations/fixes and WHY they work that's unclear and even a bit contradictory, in some cases: The seeming contradiction I mentioned: From the doc linked previously... "A large reference or its enable parent that has the Initially Disabled flag can trigger the bugs." Also in the doc: "Alternatively, all large references of an affected cell could be moved underground out of view and new references replacing them could be added. These new reference wouldn't be large references. This is also a solution for large reference bugs triggered by the Initially Disabled flag in case it can not be removed." I interpret this as somewhat contradictory in the doc (or at least very confusing) and also in some pf the back & forth posting on this topic. Please straighten me out. Here's the example 'fix' employed on BDA (let's just assume this is a LR with the bug verified; although, it was created specifically to prevent a DynDOLOD warning in the log and is likely not even an LR or LR with the bug): How can "initially disabled" flag on REFR records be both the cause and a fix? Is it due to the plugin format (ESM/ESP/ESL)? I cannot find a clear explanation. Perhaps it's info learned since this fix was devised? Said 'fix' exemplified in #1 seems to contain the data required for DynDOLOD to create it's own override, setting the dummy 'WorshipperActivator' for the -30000 buried object. Is this true? Specifically, setting "initially disabled" flag, z = -300000, and "PlayerRef" as enable parent? This info is alluded is in the posting chain I linked at top. Please debunk if I am misinterpreting. How does the LR Fix MCM toggle fit into the timeline of our understanding and reaction to the LR bug problem? Is this a total workaround rather than using the example in #1? Should we even be doing what is shown in #1? The LR workarounds doc isn't clear (to me) in how to employ, who should employ, or the exact result to expect from employing. Perhaps "just do it" applies and "you'll figure it out if you just do it"? A good and fairly comprehensive explanation of plugin formats is posted on AFKMods, but it fails to address the context of why some plugins have changes --as in the LR mitigation in #1-- being made in the ESM rather than in a ESL/P. I have some educated guesses/assumptions, but some context here would be helpful, because it's not clearly explained anywhere that I have found (notwithstanding attempts to do so in various sources). For the record, I want to add an explanation I got from @TechAngel85 on the "XESP - enable parent" dataType/column/descriptor/'chunk' with "PlayerRef" and flag "Set enable state to opposite of parent" ... clarity on such things is helpful: "This permanently disables the reference because the parent is the player, and the player is always enabled. Since that flag is present, it'll never be enabled bc it only enables opposite of the reference (player)." Done for now, thanks!

Organization is good

See the guide system requirements. That's for running the baseline. If you go with 4k+ options for all mods that have them, ultra INI settings, Step Heavy ENB, and Ultra DynDOLOD options, the Step SSE mod build will tank any system running at native resolution on monitors > 1280x1024. The guide provides all of these options.

Should be fine but probably doesn't matter. I still need to test it all together to know for certain though.