sheson

The error might not be in MoonAndStar_MAS.esp but another plugin. Check those as well. That error is straight from the xEdit portion of DynDOLOD, so it is a problem with a plugin that xEdit should report as well.

The different CPU platforms x86/x64 of DynDOLOD have nothing to do with the different game versions. DynDOLOD defaults to Skyrim. You need to add -sse command line parameter to start it in Skyrim SE mode. I suggest to read the included manual. As you can see from screenshot, the error is quite different this time compared to the log you uploaded earlier. It appears to have generated all selected worldspaces without error. It rather failed building the reference info to make a report about missing nifs. At this point the all the LOD is generated completely, once the last LODGen.exe finishes you can close 'x' DynDOLOD and it should prompt to save the DynDOLOD.esp and then proceed as normal by installing the generated output. This error suggests a problem with a plugin. Use xEdit to check all plugins for errors and fix them. Start with the plugin mentioned before the error at load order 15 hex / 21 decimal. I also suggest to not install DynDOLOD into special windows folders like Program Files or Users / Documents. I suggest to not generate LOD for Bruma / BS Heartland. It may be a good idea to disable the mod for generation and see if things work more smoothly. Blue / Green screen of death and problems that affect the entire computer/OS are typically a hardware or overclocking problem. Make sure cooling works well and that CPU, memory settings in BIOS are correct.

Try to generate the problematic worldspace (DLC01FalmerValley) all by itself. If it runs through then, install output as normal. Then start DynDOLOD.exe with the DynDOLOD.esp in the load order and generate LOD for the remaining worldspaces. Install new output, overwriting any old output files, including DynDOLOD.esp.

It makes no difference to for the DynDOLOD process if TES5LODGen was used to before generate object/tree LOD. It will do its thing. The only exception is if 2D tree LOD generation is not checked. Then DynDOLOD will try to scan the existing tree LOD in order to determine which trees already have 2D tree LOD and do not need static/dynamic tree LOD. If you merge plugins, but not their BSAs, then you either need dummy esp or add the BSAs to Skyrim.ini. Otherwise the original BSAs will not be loaded. The DynDOLOD log will show which BSAs are loaded at start up. If there is still an exception when running DynDOLOD.exe from test version, post the DynDOLOD\Logs\DynDOLOD_TES5_log.txt If the exception is with LODGen.exe (also used by TES5LODGen), get a newer version from https://forum.step-project.com/topic/12407-lodgenx64-crash-running-dyndolod-for-sse/?p=205499 and update the older version in 'Edit Scripts' of DynDOLOD/TES5LODGen. If problems persists make a screenshot or copy paste the error from the white text on black background cmd window of LODGen.exe.

It is very likely that the windows version does not matter. Is there no exception message? Post the log. Does it just disappear without error? Check event log. Have you also tried with DynDOLODx64.exe? Try with test version from https://forum.step-project.com/topic/11997-dynamic-distant-objects-lod-dyndolod-226/page-12?do=findComment&comment=203874

Awesome. Thanks for letting us know.

Let me know if this newer version of LODGen.exe works better. Just replace files in DynDOLOD\Edit Scripts\

https://forum.step-project.com/topic/11997-dynamic-distant-objects-lod-dyndolod-226/page-12?do=findComment&comment=203874

From the manual "Updating" section.

Nothing there.

Read the manual. Especially the section "Updating"

Problems like this that affect the entire computer/OS are typically a hardware or overclocking problem. Make sure cooling works well and that CPU, memory settings in BIOS are correct. Try this test version https://mega.nz/#!Bc5gmArQ!IzFTE3LCFLYPSlXdUzfVXcs2YiVV0qy4-W3-L1_o7Hw. Try FasterBase=0 and/or FasterCreate=0 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini

If I remember correctly it is not possible to use "TranslateTo" on persistent references - they just won't move. The "TranslateTo" is the the function to keep the ships moving. Persistence is required for the IsFullLOD (Neverfade) flag to work. If someone discovered a workaround, then please let me know. If that can be figured out, then DynDOLOD can be used to patch the references to the required flags. The scripts need to be updated as well, they have something in them about distance of the ships to be close to player in order for the ships to show up in the first place.

3D tree LOD uses the static object LOD for 3D trees. It disables the 2D tree LOD system. It does not matter if 2D tree LOD is generated with TES5LODGen or DynDOLOD, they should be about the same.

https://forum.step-project.com/topic/11997-dynamic-distant-objects-lod-dyndolod-226/?p=203874

I found a couple discussions that also report that Game.GetPlayer() is slower than using properties or a cache. So I am just going to take that at face value and since the Firstborn/Minion scripts are only attached to 2 single base records, using a PlayerRef property looks like the best solution. The testing for users doing weird things is what really needed to be addressed. I also did a few tests in another script (LODObject, now caching PlayerRef) where there are a few conditions with kActionRef.GetWorldspace() and PlayerRef.GetWorldSpace() that execute each iteration. Instead of using the functions, I tried using Worldspace / String (although not good for string count) variables instead. With the assignment and all conditions updated, either solution was considerably (twice and more) slower, interestingly. So that function doesn't seem to be as problematic in this case. The next or the second next version will sport these optimized scripts as it requires small changes to patcher of course to add the PlayerRef property. The SKSE/Papyrus tests moved to a once per game load function, etc.

That sounds encouraging. Use attached version that would fix the line 76 error for now. Should only happen near Goldenglow Estate anyways. SHESON_DynDOLOD_LODObject.7z

Is that on a new game? There a couple changes in the script that would require a clean save / new game. Test for stuck LOD objects. I would only expects errors in Line 76, as that is using new data that does not exist in your json files yet.

See if the attached script gets rid of the sporadic Cannot call IsDisabled() error message and hopefully the problem. There is also this cosmetic error Unable to bind script SKI_PlayerLoadGameAlias which somehow sneaked in (will be fixed next version). You can fix that by editing formid xx00090F in DynDOLOD.esp in xEdit and change the VMAD \ Aliases \ Alias \ Object Union \ Object v2 \ Alias from "None" to "000 PlayerAlias" (just type 0 when editing) Replace the existing ..\DynDOLOD\Edit Scripts\DynDOLOD\hardcoded\*.dat with the one attached, so next time you generate LOD the Alias is already set correct again. SHESON_DynDOLOD_LODObject.7z Skyrim.Hardcoded.keep.this.with.the.exe.and.otherwise.ignore.it.I.really.mean.it.7z

Still happens after reboot? Antivir/UAC? Anything in windows event log? What is the "seperate" folder? Does latest xEdit work without problems? Does c:\Users\[username]\AppData\Local\Skyrim\DynDOLOD_settings.ini exist? Any changes changes deleting that file? Does it work while holding shift when starting it?

I will see if I can replicate that and probably have another test script soon.

I did away with any and all properties because they caused a lot of problems also when updating and performance wise (maybe not for for the GetPlayer, but for other things) The clean save already needs to be done when generating a new esp from scratch, because the save file also stores the position of references and other persistent data. It can happen that between two LOD generations the same form ids are used, which then would cause problems if the save is not cleaned. Since I am doing timing tests anyways, I will also try different approaches. So far I only encountered issues with defining Functions in papyrus myself, not with the native ones.

Ops, here it is SHESON_DynDOLOD_LODObject.7z

Those pictures you posted are great.

You would think a value that never changes is "fast". I will do some profiling tests with this, anyways. I need to know for sure :)