sheson

If you have identified a plugin other than the bashed patch causing problems, please let me know their name so I can check them as well. If there are errors with bashed patch in the load order, it usually means the bashed patch has errors. Check it with xEdit and fix the errors or use a different wrye bash version to create a patch without errors. The exceptions in TexGen/DynDOLOD seem related to plugin files access. There could be something with hardware, software, OS interfering with file reading/access. Try the 32 bit versions of TexGen/DynDOLOD. If you are using MO, check its log. Test outside of MO. Just with the vanilla game or maybe install one or two (problematic) mod. Either make backup of data folder first, or take note of which files are installed so you can remove them later. If the mod is just a esp/bsa it is simple enough to do.

You have no problem using the dropdowns and option in TexGen? What windows version is that? Multi monitor setup, move to different screen, restart, no change?

The LOD trees should be about the right automatically if you installed Skysight - Simply Bigger Tree Billboards after the vanilla billboards and then generated tree LOD. Skyrim bigger trees just scales the trees via values in the plugin and that scaling affects both the full model and the tree LOD when it is generated. However, the larger the scaling the more the imperfections of slightly incorrect width/height of the billboards might be noticeable. If just the height needs adjusting then raise the height value. If the LOD tree appears overall small in width and height, then either raise both width/height or use scale, which will make a tree bigger in all directions. While you are working on this, just generate tree LOD to test it, uncheck the static and dynamic LOD to save time.

You should install the required vanilla billboards. Unless they are installed and DynDOLOD is prevented reading the files. Check if antivirus or windows prevents DynDOLOD from reading/creating any new files. It could also be the reason for the other error.

This error still has me scratching my head a bit. I will need to put together another test version with some more updates included for you to try. I hope to do it in the next couple days. If you have time and want to try test a few things in the meantime. Start DynDOLOD while holding the shift key, so all settings reset. Alternatively delete c:\Users\[user name]\AppData\Local\Skyrim Special Edition\DynDOLOD_settings.ini Make a new MO2 profile and test only with the vanilla files. If that works, then add batches of plugins to see if you can narrow it down to a single plugin. I would be interested in the results either way.

FO4LODGen by Ehamloptiran, Zilav and Sheson Static objects LOD generator tool for Fallout 4 After one and a half years, Zilav and I finally managed to incorporate FO4LODGen fully into the latest xEdit.exe builds posted to WIPz TES5Edit on Afk mods. However, get the latest xLODGen - beta with terrain LOD, this is were the most recent LOD development happens. Users of xEdit and FO3LODGen/FNVLODGen/TES5LODGen/SSELODGen will feel right at home. After downloading and extracting the archive rename executable to FO4LODGen.exe or FO4LODGenx64.exe Start FO4LODGen.exe with the command line parameter -o:"c:\Output" to set the output folder. This will make it easier to create BA2 archives, to avoid blurry textures because of loose texture files. I assume Fallout 4 modders know all about this issue with loose texture files, the involved INI settings and ENBoost. Hover over the options of the FO4LODGen window to see hints what each setting does. If a texture atlas is not created it will use the vanilla texture atlas (Commonwealth and SanctuaryHillsWorld are supported atm, ping me if DLC worldspaces are required) if possible and single LOD textures if not. I created a FO4LODGen Resources 1.2 (Mega) archive, to improve the generated LOD. While it is not required to generate object LOD, I recommend using the FO4LODGen.esp and the FO4LODGen - Main.ba2 for better results. Refer to the included docs/ReadMe.txt file to learn what each of the plugins do. The plugins can be merged, but make sure to keep a the name FO4LODGen.esp in the load order so that the FO4LODGen - Main.ba2 is loaded when starting FO4LODGen.exe. Check the log to make sure the BA2 is loaded. There is no hard requirement for the plugins that define unused LOD models and the FO4LODGen - Main.ba2 to be loaded in the game. However, if you notice flickering LOD textures or other odd behavior keep them in the load order. Let us know if this happened so we can update the instructions. The FO4LODGen-DLCCoast-WindTurbines.esp is just a bonus plugin and has nothing to do with LOD generation. All tree LOD in Fallout 4 is done as object static LOD, so 3D models are required instead of billboards. Even without the FO4LODGen Resources and no plugins changing the worldspaces, FO4LODGen already improves vanilla LOD. Tree LOD models use a feature called "double sided", which the vanilla LOD does not support. In vanilla this means the opposite side of branches are invisible. See below screenshots. Please test and post results so we can work out any kinks before official release. "Use backlight power"

See https://forum.step-project.com/topic/12231-exception-in-unit-userscript-line-322-duplicate-formid-00009389-in-file-86-dyndolodesp/

Replace ..\DynDOLOD\Edit Scripts\DynDOLOD Worlds.pas from the test with this version See if it gets any further at all and prints a list of plugins to the log and may even start the options window. It will most likely crash later, see how far it can get. Let me know the error message and especially the line # of "Exception in unit xxx line" xxx may be probably "userscript" but could be something else.

The same Skyrim.esm can not give different results for the same command used by both applications. They must be each loading a different Skyrim.esm. Compare line #458 in ..\DynDOLOD\Edit Scripts\DynDOLOD TexGen.pas to line # 500 in ..\DynDOLOD\Edit Scripts\DynDOLOD Worlds.pas. My guess would be one application is started with a command line parameter and the other isn't or a different one. Or different profiles in MO. Check the log for "Using Skyrim Data Path", second line usually.

DynDOLOD and TexGen check for a record in Skyrim.esm that is unique to Enderal. The Skyrim.esm presented to DynDOLOD/TexGen has to be from Enderal, as no other Skyrim.esm contains worldspace "Vyn" with the exact same form id. I suggest to look at the first few lines of the log that show which data path, ini and and plugin list are currently used. Unless the game path is defined as command line parameter -D: "c:\path\to\Skryim\data" it is looked up in the registry, of course. Every tool has to do it that way or prompt the user for it. Run the games launcher to update the information in the registry.

See if this test version https://forum.step-project.com/topic/11997-dynamic-distant-objects-lod-dyndolod-226/page-12?do=findComment&comment=203874 works any better. if not, in xEdit, apply the script "List loaded plugins and their masters.pas" Post results.

Delete or truncate the logfiles containing everything old, then start the applications once so only the most recent messages are logged. Use pastebin or a file upload service.

Check the load order for errors in xEdit and fix what is possible. Then post the log from xEdit loading ..\xEdit\SSEEdit_log.txt without error and DynDOLOD loading ..\DynDOLOD\Logs\DynDOLOD_SSE_log.txt with error so we can compare

See if you can load the load order in xEdit.

Check the Generate tree LOD checkbox. If the problem persists, post the entire log.

1. If the plugin changes landscape/terrain, especially the terrain height, then you should generate terrain LOD with either CK or OscapexLODGen. Oscape may produce buggy terrain meshes with sheer drops in height. If that is the case try to EMSify the plugin just for generation. Once terrain LOD is generated, just pick the Data\Meshes\terrain\tamriel\tamriel.*.btr and Data\Textures\terrain\tamriel\tamriel.*.dds from the area of your house (CK offers generating specific chunks I believe to save some time). For terrain LOD, I would only include LOD level 4 and maybe 8, as 16/32 affect a much larger area and the map, which is probably not needed. To include object LOD, either use CK or xLODGen. DynDOLOD is intended to generate LOD for entire worldspaces. I will talk about both xLODGen and CK, but first we need to talk about the object LOD texture atlas. Before generating object LOD with CK/xLODGen I suggest to install the fixed vanilla "data" from Skyrim Vanilla LOD Source Files v2.5 - no need for the "source" folder if generating LOD with xLODGen/DynDOLOD. DynDOLOD has the same fixes included, so there is no need for it, but in case it is installed, DynDOLOD Resources should overwrite it. The problem with including object LOD for only a small area is, that it needs to either use the vanilla object LOD texture atlas, or its own atlas with a unique file name in order to be compatible with other mods. The object LOD BTO meshes support pointing to a different atlas texture. xLODGen/DynDOLOD both use a distinctive file name, which is different from vanilla. So, mixing only parts of their object LOD with vanilla object LOD is possible. Though, again, if you have another mod that tries to do the same, problems occur, as it would use the same unique filename from xLODGen, but the content will most likely be different. xLODGen tries to use a custom atlas definition file (Edit Scripts\[game mode]-AtlasMap-[worldspace].txt, so for example Edit Scripts\TES5-AtlasMap-Tamriel.txt), when the option to build the texture atlas is not checked. This can be used to either generate object LOD that uses the vanilla atlas (I have yet to make the file for the vanilla atlas for TES5, for SSE they are already included in latest xEdit), or generate object LOD with a unique atlas texture file name of your choosing. When you generate LOD with xLODGen and the atlas build option is checked, afterwards there will be a Edit Scripts\LODGenAtlasMap.txt for the last generation. In order for future LOD generations to reuse the same atlas map file, rename LODGenAtlasMap.txt to TES5-AtlasMap-Tamriel.txt. To generate object LOD that use a unique atlas texture file name that only belongs to your mod, open the file in notepad and search and replace all occurrences of textures\terrain\[worldspace]\Objects\[worldspace]ObjectsLOD.dds, so for example from textures\terrain\Tamriel\Objects\TamrielObjectsLOD.dds to textures\terrain\Tamriel\Objects\MyAwesome-MOD-LOD-Atlas-Tamriel.dds. Then also rename the files in textures\terrain\[worldsapce]\objects\*.dds to match of course. Now each new generation with build atlas not checked will use that atlas map file. I will try to create the vanilla atlas map files some time soon. If using CK, you are forced to only create LOD that uses the vanilla texture atlas (which happens automatically if no new LOD models define new LOD textures), unless you want to replace the object LOD of the entire worldspace. In order for CK object LOD generation to create compatible object LOD, you always need to create object LOD for the entire worldspace. If you generate only specific chunks with CK, the generated texture atlas will only contain LOD textures that are used in these chunks. In any case, visually compare the generated atlas texture with the vanilla atlas texture, to make sure they match exactly. If any texture position is off or missing, the texture atlas does not match and you will not be able to mix your LOD BTO files with vanilla LOD BTO files without either LOD having the wrong textures. For CK to be able to generate object LOD, you need to install the "source" folder with the TGA textures from Skyrim Vanilla LOD Source Files v2.5. Once you generated object LOD with CK/xLODGen just include the BTO LOD meshes of the area the mod changes and discard the others. 2. If the base record for the house already has LOD models defined, then nothing else needs to be done for xLODGen/DynDOLOD compatibility. Disclaimer, there is a chance I am describing features of xEdit/xLODGen not available in the latest download. In case something doesn't work as described let me know. If you need more detailed instructions how to actually use the tools, let me know.

TES5LODGen replaces CK tree and object LOD generation and makes it easier. From now on I will refer to xLODGen - which will mean the latest version of xEdit.exe either renamed to TES5LODGen.exe or SSELODGen.exe. For LOD generation with either CK/xLODGen the base record of the references needs to define LOD models for the different LOD levels in order for the reference to get a LOD representation when LOD is generated. The base record also needs to have the Has Distand LOD flag set. Note that Skyrim (CK/xLODGen/DynDOLOD) does not use LOD level 3 (LOD32) for object LOD, so no need to define that slot, but it doesn't hurt either. For DynDOLOD, the defined LOD levels are only a fallback. It first tries to match LOD models to objects based on their full model filename, second it tries to match mesh rules and third uses defined LOD levels. How all that works, is explained in DynDOLOD_Mod_Authors.html. So if you care about the mod working with xLODGen generation, you need to make sure the LOD levels are defined on the base records. This also works for DynDOLOD, but it will prefer filename and rule matching. If you want to include any pre-made LOD in a mod, there are quite a few things to consider, but I am not sure if that is what you want, or just make sure the mod works with xLODGen/DynDOLOD.

Great. The DynDOLOD log will also have messages about missing nifs that you can use to cross check.

Correct, the persistent cells of Tamriel and the child worlds load the moment when you enter Tamriel or any of the child worlds. Maybe whatever the cause exists in both wordspaces, or things other than references (navmeshes maybe, I don't know much about them) are shared across child and parent world. Maybe it is about something that only loads when the area becomes active, regardless of worldspace. I usually only deal with simple references and LOD, not with NPC, Quests etc so i can't say much about that. If the crash is that repeatable, it could be quick to narrow down. To troubleshoot, consequently remove everything that does not cause the crash until you are only left with the thing(s) that causes it. So, remove every mod and plugin that is not near the problematic area, while the the crash still happens, keep removing plugins changing the area one by one. If the crash goes away, enable the plugin again and remove another. Once you are left with only vanilla DLC and one plugin and still have the crash, use xEdit to remove worldspaces, then entire cells, then the content of the last remaining cell. The 50:50 approach works well. Remove 1/2 of data. If crash went away, go back one step and remove the other half and so on. The goal is to keep the data/record that causes the crash, until nothing else is left.

It loads the tempoary cells that are defined in the Tamriel worldspace. AFAIK the temporary cells defined to the child worldspace with the same coordinates do not matter at this point. The temporary cells of the child worldspace are only loaded when entering the child worldspace, superseding the temporary cells of the Tamriel parent worldspace. The persistent cells of all child worldspaces are always loaded together with the persistent cell of the parent worldspace. They seem to act like one and the same. Crash fixes is not reporting a problem with a nif? Then maybe a deleted record or a navemesh problem. If the crash is that reproducible, you should be able to determine the coordinates of a handful of cells that attach when the CTD occurs. Find them in xEdit with CTRL+SHIFT+F cell finder, then have a look at plugins that change them. Remove those one by one. Once you found a plugin, you could have a look at the references and other records in those cells, or the overwrite cell record themselves. You get the idea. Only if all that fails to find something would I consider looking at the cells in the childworldspace, however unlikely it seems. I would still check, because more often than not, these things are not always what one believes them to be...

Yes, the worldspace is so small that all that generating LOD for it is just creating extra data and stuff that is not needed. It is not really bad if its there, but there is no point really, so it is dead weight. Less dead weight is always better.

This is a problem in DynDOLOD with a rare occurrence of a cell record not existing (I am not sure if CK can create that circumstance, but it seems totally legit otherwise). Will be fixed next version. It just so happens that it is better for this worldspace to not generate dynamic LOD (because of all that lava) and that static LOD will not really improve / doesn't matter either since the island is so small. So I recommend to just ignore that worldspace. Simply do not check it when generating LOD, it will save you from the issue and you do not really miss anything either.

I will get the mod and do some tests and post again with my findings.

Great to hear. You are welcome. I can not play without it either :)

See if it goes through without a problem with summersetisles.esp disabled or the worldspace "WastesOfOblivion" not selected. Which version of summersetisles.esp is that?