sheson

A reference is placement of on object with position coordinates and rotation for example. A large reference means, the form id of such a reference is listed in the worldspace record RNAM list. Large reference are not LOD. A large reference simply continues to show the full model outside the uGridsToLoad cells but only to the distance of the uLargeRefLODGridSize setting. When records are overwritten by other plugins they typically keep most of the original data and only change a detail. Like if a rock is being moved a bit all but the position information of the record stays the same. Check the CK wiki and also start using xEdit to see how records in plugins work. In case the rock is a large reference, the RNAM data in the worldspace record of the overwriting plugin simply lists the reference again.

You sure you got the right cell? 6, -1 is inside Whiterun about where Heimskr is preaching. The last plugin Smash Patch.esp overwrites the record already and "unsets" the flags.

You want to check which mod makes changes to the cell record, its land record or maybe to landscape textures. If it's texture it probably would be more widespread. Use DynDOLOD SkyUI MCM You Are Here to get the cell coordinates. Use xEdit Cell Browser (CTRL+SHIFT+F) to find the cell's form id. Could be XCLC - Grid / Land Flags / Hide - Quad 1/2/3/4 flags

There are free image service like https://imgur.com/upload Log files can be found in the log folder of DynDOLOD. Checking texture would include finding out what mod - if any - supplies them with xEdit Asset Browser (CTRL+F3) and the MO2 right window data tab. plus checking them visually in an image viewer. If you have problems with a third party guide, you need to ask question about it on the appropriate forum/topic for that guide.

By scrolling through the list and checking them, just like you would have to for mesh masks. Hovering the mouse to get the extra information should help.

If you want that particular banner to also always show together with all other banners of the same type, use the mesh mask rule and remove the FormID rule (or also edit accordingly). If you only want that particular banner to always show, only edit that FormID rule and do not add a mesh rule.

There already is a rule for that specific banner to show in the NearGrid. This rule targets it specifically via its FormID. FormID rules take precedence over mesh mask rules. Mesh mask rules apply to all reference that use base records for which the mesh mask matches. So all banners that use GenericBannerRed03.nif. If you want that particular banner to also always show together with all other banners of the same type, use the mesh mask rule ad remove the FormID rule (or also edit accordingly) If you only want that particular banner to always show, only edit that FormID rule. The FormID rule that targets that banner is the one that has skyrim;000eb82e for the Mesh Mask/Reference field. Hover above it in the list to see more information, like the name and location of the reference and its base record. Also note the rule for its civil war replacement skyrim;000fcc65.

Do not post screenshots of text. Copy and paste the text instead. The large reference bugs means that the engine does not unload the static object LOD for all large references in a cell when it is supposed to. So the large reference full models and their LOD models show at the same. This can manifest as very obvious texture/lighting flicker between the two models. Any ESP overwriting a large reference triggers this bug for the entire cell. Hence the log messages as seen in the screenshot to warn about plugins that are not fully visually compatible with Skyrim Special Edition. If a plugin (ESM in this case, since it is not supported by ESP) overwrites a large reference, it should also list the large reference in its worldspace RNAM. That is what the game files do. If an overwrite/plugin is removed then whatever the overwrite record or plugin changes simply does not happen.

You can easily check if a tree mod contains billboard by looking if it contains textures and text files in a subfolder of ..\textures\terrain\lodgen\.. Those are not needed anymore. Users that are using the DynDOLOD 3 alpha are asked to test all new features, including the automatically generated billboards. Tree mod authors and users not having to worry about creating, finding and to correctly sorting billboards resources in the load order will be the new norm. I am almost certain you will find the automatically created billboards to look better, especially when using HD billboards with ultra tree LOD. Those settings should work the same in DyNDOLOD 2.x and the DynDOLOD 3 alpha. Are you reporting they do not work the same? The Grid should not matter when setting Reference to Original. Remember to remove any rules that actually target specific references with a form id.

Download the linked version of LODGenx64.exe and replace the existing version in ..\DynDOLOD\Edit Scripts\LODGenx64.exe Start DynDOLOD in expert mode (see ..\DynDOLOD\docs\help\Expert.html) Select the desired worldspace Click the Execute LODGen, so it simply restarts LODGen with the already existing export file for that worldspace. It should then generate the object LOD meshes for that worldpsace without error. Repeat for every world space that had errors running LODGen.

While you are writing about a wall textures, the tiny screenshots provide no information what they are about and do not show any walls from Markarth. No logs and no other information was posted. DynDOLOD uses the object LOD textures that are currently installed in the load order. TexGen can only update a few of them. TexGen from DynDOLOD 3 alpha a few more, including pre-rendered ones used by the cities. Check ..\textures\lod\mrkbuildingslod0[1|2|3].dds Also make sure nothing overwrites the TexGen/DynDOLOD output.

Why change a text file to pdf!? The warning messages say what is wrong: Warning: Wrong billboard path textures\terrain\lodgen\someplugin\*, should be textures\terrain\lodgen\anotherplugin\* The installed billboard with the wrong path will be used by DynDOLOD 3 alpha. These billboards won't be discovered by xLODGen/DynDOLOD 2.x tree LOD generation. TexGen should have generated all the billboards with the correct path, so not sure why it even checks for billboards that might have a wrong path. You are participating in the DynDOLOD 3 alpha. If possible, do not install any billboards. TexGen should generate them. Instead provide feedback in case TexGen does not generate the expected billboards.

Try disabling high dpi settings (right click properties) or font scaling in the OS settings or use DynDOLOD 3 alpha.

There is no DynDOLOD.esm for Skyrim/Enderal.

The log shows that there was an error and DynDOLOD did not print "completed successfully" to the message log: ERROR: Worldspace object bounds added by SlavePackRiekling.esp for [04000800] DLC2SolstheimWorld outside +- 128 cells. See the log or FAQ for more details. SlavePackRiekling.esp changed the size of DLC2SolstheimWorld beyond useful values. Either do not select DLC2SolstheimWorld when generating LOD or fix the object bounds to usefull values if they seem to be wild edits. To fix worldspace bounds error, open xEdit, open the DLC2SolstheimWorld worldspace record by entering the FormID 04000800 into the field top left of xEdit. Hit Enter key. Scroll right to the column of the mod SlavePackRiekling.esp. Scroll down to the rows for Objects Bounds. Right click a value and select edit and enter a number <= +- 128. In case it is a overwrite record use numbers from master mod as a guideline. There is also a DynDOLOD FAQ entry for DynDOLOD: ERROR: Worldspace object bounds added by plugin name.esp for [xxxxxxxx] Worldspace outside +- 128 cells. Read the instructions in the manual: Verify the messages say that LODGen for 'worldspace' completed successfully. After generation completed with the message 'DynDOLOD Worlds completed successfully', click 'Save & Exit' to close DynDOLOD.exe and let it save the newly created or updated DynDOLOD plugins. No other plugins should have changed. Fix the broken plugin or do not select the affected worldspace so that DynDOLOD can complete generating LOD successfully without errors. Only install the output if there were no errors generating it.

Post/upload the entire DynDOLOD log so we know which DynDOLOD version you are using, which game version you are using, which plugins are loaded and if there might have been warning or error messages. It is kind of obvious that the DynDOLOD output needs to be enabled for a cyclic interaction with DynDOLOD.esm being reported.

Always post the log please. The SSE-Tamriel--tamriel.esm should not affect this, unless there is a plugin in the load order also adds the same missing cells maybe. Try the version from it should create a bugreport.txt.

We only know there was an error while generating the object LOD atlas. The cause is unknown so far without the entire logfile and bugreport being posted.

OK, this all looks as it should then. If ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt still contains the GrassMap= line to ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt and that also contains the list of those grass billboards that is a good sign. Set Expert=1 and Verbose=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and start DynDOLOD, select Tamriel and click Execute LODGen so it runs again with the existing export files. With the verbose=1 its log ..\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt should contain some more information. Post/upload that.

I doubt you know what I came across before and what I didn't. I only trust log messages. Maybe look at them and follow their advice.

I find [01:27] <Notice: [Tamriel] Gathering grass data for object LOD> in the debug log that you reported is not in there. I can also see that it processed grass billboard and added them to the object LOD atlas for Tamriel. Double check the object LOD atlas textures in ..\DynDOLOD_Output\Textures\DynDOLOD\LOD\*.dds if they contain some of the grass billboards. They are really small compared to other textures. Check ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Object_Atlas_Map_Tamriel.txt contains lines that start with textures\terrain\lodgen\tamrielicgrass.esp\tg_coast_grass01_00000874_1.dds,8,textures\default_n.dds ....

Without posting about the supposedly more issues these types of statement are useless. I can guarantee every update improves something and rarely to never introduces new issues. In case an update breaks something, users make actual useful error report within hours and thus any regression is fixed shortly. Search official forum finds these: Carefully read every line of the message that was posted. Then follow their advice. Search official forum finds these: If problem persists, post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt and ..\DynDOLOD\logs\DynDOLOD_SSE_log.txt to official forum

What does this supposedly have to do with DynDOLOD 3 alpha? DynDOLOD generates object and tree LOD. It does not change cell water LOD in any way. The load order has probably weird INI settings, resource problems or maybe too many plugins over the limit etc. No modwatch was provided. No logs were uploaded. DynDOLOD FAQ: Game: Out of place objects / floating objects / flickering full models A: DynDOLOD does not change how the engine works. When new cells attach, first it loads the full models, then unloads object LOD. For that brief time both models show and there can be flicker. The busier the cell is and the more system rsource are strained the longer it takes to load full models and unload LOD. A: If LOD was generated for a different load order generate LOD for the current load order. A: Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If problem goes away, the updating of an existing save game with old DynDOLOD.esp went wrong. Follow instructions how to update save game with a new DynDOLOD.esp. RTFM, watch the video https://www.youtube.com/watch?v=1_5MWqeHIzw&t=2320 or check DynDOLOD SkyUI MCM. The clean save routine can also be redone with the same plugin to reset everything. A: If the load order had script lag and deactivating/activating from the DynDOLOD SkyUI MCM main page does not reset out of place objects, do the clean save routine where "old" and "new" plugin are the same. Consider generating less demanding dynamic LOD, see 'Performance' section in ..DynDOLOD\Docs\DynDOLOD_Manual.html A: Wild edit added by a plugin. Check the DynDOLOD log for messages about wild edits. Use console in the game and click on object to retrieve the form id. Look up the form id in xEdit and remove the reference, clean plugin afterwards. Notify mod author. If object is added by DynDOLOD.esp, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this object originates. A: Deleted record by a dirty plugin. Check the log for messages about deleted references by dirty plugins. Clean all UDRs and ITMs from dirty plugins. A: Sometimes LOD objects are placed on top of other objects without LOD and thus appear to float in the distance. Use mesh rules so that the object has no LOD or that the other object also has LOD. A: Game engine limitation. If the game enables objects that have static object LOD, the entire static object LOD for a cell may briefly show with the full models at the same time. Since now more objects have LOD this might be more obvious than before, especially while playing the intro. Consider installing the generated LOD mod after completing the intro. A: If the problems is stuck object LOD in Whiterun after fast travel, change Distant Object Detail on the View Distance tab of the Advanced options of the games launcher from Ultra to High. Alternatively try just slightly changing the value fBlockLevel0Distance=60000 in SkyrimPrefs.ini to 57000. A: Some mods are made with disregard to generating LOD or require updated rules and configs for best compatibility. This is especially true with mods modifying the walled cities. Users are asked and welcome to provide feedback to https://stepmodifications.org/forum/forum/223-shesons-dyndolod-xlodgen/ in order to get everything working with as much compatibility as possible. Include a link to the mod and screenshots (with console / form id) about issues if possible. A: Flickering textures (full and LOD model showing at the same time) in the LOD area outside the active cells in Skyrim Special Edition and Skyrim VR are caused by plugins triggering the large reference bugs as explained in ..DynDOLOD\Docs\DynDOLOD_Manual_SSE.html. Verify if the problem goes away by setting uLargeRefLODGridSize=5 in SkyrimPrefs.ini. A: In case large references are enabled in the game, make sure to generate both the DynDOLOD.esm and DynDOLOD.esp and to enable the Large Reference Fix in the DynDOLOD SkyUI MCM. See ..DynDOLOD\Docs\DynDOLOD_Manual_SSE.html A: If the problem is stuck object LOD in loaded cells, it can be caused by uLockedObjectMapLOD=32 in Skyrim.ini.

Blackreach has no map normally. You are probably using a mod that adds it. What makes you believe this has anything to do with DynDOLOD? If the load order changed, generate DynDOLOD from scratch so the highest overwrites are used to build the plugins. Read the first post what logfiles to post.

Copy and paste or upload text/INI/logiles instead of posting screenshots of text. Post the TexGen and DynDOLOD logs as explained on the first post. There is no point in doing anything else until the "Gathering grass data for object LOD" is printed into the debug log. There is no grass in that BTO, which is not surprising at this stage. Upload TexGen and DynDOLOD logs and debug logs as explained in the first post.