sheson

If a file does not exist or if the OS, UAC, antivir blocks programs from access, it does not matter how the program is started. Note that we do not know if MO2 is being blocked from virtually putting the plugins.txt there or if DynDOLOD is prevented from accessing it. You should have similar issues with other tools trying to use that file to get the plugin list. Like when using xEdit for cleaning for example. Basically every modding guide starts with explanations and instructions about not and installing the game into Program Files x86 and how to move it. This most likely is not directly affecting the plugins.txt file not existing where it should or programs being blocked from accessing it.

C:\Users\[username]\AppData\Local\Skyrim Special Edition\Plugins.txt is the standard location the game stores/expects the plugin list. When starting programs from MO2, MO2 substitutes that file with the version from its profile folder. If the OS tells a program that a file does not exist, it either does not exist or access is prevented by the OS, UAC, antivir etc. Best not to install the game (or any modding tools for that matter) into special Windows folder like Program Files x86

The trunk NIF folder should be in the data folder as already discussed and ship with the mod. The trunk output folder is then part of a normal TexGen run and should be installed in the data folder and ship with the mod. Users will be able to update these when running TexGen themselves. The example uses the trunk billboards for input while they are still in the TexGen output folder, so hybrid generation example works without installing the TexGen output. The crown input folder can be anywhere you like (but not in the data folder) and should not ship with the mod. DynDOLOD itself is not using the crown input in its standalone folders. They are only used when running hyprid.bat to build the 3D tree LOD models with the trunks. If the cowns are in the data folder they risk being used for 3D tree LOD instead of the hybrids because they have the same file name. And as I keep preaching, by Bethesda own convention, there are never two files with the same filename in different folders to avoid mixups. The output generated by hybrid.bat / LODGen are the 3D LOD trees to be put into the data folder and ship with the mod. If the relative paths seem confusing, just use rooted ones. The relatives paths are just so the included examples work. Same for using the TexGen output path instead of the data path. Users should not need to run hyrbid.bat to merge crowns with trunks. Ship the trunk NIF and billboards and the final hybrid 3D LOD trees. The crowns NIF which are now copied 1:1 into the hybrid tree LOD model serve no further purpose.

Yes, please follow what I wrote in the manual. I wrote that with more care.

If a tree does not use a vanilla trunk, create a trunk NIF from the full model for it. Then rename it as usual with the CRC32 of the full model and _trunk as explained in DynDOLOD_CreateHybrid.html. See ..\DynDOLOD\Edit Scripts\DynDOLOD\Render\Billboards\DynDOLOD\lod\trees\sbt\ folder as example. Put the new trunk NIF into ..\data\DynDOLOD\Render\Billboards\SFO\*.nif and ship it with the mod. Every time TexGen is run with the Rendered option checked, the trunks billboard textures will be updated with the current textures and TexGen options. Billboards do not need to be power of two as they are never used directly. They are made multiple of 4, so they can have BC7 compression. Not generating trunks in TexGen simply means trunk billboard textures that are included in DynDOLOD Resources or in a mod are not being updated/overwritten for the current load order or with non default TexGen settings. That is fine if none of the full textures are changed.

xLODGen is a tool mode of xEdit. xLODGen terrain LOD beta is the latest version where LOD generation is tested. DynDOLOD is an advanced and easier version of xLODGen for improved tree and object LOD generation for Skyrim. Read the xLODGen terrain LOD beta thread and the readme included in its download archive for basic instructions and information how to generate terrain LOD. > I believe xLODGen64.exe should be integrated with MO2? Every tool that needs to see the current load order needs to be started from MO2. Consider following a modding guide that explains basic modding principles and how MO2 works. >And I'm using DynDOLOD downloaded from Nexus, should I have some other version? DynDOLOD has version numbers. Use either the latest release or the latest alpha version. The primary download links here link to Nexus downloads. Since the goal seems to be generating occlusion with xLODGen nothing changes in regards to DynDOLOD. >Also, should we disable pre-generated LODs by other mods when generating our specific landscape with SSELODGen? Like, for Majestic Mountains, Terrain LOD Redone, Enhanced Landscapes and EVT, HD LODs Textures? I have all listed. Follow the instructions. Do not invent steps that are not part of the instructions, as the instructions do not include the million things that do not need to be done. The vanilla game include pre-generated LODs. No they do not need to be removed. These tools generate them and overwrite them when following the instructions. >I downloaded the file SSE-Terrain-Tamriel-Extend.esm, do I need only that when generating landscape? Do I install it like a mod in MO2 or just put it manually in Data folder? I think I read somewhere that it should be removed after generating landscape. Or after generating Occlusion? Tools do not care about mod managers, only that the plugins or assets can be read from the load order. How they get there is your decision. From the first post of xLODGen terrain LOD beta right under the download links for the terrain plugin: "Only required to be loaded when generating terrain LOD." These tools and their use require rudimentary modding knowledge. The 3 LOD types and the occlusion data require to be generated in a sequence, that is all there is to it. The basic steps are: unpack tools, install requirements as instructed, run the tools from mod manager, remove requirements as instructed, install output as a mod. Terrain LOD, TexGen, DynDOLOD, Occlusion. As explained in the first post or the DynDOLOD manual, the occlusion can also be generated into the DynDOLOD plugins, saving one step. Follow a modding guide if you require instructions to be all in one place.

We are only onto something if this time a bugreport.txt was created for the exception and you upload it.

Read the first post. Read what log files to upload when making posts. Check the TexGen log if there are any errors. Check the billboard preview to see if the billboards look OK. Check the generated billboards textures in an image viewer. Check the generated object LOD texture atlas in an image viewer. Check/test different grass brightness top/bottom settings.

The setting fLODFadeOutMultObjects has nothing to do with static LOD outside the load cells. I obviously mean the settings for object LOD as explained in the DynDOLOD manual, under [Terrain Manager] fBlock* in SkyimPrefs.INI, which can be changed in the DynDOLOD SkyUI MCM settings page. If the BTO are fine checking them in NifSkope, then generating different BTO that are also fine is not going to change anything. Make sure you run the tools in the right game mode, so the generated meshes have the correct NIF version.

Download this version of xLODGenx64.exe, select only the worldspace you had the error in and only select to generate the terrain LOD diffuse/normal textures, no need for the meshes. If the error happens again, it will hopefully save a bugreport.txt. Upload that if it does.

Check the object LOD distance settings, obviously. Disable or change settings of SSE FPS Stabilizer.

Check the log above for error or warning messages. If making posts, post/upload the entire log.

From the DynDOLOD FAQ Q: 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 . 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. As you can see by the last FAQ answer, this is already a well known/documented cause for this type of problem issue. COC in itself is fine, it is not really different from fast travel.

The snow/ash LOD shader identifiers are always applied to all LOD levels for a reference. If you want LOD shaders and full model shaders to match exactly, the LOD and full model shaders need to have the exact same settings, and the model and textures need to be the same as well. Typically the LOD level 0 mountains use the full texture. Having only two snow LOD shaders and two ash LOD shaders available limits what is actually feasible.

As you wrote MM has a LOD pack, which replaces the vanilla LOD models and some object LOD textures for mountains, including pre-rendered ones that can not be currently generated automatically. Make sure they are installed correctly when generating LOD. They typically used to be fine. If you do not have this problem with the vanilla LOD models/textures, then check with the author of MM about it. The LOD model and texture have an effect on the snow LOD shaders. The snow LOD shaders which are applied to object LOD are the material object shaders with the form id 006AE38 ("SnowLODMaterialHD") for the nearest LOD mountains that use the full mountain texture and the form id 00050372 ("SnowLODMaterial") for the further LOD mountains that use the pre-rendered object LOD textures. The shaders are applied "live" in the game. Whatever plugin is the last to overwrite these shader records wins and is responsible for the final result of how this snow cover looks. Not generating LOD for something means, something won't have any LOD. As you can see from above, the used LOD generator does not matter, it is all in the LOD assets and other plugins modifying LOD related records.

What makes you believe this has anything to do with DynDOLOD? The worldspace has no lodsettings file. That is probably because it is very small. So, the screenshots are most likely showing full models. Make sure to stay under the max plugin limit.

Are you sure there is no bugreport.txt in the same folder the exe files are? Can you pinpoint at what operation of the process it was closed? If not, consider testing for memory errors or maybe check the Windows DEP setting, anti vir etc. Consider moving the game out of Program Files x86.

Ah just the everyday Exception code: 0xc0000005, which could be anything really. Did it ever happen again, can you reproduce it?

Read the error message. Pay attention to "MajesticMountains.esp might be the wrong version" and "Error in MajesticBrumaMountains.esp" Fix the unresolved error. Click onto the link "Help for this message" to open further explanations for the message. https://dyndolod.info/Messages/Unresolved-Form-ID

I a program is being terminated like without an exception it is typically because of something outside of a program code error, like memory, overclocking, error etc. There might be something in the Windows event log.

Are you saying it quit without saving any log files or a bugreport? Code: 0 has always been the last line of the LODgen logs when everything went well.

xLODGen beta 77 - based on 4.1.3f - added FO3/FNV double sided support There is a new check box that allows to support the double sided option. If one or more double sided LOD models are in a LOD quad (the 4x4 cell area a BTO covers), the entire super mesh is set as double sided. Remember, for FO3/FNV object LOD only can have a single shape, so the entire LOD quad shares the same shader settings. Enabling this option can cause z-fighting for existing LOD models that have both sides of a surface done as normal single does and are close to each other. So, for the feature to be useful some LOD models might require updating to fix these visual issues by removing one of the single sides for example. If done consequently, it could help to reduce overall triangle count.

Great. All that documentation grows organically over the years, so it is not a big deal to direct people to the right parts for the right piece of information.

Also works for me with those exact settings. Can you replicate it at the same cell, same time? You have any texture replacers that do not show a plugin in the log? If this is because of some (multithreading) code, I might have changed it in the latest beta version 77 I just posted. See if it still happens with that version.

Yes you did. Read the first post. Especially the part about which log files to post. Old and new billboard texture and text file generation is explained in great detail in the included documents.