sheson

Excuse me? You have one post. This seems to be the first time this issue is brought up here. If you have a problem with a tool like MO, in that it reports that it installed something successfully that then doesn't work for you, I suggest to ask for help in the appropriate forums for the MO version you are using. It might help to realize, that despite the messages about script/interface folders the installation of DynDOLOD Resource SE works for everybody else with MO since many months. If nobody has a such a problems, nobody is posting about that problem and nobody requires a fix. DynDOLOD, just like the game or xEdit reads the current mod list from C:\Users\[user name]\AppData\Local\Skyrim Special Edition\Plugins.txt This can be verified in the log ("Using plugin list ..."). Use a mod manager that correctly updates this file with the current mod list. Typically MO does that. It seems you have a problem with a third party tool. Also check the data path is discovered ("Using Skyrim Special Edition Data Path..."). If things are off start the game through its launcher once so settings are written to the required places. You seem to have an installation and setup problem with a third party tool. You seem to believe you are entitled to help for free tools that are released as-is. You are mad because there has been no past discussions about your problem? I suggest to put aside emotions and attitude, it usually helps with looking at things more logically like discovering the root cause of problems instead of symptoms. There is an entire section of a forum that I can be reached at because Nexus is not a good platform. However it is intended to discuss DynDOLOD and LOD related things. Not providing help with third party tools. The reported problems seem entirely about MO alone. If MO reports something as "Installation successful" and then doesn't work as expected, it seems like a strong hint to look at MO. the DynDOLOD Resources SE is a simple archive with a FOMOD installer. Seems it worked and was installed as intended.

Please post the log(s). Also not sure what "32 bit texgen simply does not work it refuses to read the master files" means. Post those logs as well. We know this error is limited to x64 version. It is related to the (alternative) memory manager, which appears to be fine in x86. The last plugin that is loaded the moment the first exceptions happens is not necessarily the cause - if it all. You could also try just reordering plugins. For example, try to move the plugin that loaded before the one in which the first exception happens to load much earlier.

Whenever there is something available I post about it.

What is the relationship to the "Load Order messed up" error message of this thread? TexGen and DynDOLOD generally both work without problem in MO.

If the user set TreeFullFallBack=1 in the ini, then it is not only looking for billboards but also for full models to fall back on for the required LOD level. In that case, if the the entire tree group (base record) has no LOD in that LOD level, then maybe the full model can not be read/used by LODGen for whatever reason. Check the export file ..DynDOLOD\Edit Scripts\Export\LODGen_SSE_Tamriel.txt for the full nif name and then check the next 3 tabs (LOD4/8/16) defining either a nif (full or 3D LOD) or a billboard dds filenames. If you can not find the tree group mentioned at all, then it couldn't match any assets. Double check the LOD4 tab for which nif file is mentioned there and if it exists. I would expect that LOD8/16 should always have a billboard dds, unless you changed the tree rule. BTW if EVT can not find its own matching 3D LOD models (srg_tree*), then either its required assets are not installed, or may be the Skyrim SE version is not fully converted yet. In that case use the Skryim version. For performance reasons you really want to use 3D LOD models over of full models. >I ran it with TreeFullFallBack set back to 0. No change. What did not change? The message did not change that it is falling back to billboards? In that case test with 2.26 or 2.27 maybe something happened to the code. Did you generate traditional tree LOD once to check for the billboard found/not found messages? In case of "new tree" (a new full model filename added/replaced by a mod) it should only fall back to full model if a billboard exists. Otherwise everything TREE would have full model LODs.

If a tree has no LOD - 3D or billboard - the reasons I can think of are pretty straight forward and simple to check: 1) There is no LOD resource for that tree - 3D or billboard. All trees of this base record will have no LOD. When generating traditional tree LOD, the log will tell you which tree records have no billboard. When generating 3D LOD and a matching 3D LOD tree is not found it will print a line like "Tree replaced, looking for 3D LOD [...] using billboard instead" - so again, if the tree has no LOD at all, the billboard is missing in addition to 3D LOD version. So whatever guide you use, 3D LOD or not, the required billboards are not installed. 2) A tree reference has settings like the XESP Enable Parent or Is Initially Disabled flag that prevents this particular tree to have tree or static LOD generated for it. Applies to Skyrim SE or if "Generate DynDOLOD" is not checked for Skyrim. Click on full model, get form id, check in xEdit. 3) LOD was not yet generated for this load order or the generated LOD is not installed yet.

It is up to users to decide exactly which tree uses which full model from which mod. Obviously then each full model should have a matching 3D LOD tree and a matching billboard. I can't really make any recommendations which single tree should be from which tree mods - as long a well matching 3D LOD tree and billboard exists, this comes down to personal preference. That is really all there is to it. If entire types of trees (base records) pop into existence, its missing 3D LOD model and billboard must be missing, both will be reported in the log. If specific tree references pop into existence, it is because they require dynamic LOD which doesn't exist yet. Set the Is Full LOD flag on those trees if "LOD" is desired for them. That can either be done manually or with rules.

https://forum.step-project.com/topic/12504-any-plans-to-incorporate-terrain-lod-generation-in-dyndolod/

I will see if I can replicate with that load order. Also test with DynDOLOD.exe. Then test with latest version 2.31, also both exe versions. Just let me know what works what doesn't

Good to know, thx.

If you have questions about third party guides, you should ask the guide author. I can make some observations regardless: There is no such thing as LOD for grass. Grass can only be drawn as far as the loaded cells. If you compare the full model trees in the loaded cells - the grass line is a good indicator - with the LOD trees beyond the loaded cells you can see that they seem to match perfectly. So 3D tree LOD seems to be working fine for the installed trees. It also seems the additional LOD objects from DynDOLOD fill the landscape nicely and for example the LOD dirtcliffs picked up a landscape texture replacement. Unrelated to DynDOLOD: Lighting seems bright and washed out, could be ENB or a weather mod - user preference of course. It seems you didn't install a "large" tree option. You don't seem to have the same mod that adds tree to the tundra. The terrain LOD texture may be still vanilla, find a suitable terrain LOD mod or for the landscape texture setup or generate terrain LOD textures for the load order with Oscape.

debug=1 is already in part of DynDOLOD. I just needed to add one additional debug line to the code for so we have something to look at for this problem. It will now stay in there for all future releases. I didn't realize there actually still was an error that you could fix with the new debug line. I misread your answer as everything worked fine now - not enough coffee I guess :) - so disregard my mumbling. If the problematic records were in a downloaded mod/plugin I would be interested in which one and which record to learn what cause the assert notice. Maybe it can be work around it or a more descriptive message can be printed.

It seems like it. Without other reports and the latest version working all well it is hard to tell.

The exe is the same, I just added that one debug message. so either should be fine. Noting else changed? That is weird. If you like just run the normal exe with debug=0 just one more time, to see if the error happens again.

Oh well. Replace DynDOLOD.exe with this version https://mega.nz/#!UMpQ0YbD!FzM47bvAN2Q1DLZuVqAShegK66Gl0SE27U9Y3ck1uM0 Then edit ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini and set Debug=1 It should print a line for each base record it is trying to update. The last one *could* be a hint to what causes the error. Look that one up in xEdit if it is overwritten, check values, or remove mod that adds/changes it etc. Let me know what you find / which mod.

Assertion errors from xEdit usually mean some data problem in plugins. After the error, when you close DynDOLOD.exe it should still offer to save the esp. Do that and upload it somewhere so I can have a look at the last thing that was added to it. At least that will help adding a debug log line for later testing.

Please post log ..DynDOLOD\\Logs\\DynDOLOD_SSE_log.txt from the failed start.

There is no code difference in reading the registry for either version. Unless the compiler does things differently. I could imagine permissions, UAC or anti virus treating the two executables differently. The x86 will be slightly faster due to more optimizations existing for that architecture, the x64 will be able to use more memory in case it is needed.

My test was with 1.3.3, so that could be it.

DynDOLOD typically does not use base records from other mods for LOD. It should create a new copy just for itself and on that copy it is supposed to ..Meshes\\DynDOLOD\\lod\\clutter\\impcandelabracandle01_dyndolod_lod.nif. So that copy has the full model instead? Check if DynDOLOD Resources are completely installed and that nif is available. Unless rules for candles were changed or something unexpected happend. When I generate LOD for just vanilla+DLC and Bruma it is fine. Otherwise I would be interested in the esp with records intact so I can investigate.

Provide more information: Game version Skryim or Skyrim SE Which Mod Manager, starting directly making a difference? What Windows version DynDOLOD.exe / DynDOLODx64.exe making a difference? If you like do same test with older DynDOLOD.exe/DynDOLODx64.exe (the first time problems were reported was with older version, though)

What do you mean by DynDOLOD referencing this model? DynDOLOD should not use that model for LOD. It will only create an overwrite for that record to set the Has LOD flag, but that doesn't do anything else, other than changing behavior on cell borders (full model may load earlier outside of uGrid without the flag) In any case, all shouldn't matter either way, if crash fixes is mentioning that nif by base record form id. Then that nif is corrupt or can not be loaded. Update/replace/check the nif.

Yes. In fact I already have terrain LOD gen meshes/textures mostly completed for Skryim and Skyrim SE. ETA depends on a few factors, but lets say some time later this year.

3. Check the last plugin(s) you enabled before the error happened, like number 179. I cant say anything about Windows 10 or whatever version you might be using. I guess anything can happen with it.

The CTD with LoTD was because LOD models were missing in the newLoTD archive, so LOD generation had to fall back to use a couple full models. Those happen to be nifs that cause CTD when they are dynamically enabled. I am not quite sure what the issue is with the full models causing the engine trip as I only encountered it a couple times so far. Crash fixes does not report this crash as a problem with a nif, because the nif appears perfectly fine. It probably is some feature or setting that interferes with something in rare combination of thing. Can you retrace the steps how you found that base record in BSHeartland.esm? That base record or its model should not be used for LOD directly. If "Candles" rules were loaded, the dynamic LOD for the those candles should use Meshes\DynDOLOD\lod\clutter\impcandelabracandle01_dyndolod_lod.nif, which is fine. Maybe for some reason the LOD uses a different / full model which is problematic. You can also try to remove the DynDOLOD_LOD reference for that LOD candle to verify it is indeed the object causing problems.