sheson

The only other thing with static LOD I could imagine would be that LOD4 does not have the object, but LOD8/16 does. If this even is about static LOD, the stuff that goes away with tll.

Gotcha. Looks like this was caused by an legacy x86 counter/integer/counter conversion, which only becomes a problem in x64. It is one of those how the @#%$ did this not cause any problems all this time before and wtf has MO to do with it. I suppose it is all in the virtual memory addressing, guess we were lucky so far. Please test this version Rename to TexGenx64.exe if needed. Please let me know that it works. Fingers crossed.

LOD can not receive or cast shadows in Skyrim or Skyrim SE. That is something that only Fallout 4 has. All the options are explained in the manual. Check the sections "Configuration" and "DynDOLOD Mod" first.

The next version will print out some more detail which LOD models / billboards are used for static LOD. Hopefully asset use or lack thereof is a bit clearer then. At least it will be easier to check.

The load order messed up message only happens when something later needs to read data from a plugin and the internal file counter does not agree with the load order form id. What that means is, it is entirely possible that whatever DynDOLOD/TexGen need to do may just get away with it. Generating textures with TexGen is probably fine after such exception. However I would not trust any saved esp in that state. I can verify the random nature of this bug. I still have a reproducible MO setup and load order with "only" 24 plugins that still shows the bug when using a debug version of version #2. The release versions I uploaded however are all working fine for me. What currently prevents me from tracing this error is, that I have not yet succeeded to replicate the problem on the development machine, despite basically copying the entire MO setup and what not. So yeah. Any tiny change in whatever will make it work... or not. If you have this, just move one plugins that are before the one that has the error around in the load order, it might just be enough. I also see the same as you, the exception happens at a specific position at times and has nothing to do with the plugin that is currently at that position. Whatever the cause, it will be something really silly.

My posts about the large references are in answer to hishutup. Your case of of missing LOD assets is solved already :)

Yes.

Either move the slider Large Object Distance in the launcher to the very left or set uLargeRefLODGridSize=5 in SkyrimPrefs.ini You didn't describe which type of LOD objects? Any? Just trees? Also make sure the DynDOLOD.esp is loaded in case LOD was generated with it.

For the next version I'll add an explicit deletion of those files instead of relying on it to overwrite them.

Sounds like the large reference engine bug. Turn the value to 5 and see if it makes a difference.

Change the LOD 4 column to Full Model in the "tree" rule.

Use the -sse command line for x86 and x64 version to make it see Skyrim SE. You can also just rename any of the working DynDOLOD exe from the test archive to TexGenx64.exe

Of course. I already removed the entries for next version.

That kind of sounds terrible, but then 1703 is still beta, right? So anything is possible :)

Which doesn't matter. Just the one with the least amount of plugins loaded until the error happens. The plugin loading part is exactly the same.

If there are no *.BTO meshes generated, check the LODGen log for errors, like ..DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt Last line should be "Code: 0" If it just stops without specific error msg / code then LODGen.exe crashed. Bring the command line window to the front next time and watch it. Since you mentioned bad memory. Make sure CPU is cooled and memory timing settings BIOS are stable - in case of overclocking etc.

Inconsequential as can be seen from experience of the past 8 months or so and the log entry of MO completing the installation with "Installation successful". As I already pointed out in my one time answer, user needs to check which game paths and plugins.txt DynDOLOD is using. The most likely reasons for the problems is not setting the required command line parameter.

Yes it contains all other unreleased updates. There is only one branch that I keep changing. If you could post the log for the shortest numbers of plugins loaded until the exception happened that could help. I had a load order that showed the exception, but it now works with the 3 latest compiles from that archive while it still fails on an old compile (not on the 2.26/2.31 versions though). It is a bit erratic...

Ahh I see, no log then, I thought there might have been an exception or error message of some kind. Thanks.

great that it works for now. DO you happen to still have the TexGen log with the error? I would be interested in it to see if it is related somehow.

Based on what we learned so far here is an archive with 3 different x64 versions to test for users who have this problem. Simply put the exe files into the DynDOLOD folder of the standalone version. Then either start them directly (adding -sse command line parameter of course) or rename to DynDOLODx64.exe/TexGenx64.exe Report which one works or not and which one works the fastest for you.

Thanks I got the files. This seems like a rather odd error. Even if you had multiple instances of something, it should always overwrite / replace the DynDOLOD_SSE_atlas_map_tamriel.txt file. It seems that for some reason each run attaches the new data to it instead of replacing it. I guess fr now the easiest solution would be to simple delete all files in ..DynDOLOD\Edit Scripts\DynDOLOD\cache\ before doing a new run.

The fail check would be that every logfile of LODGen.exe is checked for a successful exit code and messages are printed to the DynDOLOD log: Checking ..DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt Which is then either followed by LODGen.exe completed succesfully ..DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt or in case of an error it looks like this LODGenx64.exe check the logfile for errors ..DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt

I am not going to deal with children. Expert advice for a third party tool and what to do next and what to check was given. Given the attitude and entitlement no more time will be spent.

Not only that, but also the accompanying message "Texture name already defined in atlas file ..." does as well. Not quite sure how that can happen though. Something went sideways when generating the texture atlas definition file. You could try again to see if it is a one time thing. If problem persists, check/post the DynDOLOD log and ..DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_SSE_atlas_map_tamriel.txt