sheson

Moved to t he DynDOLOD 2.x thread, since you not using DynDOLOD 3 Alpha. Consider using DynDOLOD 3 Alpha instead. Use the x64 version of the tools so they do not run out of main memory.

The unofficial patch already covers some of those. However, they are not added as large references - probably also because those were done in Skyrim long before Special Edition came out - so they unload too early if large references are active in child worlds. In case of cell -17,28 the additions actually prevent automatic copying of large references into the child world cell since it is not empty anymore. I will probably undo everything the unofficial patch does in those cells just outside the walls, so that as much as possible is done automatically based on the references found in the Tamriel worldspace. Hopefully, that will have best compatibility with other mods making modifications to those areas. We'll see...

Just listing the form ids of mountain/rock references that have no representation in the Solitude child worldspace works, too.

Moved to the DynDOLOD 3 Alpha thread. Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts. See Long running time or output several GB in file size at https://dyndolod.info/FAQ. In particular, see if removing or terminating crapware installed with the graphics drivers helps. Check if there are Texconv background processes DynDOLOD might be waiting on.

Thanks. If you say most of the trees, it probably means, that the unofficial patch does not add references for all trees that happen have references/LOD in the parent worldspace. After all, the trees in Solitude not having full models is how the vanilla game was made. I suppose an appropriate solution will have to cover all trees and work regardless of the patch. If something doesn't have LOD it is typically because there is no reference for it in the parent worldspace Tamriel. Screenshots of the full models with more informative console would help. Mountains/Rocks are on the ignore list for the automatic carbon copies to the parent to avoid unnecessary conflicts. Large references make this more obvious, since where the LOD starts to show is pushed further away. The tools save the log and then debug log right after when they shutdown. Give the saving of the logs some time. Just let the tools close on their own. Otherwise there should be an error message if something prevents saving of the debug log.

Do not forget to upload the log.

I already explained the how - and thus confirmed your findings - the "Delete" rules work and why they were added for standard tree LOD generation. For standard tree LOD, which does not unload in child worldspace, this used to be the desired and expected outcome. Obviously that outcome is not desired when generating ultra tree LOD - which unloads properly. Hence my suggestion to generate ultra tree LOD without the rules. Despite my troubleshooting suggestions had no feedback from anyone so far. So the best working solution is yet undetermined. So in your case, the solution is to wait for the next version, as I have repeatably said already. It means, deleting the rules and then generating ultra tree LOD may just have the correct/desired outcome without having to do anything else. Potentially a quick and easy fix to the issue without having to wait for me to to tests and waiting for the next version. Yes, that is why I answer questions and explain how things work and why and post links etc. You are participating in an Alpha test, reporting an issue. I am suggesting a solution that might immediately rectify that issue. You do not seem to be interested having a shot at an immediate solution and no interest to report the outcome to improve the tool/configs so everyone's saves time. I prominently require users to make an effort and help with the development of the tools to improve them, including troubleshooting and reporting. This is typically done, so users can address issues without having to wait for me trying to replicate issues and to publish an update. Editable configurations and settings exist for this reason. It is impossible to know if something works or not without testing it. Without testing the outcome has not been proven. That is the scientific method that drives the development/troubleshooting. Me asking users to test or try things is the modus oprandi since inception and a requirement to use the tools in order to advance the development and compatibility. I have already explained why the rules were added: It was done because when generating standard tree LOD, the standard tree LOD does not unload in child worlds and there there will be billboards and full models showing at the same time. The fact that the references are added as IsFullLOD results in similar issues in the parent worldspace. I am not speculating why nobody noticed or reported the issues with ultra tree LOD before. Since I now have been informed that you are unable to do the troubleshooting I asked for, I have added this issue to my long list of things to do, as I said I would. I can not affirm anything until then. That means - as I already said - the next version will have an appropriate solution. I have repeatedly suggested a potential solution for the issue, awaited the success or failure report for it and promised an appropriate solution for the next version for this issue. In case having said these things in several posts didn't make it clear: This is an issue and that is why it will be fixed in the next version.

Moved to the DynDOLOD 3 Alpha thread. Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload when making posts. Do not post screenshots of messages, use the "Copy message to clipboard" and paste the text instead as explained in the first post or at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text The message is saying that Unofficial Ghosts of the Tribunal Patch.esl has a large reference entry which links to the FormID 0x0401E343, which is a reference that normally exists in Dragonborn.esm. That FormID can not be found. Typically Unofficial Ghosts of the Tribunal Patch.esl should only have that large reference entry if it overwrites the reference added by Dragonbon.esm. Use the "Click on this link for additional explanations and help for this message" to open https://dyndolod.info/Messages/Unresolved-Form-ID as explained in the first post or at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages Start by checking the plugin and record with xEdit mentioned in the Error in ... message. So, start by checking with xEdit if the plugin load order 0x04 is Dragonborn.esm. Then check if you can find the formID 0x0401E343 in it. If unresolved form ID errors happen in the latest and all updated vanilla game files (including DLC and CC), consider using the Unofficial Skyrim Legendary Edition Patch, Unofficial Skyrim Special Edition Patch and/or Unofficial Skyrim Creation Club Content Patches. Make sure the vanilla and CC game plugins are all in sync for the same game version and that the patch plugin was made for that version. The order of the 3 vanilla DLC is wrong in the modlist.txt you uploaded. Make sure the plugins are sorted properly.

So turning LOD off and then on "fixes" the outlines caused by another mod? Turning LOD off and on again does not change the LOD meshes or textures. They are still the same. Still not sure what you expect LOD generation to do about a mod causing this? Does it not happen with vanilla LOD?

From the log it seems you are using DynDOLOD.DLL 2.45 for 1.6.640 with DynDOLOD DLL SE - Scripts 2.82.5. Does that sound correct? If it does, download the DynDOLOD DLL SE - Scripts 2.82.6. You might need to do a clean save without the plugins and scripts in the load order, so the old scripts are removed. If you can repeat whatever you believe might have caused this, test if the never ending loop situation does not happen anymore.

No logs. It is unclear what LOD types were generated for which worldspace etc. Why do you believe this has anything to do with xLODGen? Does it go away when toggling LOD off with tll in console? What do you expect LOD, which is meshes and textures that show past the active cells, to do about a mod that adds a highlight around things?

If you have problems using the current version, then report them. There is no reason not to use it. I directly answered the questions what the rules are expected to do and how/why LOD for the trees is still be seen from Solitude. If the current alpha version still deletes those references because the bug does not happen for your load order, then obviously just remove the reference rules that delete those references via the advanced interface or directly from the DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. Then everything should just work with ultra tree LOD. Does it not? Does [..] removing the reference rules solve the issue for you? I am directly asking you to remove the reference rules instead of relying on the bug. Twice. Simply read the actual lines I am writing. I am asking again, what happens when you do this? If the result still is not working, it will be addressed in the next update, as I already mentioned. If you are unable to do what I am asking directly, then simply say so. Then I will add the tests to my long list of things to do. And you just need to wait for the next version for it to be resolved.

https://dyndolod.info Always use the latest version. Using the latest version and to provide feedback or to report problems is a requirement to participate in the alpha test. Do not waste time using older versions or reporting problems with older versions. Reference rules are simply supposed to do what they are documented to do: https://dyndolod.info/Help/Mesh-Mask-Reference-Rules#Dynamic-LOD-Options Delete disables original reference completely and there will not be any LOD. The vanilla game already adds the corresponding tree reference in the Tamriel worldspace, for which LOD is generated. Solitude uses the parent worldspace Tamriel for LOD. The unofficial patch adds tree references for the same positions in the child worldspace, which caused the standard tree LOD and full model to show at the same when the cells are active - when the user is close - in the child worldspace. Because they are flagged persistent and IsFullLOD, similar overlapping happens in the parent world. Hence references rules were added to delete them. In the past few years new features were added that should automatically deal better with this if the references are not deleted. If not, then a new more appropriate solution that works for both standard and ultra tree LOD will be conceived. So I ask again, does using the current version not applying the "deletions" / removing the reference rules solve the issue for you?

Read the first post which DynDOLOD log and debug log to upload when making posts. That would help determine which scripts you are actually using. If the counter goes to 0, it evaluates to false and exists the while loop.

The current alpha version has a bug, so it does not delete those references when the current unofficial patch is used. If the references are not deleted by DynDOLOD, then the full models added by the unofficial patch to the Solitude worldspace should still be visible. You know if the bug happens, if the advanced interface shows the reference rules as not resolved as I explained here already https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/?do=findComment&comment=272122. Does the bug not happen for you? If the current alpha version still deletes those references because the bug does not happen for your load order, then obviously just remove the reference rules that delete those references via the advanced interface or directly from the DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. Then everything should just work with ultra tree LOD. Does it not? As usual, always use the latest Alpha version. Whatever older versions do is irrelevant.

As I wrote, if the tree references inside Solitude are currently not "deleted" because of a bug, then I would expect ultra tree LOD generated with Alpha 128 to be better now. As I explained, that setup was made for standard tree LOD many years ago. Generate standard tree LOD instead of ultra tree LOD and test that too. I would expect the old issue of having billboard tree LOD and full model show at the same time may creep up again - or not, since additional features have been added in the past years to address that automatically. Carbon copies for IsFullLOD references in a childworld are added to the parent world or vice versa if the IsFullLOD flag is removed. The editor id will always have the plugin and form id of their source reference in them.

That post seems to have been lost on me among the other posts. If I don't reply to something in a matter of days/week just make a new post linking the old one. The issue right now is that mesh references rules that "delete" specific tree references added by the unofficial patch in Solitude are not being applied. If I interpret the screenshots correctly, the "deleting" of xx06313E etc. worked as desired, since it shows the xMarker.nif. That is done so LOD and full models do not show at the same time. Also, when in Tamriel, there is the original full model tree and the IsFullLOD tree from the unofficial patch showing at the same time. So there is two reasons to "delete" those tree references. These rules exist since a long time ago and were already made for Skyrim LE unofficial patch, IIRC even before ultra tree LOD was a thing. The automatic stuff that happens now instead might be actually better now when using ultra tree LOD.

Just load DynDOLOD, advanced mode, click low, medium or high to update rules, Check if the reference rules for the unofficial patch resolve to references by hovering the mouse pointer over them. If it just shows the filename of the rules INI, the reference was not resolved. If it was resolved, there will be second line with info from the record. Just compare to the Skyrim.esm reference rule above, they should always resolve. This worked at least up to the unofficial patch 4.25b but not anymore for some reason. Not quite sure about the cause, but it will be fixed in the next alpha.

If 0006312F (and others) is not "deleted" per the references rules, then there is a bug I will have to look into.

Persistent references are always loaded. Persistent references with IsFullLOD show also when the cells for the position of the reference are not attached. Solitude is a childworld of Tamriel and uses its SkyCell, which means persistent references with IsFullLOD show in both worldspaces either way. References in the child worlspace that have the IsFullLOD flag are being patched by DynDOLOD and a carbon copy is created in the parent worldspace, so proper working LOD can be added instead. Without TGC Solitude Fixes active, the carbon copy should not happen, if a reference already exists for the same position with the same model. Proper LOD will be added for it instead. So, in any case, if the purpose is to remove the trees, TGC Solitude Fixes needs to disable the trees in both worldspaces regardless of using DynDOLOD or not. DynDOLOD however, also has some reference rules that disable some trees added by the unofficial patch including 0006312F, 00063133 etc. since they are unnecessary, because of the IsFullLOD tree references in the childworld being patched to have proper LOD as explained above.

Did you change the Ignore= list in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_childworld_SolitudeWorld.ini so that trees in that child worldspace should have LOD in Tamriel? If TGC Solitude Fixes disables trees added by the unofficial patch to Tamriel, it should probably also disable trees with the same position in the Solitude worldspace.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots 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 pluginname_formID for the source plugin and reference.

Also see http://tes5edit.github.io/whatsnew.html#improved-language-and-codepage-support Yes, as you can see in the ignore file, the lines also contain the EditorID, Name and plugin name and the Name is being translated. I will probably change that some time so it always works. Regardless, there should be nos such error. Use the latest version. Upload the log, debug log and bugreport.txt if error happens with latest version.

In case the generated plugins end up not carrying forward localized strings correctly, refer to the xEdit documentation how to set language etc. with command line arguments like -l. See https://tes5edit.github.io/docs/2-overview.html#CommandLineSwitches and refer to xEdit docs or support by more knowledgeable people about this topic than I.

If you want to achieve the best looking Skyrim, then you should follow a proper modding guide written by author(s) that actually understand and explain how to generate LOD for the current load order. Guides that do not generate LOD for their load order are either do not care or are clueless about the issues. The reason you don't "see" a difference in quality is that you do not know what to look for, or as already mentioned, it may be primarily about consistency/matching with the entire load order properly everywhere. It is unclear what "those lods" refers to. If there are problems with the LOD patch you generated, make a proper problem report as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum You might also want to read https://dyndolod.info/How-LOD-Works as a starting point if you are interested in learning/understanding things better. xLODGen/DynDOLOD do not change how the game works, where LOD starts (generally, large reference bugs workarounds can change that on specfic occasion) or the max render distance. They generate LOD for the current load order. In case of TexGen and DynDOLOD with new and improved LOD assets.