sheson

xEdit/xLODgen/DynDOLOD print the CRC32 of plugins in the log or in xEdit in the left tree view Name column. Background Loader: [LegacyoftheDragonborn.esm] File loaded (CRC32:56140CBA) For 5.6.3 I get 5C46C844. Did you do any edits maybe?

Thanks. I was somehow under the impression it doesn't happen when you start with a clean save in/near Solitude, only when further away. I guess I am mistaken. What doesn't seem to make sense is that if something is enabled and loaded to change into disabled or unloaded state just because you are saving/loading the game. Can you enable the papyrus log, do the thing, see if there are any errors from the SHESON_DynDOLOD scripts or anything related to LegacyoftheDragonborn? Especially in the second log loading the save. What version of LegacyoftheDragonborn are you using? The CRC32 of LegacyoftheDragonborn from the log is not matching what I have for 5.6.3

That's great. Thanks for letting us know.

The reference from the screenshot is "deleted", so that tree full model should not show in the any worldspace and have no LOD. If you check the reference 6100401C (the on from the screenshot) I believe you will find it doesn't have any enable parent. Be that as it may, the log shows you are using Alpha-87. Generate LOD with Alpha-89 (install into new and empty folder), see if the problem still happens. If it does, upload log and debug log.

Can you test Dragonbridge, Morthal, Dawnstar? Maybe you can get a rough idea about the distance when it starts. What are the SkyrimPrefs.INI [MAIN] fSkyCellRefFadeDistance and [LOD] fLODFadeOutMultSkyCell settings? Copy/paste the line "reset": ... from near the bottom in DynDOLOD output skse\plugins\StorageUtilData\DynDOLOD_Tamriel_Objects.json

See the first post which log and debug to upload when making posts. Always use the latest Alpha version. DynDOLOD 3 Alpha is supposed to automatically detect trees added to the Tamriel worldspace in the areas of the walled cities and handle them automatically without having to set the enable parents in plugins or reference rules anymore. If the tree reference have enable parents set to player already then they should not have tree LOD anyhow. What plugin is setting the enable parent for the tree in your load order for the tree from the screenshot though? When I check Perfecter Whiterun.esp xx00401C in xEdit it doesn't have one. Though it should not need one with DynDOLOD 3 Alpha-89.

Test how things turn with this version of LODGenx64.exe https://mega.nz/file/9cxUjLyT#Mh6aK_lVKCuQpNYmFghj3IgRNMXHb2W7nt0WcQLUseA

My initial idea would be there was not enough time spend outside for all things to settle before you went inside again. Have you tried what happens if you do this without the new DynDOLOD active? E.g. is the guild house working properly with the clean save? What happens if you do this in Whiterun instead?

As expected, the first line of the log shows an older DynDOLOD Standalone version is being used: DynDOLOD 3.0 Alpha-88 x64 - Skyrim Special Edition (SSE) (C973144D) starting session 2022-05-07 16:50:43 As explained, always use the latest version of DynDOLOD Standalone 3 Alpha with the latest version of DynDOLOD Resources SE Alpha. Really follow the installation instructions. https://dyndolod.info/Installation-Instructions, especially this: Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\. Remove old version first, do not unpack over old version. Always unpack into new and empty folder.

Read the first post which log and debug log to upload when making posts. Use "Copy this message to clipboard" and paste the entire message as explained on the first post. Click on "Click on this link for additional explanations and help for this message" which should open https://dyndolod.info/Help/DynDOLOD-Resources, check its Troubleshooting section. Really follow the installation instructions. https://dyndolod.info/Installation-Instructions, especially this: Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\. The log will most likely show an older DynDOLOD Standalone version is being used.

Ah right, the problem was that the debug log was already replaced and doesn't contain the generation anymore. Please upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Tree_Report.txt and DynDOLOD_SSE_Object_Report.txt If you have the time, check if there is any difference with DynDOLOD 3 Alpha-89. In case it still happens, upload that debug log.

Just added this to https://dyndolod.info/Help/Grass-LOD In case the grass cache is used with runtime version 1.6.x and the *.CGID files have been renamed to *.GID, set GrassGID=gid in the ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini. This requires all *.GID to be of the valid data format, otherwise there will be Error reading grass [worldspace] [x,y] / Error processing grass data *.CGID Unable to read beyond the end of the stream as explained below. This is to avoid having to keep both the same CGID and GID files in the load order or having to rename them back and forth. Note that NGIO can not read CGID from BSA. This only works with the engine natively loading GID. DynDOLOD/LODGen read anything from BSA.

I just opened the edit function to update the page on the website. Check it back in a while. https://dyndolod.info/Mods/Base-Object-Swapper It means, DynDOLOD now supports the Pos[A|R], Rot[A|R], Scale setting as well as the [Form|Location/Cell_FormID|Location/Cell_EditorID]. If any of the tranforms is random, the reference is ignored for LOD. "Principle support" means it needs testing with real mods utilizing the features and there might be bugs.

The form id is just a tree, which should not cause any problems with references placing glow meshes. Seem the broken plugin was removed for a reason. See if "fixing" the HITMEs as already suggest makes a difference. https://dyndolod.info/Messages/Internal-File-FormID-Is-A-HITME If not, generate LOD from scratch with the fixed plugin to see if that helps. If that does not change anything, it is possible it selects a tree instead of the reference with the glow mesh when clicking with console open. Install More Informative Console to help finding the correct form id for the glow mesh. We would expect the NIF to have a name containing "glow" or "fx" for example. If the glow can be seen when outside of Whiterun, use tcl in console to get near it to select it via console to get its form ID. Test generating with "Fake lights child worlds" unchecked. If that help, then it means disabling dynamic LOD objects just takes longer than usual and increasing the time to fade-in from black would be the option to use in case you want to have LOD with those fake lights.

If the process stops with a proper message that explains the cause of the error, then it is not crashing. If the message has a link "Click on this link for additional explanations and help for this message", then click it to open further explanations and help as explained on the first post. Unresolved form ids will cause CTD in the game (the game closes without telling you what the problem is) Do not "delete" base records. To remove objects like trees, "delete" the references, clean the plugin with xEdit afterwards. Alternatively define a different model on the base record or replace the model NIF. Could be an "empty" dummy NIF with just the BSFadeNode. If further help is required with a message, use the "Copy this message to clipboard" to copy and paste the text when making reports as explained in the first post. Also upload the log and debug log as explained in the first post.

OK. Do you know which plugin has the load order hex 20 when you are in the game? (The first two digits of the form id?) Either check MO2 right plugin list or load entire load order into xEdit to see which plugin starts has [20] in from of it. Then enter the form id into the FormID field top left and hit Enter key to bring it up the reference in the right window to verify you got the right plugin. The order can change, so in case that there is a problem identifying it, best to install More Informative Console, which will show it right in the game with console open. When you say "flash" does it mean the glow changes intensity briefly? In that case setting a slightly longer time for fade-in from black might help to cover up the delayed disabling of FXGlow LOD. See https://dyndolod.info/Help/Mod-Configuration-Menu#Settings In that case don't worry about finding the plugin/form id. You should look into fixing the HITMEs https://dyndolod.info/Messages/Internal-File-FormID-Is-A-HITME

Read the first post which log and debug log to upload. When making screenshots of things in the game, open console and click the object in question to show its reference form ID. Use More Informative Console to show additional information. If the form ID points to a DynDOLOD plugin, load the plugin into xEdit and look up the reference. Take note of the Editor ID, which is typically of the format plugniname_formID for the source plugin and reference.

What DynDOLOD Alpha version are you using? If that happens with the latest Alpha, then upload the log and debug for the generation of the problematic results as requested. A threshold of one is/should not a problem with the current version. There should be no need to manually edit anything.

Thanks. Not quite sure why that causes the problem in use problem you have, though flag overwrite and the change to the reference are not really necessary in this case. That will be fixed in the next Alpha version. To fix your problem right now without having to wait for the next Alpha, remove both overwrite records 0009C6CE and 03007685 form the DynDOLOD.esp. The config file setting should force creation regardless of anything else.

Read the first post of the DynDOLOD 3 Alpha thread where to make post. I moved your post. Read the first post which log and debug log to upload when making posts. https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards TexGen determines which trees and grasses should have tree/grass LOD billboards automatically created for them based on the model volume and height. A tree is every base record of the type 'TREE' and 'STAT' with the 'Has Tree LOD' flag set. Grass is every base record of the type 'GRAS'. in addition, for TREE base records either the model filename needs to have "tree" in the file path or also have the HasTreeLOD flag set. The debug log should contain some information for every TREE and GRAS and flagged STAT base record that was looked at. That information might help to determine why something was skipped and set to False in the created [Tree|Grass]_Billboards.txt. So if you have TREE base records that are plants and thus do not have "tree" anywhere in the file path, set the HasTreeLOD flag for automatic discovery. Forcing it with via config file might be easier. Provide one example form id of a base record in question and more detail in case more help is required.

Read the first post which log and debug log to upload when making posts. Make a screenshot with console open that also shows the ref form id of the object in question. Check in xEdit if there are any plugins overwriting 0009C6CE and let me know.

Note that DynDOLOD 3 is still an Alpha test. See https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-88/ Step by step guide how to install: https://dyndolod.info/Installation-Instructions Step by step guide how to run TexGen and DynDOLOD: https://dyndolod.info/Generation-Instructions Advanced options explanations: https://dyndolod.info/Help/Advanced-Mode Underside explanations: https://dyndolod.info/Help/Terrain-Underside Grass LOD explanations: https://dyndolod.info/Help/Grass-LOD The DynDOLOD documentation is load order and mod manager agnostic as it explains how the tools and the technical stuff works. It is a technical manual. As such it does not have goal oriented guides for entire load orders like comprehensive modding guides.

It wasn't that particular hard in this case, since it's a console program that mostly reads/writes binary files and does some "math" in between and none of that needs changes. Both versions are compiled from same source. Next Alpha version will silently check if the new version works (e.g. is Net 6 runtime installed) and use net48 in case it isn't.

See this post https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-88/?do=findComment&comment=259371 It worked for the other users.

That's most likely because of different threadsplit defaults. Though long running generations with 3D tree LOD or grass LOD could be a couple minutes faster because of micro optimizations.