sheson

From https://dyndolod.info/How-LOD-Works When new cells attach, the game first loads the ground and lowers the terrain LOD meshes by a fixed amount under the ground and disables water LOD for the cells, loads all trees and disables their tree LOD, loads all objects and their full models and then disables object LOD for the cells. Full model loads. LOD is turned off once they are loaded. They need to load when the cells attach. It is not possible to load full models load slower. You can shorten (e.g. make things in the active cells load later) inside the cells by changing the in game Settings/Display sliders for Actor/Item/Object/Grass Fade to the left. DynDOLOD adds LOD for tens of thousands of objects that didn't have LOD before to lesson the amount of things popping into existence. If you have a particular case of something that should have LOD but doesn't, make a post about that specifically.

That line is in the mentioned export files already. In case the export file has been created by DynDOLOD it is set to False. TexGen generates single LOD textures and billboards. Those seem not to be relevant in this context.

There is no need for a "back door method" - whatever it is supposed to be. Simply adding a correct mesh rule works. For example:

LOD generators do not change how the engine works. They generate and improve LOD meshes and textures for the load order. https://dyndolod.info/How-LOD-Works

Only load the plugin you want to update RNAMs for (xEdit should automatically load all required masters). If it creates unresolved form IDs then, let me know a mod/plugin how to reproduce. The problem with the wrong position/model does not happen after you generate RNAM for the plugin you flagged ESM? E.g. the problem happens if a large reference is overwritten by an ESM without RNAM and the new cell / reference is not listed in any RNAM of any ESM plugin (OK that might be not trivial to test for your right now - I am just saying out loud the conditions)

You can try adding CreateObjectLODAtlasMap=0 to ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Then no object LOD atlas texture is created and the original textures will be kept. If you remove the line starting with TextureAtlasMap= from the export file (..\DynDOLOD\Edit Scripts\Export\LODGen_[Game MODE]_Export_[Worldspace name].txt) and then Execute LODGEn in expert mode shouldhave the same effect. It will still merge all shapes that share the same shader/texture. Set DontMergeShapes=True and each shape will stay separate. You can also create your own export file manually instead of using DynDOLOD and just start execute LODGen via a bat. See ..\DynDOLOD\docs\trees.ultra\tools\re-uv\merge.bat and merge.txt with minimal content. The first 3 0.0 are the position (translation), the next 3 0.0 are the rotation and the 1.0 is the scale. The first two 0 are meaningless in this context.

There has to be something else at work, too. Save games do save positions of things, so any tests need to be with new game. I would remove everything else from the plugin and only keep involved records and only test with the minimum number of plugins. That should at least quickly narrow it down to what records/changes are required to have the problem and others are more likely to be able to replicate it.

Do you have an example plugin where the actual full model loads in a different position/cell other than the position/cell that the winning overwrite of the reference defines? With a new game of course.

With either 1.5.97 or 1.6.353, either with the plugin COTN - Falkreath.esp from https://www.nexusmods.com/skyrimspecialedition/mods/56731 as is or after ESM flagging it without generating RNAM data, then generating LOD, I always see the new model and also the large reference seems to behave normally, e. g. it loads past the uGridsToLoad and turns off beyond uLargeRefLODGridSize.

I compacted the FormIDs and ESL flagged the plugin Timber for Whiterun MystiriousDawn.esp and removed "treereach, treepine, treeaspen," from the Ignore= line in DynDOLOD_SSE.ini and then generated LOD. The trees were copied from the child world to the parent word and LOD was generated for them as expected. DynDOLOD_SSE_ChildworldCopies_Tamriel.txt contains the expected lines for the trees as well. For example: [REFR:FE001D8F] (places TreePineForest02 [TREE:00018A02] in GRUP Cell Temporary Children of WhiterunPlainsDistrict04 [CELL:0001A276] (in WhiterunWorld "Whiterun" [WRLD:0001A26F] at 6,-2)) -> timberforwhiterunmystiriousdawnesp_000D8F_DynDOLOD_CHILD [REFR:084D18F5] ...

There is no mention in the post that the plugin has been ESM flagged, it seems to be an normal ESP based on the information provided. Seems to me the plugin triggers lots of large reference bugs already. The CK often adds all surrounding cells to the RNAM table, not only the one the large reference is in. This is used for pre-loading references one cell ahead (Skyrim LE or if large references are off). Be that as it may, the last plugin to overwrite anything is typically not ignored (unless the Ignore flag is set), so whatever base record / model is used is typically defined by the last overwrite.

I do not provide support for third party mods. This is the xLODGen support channel. xLODGen does not change how the engine works. Read the first post and the Terrain-LOD-Readme.txt included in the download archive. For questions, help regarding DynDOLOD 3 Alpha use https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-95/ Terrain LOD textures are generated exactly as the full terrain but with lower resolution. For terrain LOD textures to have more detail, increase the resolutions, check bake normal-maps. Use BC7 Quick, so terrain LOD texture generation doesn't take as long. The visual differences to BC7 Max will be insignificant - if at all. If you use a tool that edits terrain LOD textures after generation, compare its output to before to make sure it did not degrade resolution/quality. For better terrain LOD meshes, set values for quality, check the protect cell border and the make use of the optimize unseen dropdown.

The reference is already reported as being overwritten, no? What you describe is not really possible AFAIK I know. Check with More Informative Console which are the last plugins reported to change the reference / base record. The engine enforces its own load order of plugins which can be different to plugins.txt. Test with latest version from https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

And what would the name of the mod(s) and plugin(s) be?

Do not install the game into special Windows folders like Program FIles x86 to avoid issues with UAC, anticvir etc. You did not provide any information about the flags, Grid, and Reference settings. From https://dyndolod.info/Help/Mesh-Mask-Reference-Rules: The order of rules matters. Rules at the top match before rules at bottom. Reference Form ID rules always take precedence over Mesh Mask rules which target base records. The mesh mask is any part of the path/to/model.nif of a full model defined on a base record. Check the path on any base record, you will notice it is relative (e.g. does not start with a drive letter) and also does not start with meshes\ In the case a specific reference - a distinct object in the world - needs its own rule, it can be targeted by using the plugin filename and its form ID. While mesh masks target the model path/filename.nif defined on a base record, reference form IDs target the reference. Using the form IDs of base records does not work. Flags VWD - Visible When Distant The rule is only applied if a matching LOD model is found. If no matching LOD model exists the rule is ignored. That means, if no LOD model exists, do not check the VWD flag if the rule is supposed to apply. Since a LOD model for StockadeScaffoldTop1Sided01.nif (and most other stockade models) exists , if you want to overwrite the automatic matching of LOD models with a mesh mask rule, the VWD flag needs to be checked. All in all it would be much better to create dedicated LOD models for the new full models and it would be best if those new LOD models target the CRC32 of the full model specifically. See https://dyndolod.info/Mod-Authors

I will need to generally enable the game mode FO4 and do some other updates in the code. Send me one FO4 config file that contains at least one LOD texture, then I could see about implementing that.

DynDOLOD Resources already contains stockade LOD models. See https://dyndolod.info/Help/Mesh-Mask-Reference-Rules. You did not provide the actual entire settings that you tried.

There is no extra step. Anything that would have object LOD in Tamriel (e.g. LOD assets or mesh mask match) and does not match the ignore lists and does seem to exist already in the parent world near the same position gets a facsimile copy. Check ..\Logs\DynDOLOD_SSE_ChildworldCopies_Tamriel.txt for the list of objects that made the cut. Make sure to edit the right INI. The better method would be that whatever mods adds trees to the child world, should also add them to the parent world.

Read the first post which debug log to also upload when making posts. As explained in the first post, click the "Click on this link for additional explanations and help for this message" of the error prompt, which should open https://dyndolod.info/Help/LODGen Read the explanations for the reported error code E0434352. Check the reported LODGen logfiles for additional hints as suggested.

Moved the post to the DynDOLOD 3 Alpha thread. Tree, object and terrain LOD are meshes and texture loaded by the game and not the same as dynamic LOD, which is what requires the clean save. It trees have no LOD, then either billboards were missing at tree LOD generation time or the tree LOD distance is too short. https://dyndolod.info/Help/Tree-LOD https://dyndolod.info/Help/Mod-Configuration-Menu#Tree-LOD

The one in the Solstheim worldspace is a different reference in that worldspace in Dragonborn .esm

Moved the post to the DynDOLOD 3 Alpha thread. Upload the log and debug log when making posts as explained on the first post. Use the "Copy message to clipboard" link and paste the text instead of posting screenshots as explained on the first post. Click the "Click on this link for additional explanations and help for this message" to open https://dyndolod.info/Help/DynDOLOD-Resources. Check the Troubleshooting section. Do not install the game into special Windows folders like Program Files x86 to avoid issues with access permissions, UAC, antivir etc. Yes, the error message is self explanatory. A required file that is installed with DynDOLOD Resources SE Core Files is not found in the used data folder of the game. The FOMOD installer always has the Core Files checked. The checkbox can not be unchecked.

Simple Windows programs like xEdit/DynDOLOD or LODGen using standard OS functions can not damage RAM any more than any other program by simply using it.

The tools need the time they need based on user settings and load order. Use BC7 quick instead of BC7 max.

If a computer turns off, reboots, has a BSOD etc., then there is a hardware, BIOS setting, OS or driver problem. If there is a log, debug log, bugreport.txt then upload them as explained at the first post. If there is an error message, event log entry copy and paste its text.