DynDOLOD Beta for Skyrim Special Edition, Skyrim VR and Enderal SE 2.98

[sheson]

ok this is getting even more frustating, i completly uninstalled all mods related to dyndolod, downloaded the version 2.66 of the standalone and resources package, and installed them in the same order like i had before. and i still get the same error. there is nothing overwriting the papyrus scripts from papyrusutil vr or the scripts dyndolod resources, and i get the same error on startup on the game.

dyndolod requires dyndolod.dll. i have double check my install order several times and everything is in the right order also.

sksevr

skyuivr

dyndolod resources se 2.66beta

papyrusutil vr  3.6beta

papyrus extender - vr 1.4.15 - v1.51

and at the very end of the install order 

texgen output

dyndolod ouput

 

plz help the reason i am going with papyrusutil to dynamic dyndolod is because i need it installed for another mod.

i tried also the variation using the dyndolod.dll and it's scripts also but it also generates the same error. can dyndolod.dll and papyrusutil be used together. everything is installed thrugh mod organizer, do i need to install these mods manually instead. plz help

The text "DynDOLOD requires DynDOLOD.DLL" does not exist in the papyrus scripts SHESON_DynDOLOD_*.pex shipping with DynDOLOD Resources.

If you start a new game and see that text the only possible answer is that one or more scripts from DynDOLOD DLL are installed.

is dynamic dyndolod just broken on skyrimvr? i have been trying to get it to working for a week now.

No it is not. There would be posts from many people having the same issue.

Edited July 14, 2019 by sheson

[erasmux]

If the files are not corrupt (which seems to be the case because they work out in the next run), then you should check overclocking settings, CPU temps, memory timings etc.

Also possible that MO2 is acting up with Windows 10 as we see with the mysterious corrupting textures issue.

Obviously I have tested the computer general stability: I do not overclock, cpu temps are low, the computer is 100% stable (other than this DynDOLOD issue which I believe IS a DynDOLOD issue), prime95 tests run without error, memtest86 runs without errors, disk health is good and error free. Even if the computer was unstable, which it isn't, there is no chance such instability would reproduce these exact DynDOLOD errors consistently and only them (getting 0-3 such errors, usually 1 or 2, in each run and on the same files and no other errors).

 

Also it's Windows 7 so it's not "MO2 is acting up with Windows 10". Furthermore, just for you, I have reproduced the error without MO, so it's definitively not an MO problem.

 

I know it's not what a developer wants to hear but I am as sure as one can be in such matters that the issue is with DynDOLOD (or the tools it runs like LODGen or TexConv).

 

Again, if there is anything I can do to further investigate the issue let me know (I do have the proper background, programming, etc.).

[sheson]

Obviously I have tested the computer general stability: I do not overclock, cpu temps are low, the computer is 100% stable (other than this DynDOLOD issue which I believe IS a DynDOLOD issue), prime95 tests run without error, memtest86 runs without errors, disk health is good and error free. Even if the computer was unstable, which it isn't, there is no chance such instability would reproduce these exact DynDOLOD errors consistently and only them (getting 0-3 such errors, usually 1 or 2, in each run and on the same files and no other errors).

 

Also it's Windows 7 so it's not "MO2 is acting up with Windows 10". Furthermore, just for you, I have reproduced the error without MO, so it's definitively not an MO problem.

 

I know it's not what a developer wants to hear but I am as sure as one can be in such matters that the issue is with DynDOLOD (or the tools it runs like LODGen or TexConv).

 

Again, if there is anything I can do to further investigate the issue let me know (I do have the proper background, programming, etc.).

Great that you did all that testing. I will have to wait for the deluge of error reports from all the other users before I attempt to reproduce the "DynDOLOD issue" that all of sudden befell it. Test with the x86 version or vice versa the x64 version.

 

In the meantime maybe you could double check the .NET 4.0 installation and the Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019. Maybe a recent update to those causes issues.

 

If problem persists post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt (if it exists) and ..DynDOLOD\Logs\DynDOLOD_[GAMEMODE]_log.txt

 

If you see problems with LODGen.exe again, maybe you could test the earlier versions included in xLODGen beta 42 or beta 45.

Edited July 14, 2019 by sheson

[erasmux]

Great that you did all that testing. I will have to wait for the deluge of error reports from all the other users before I attempt to reproduce the "DynDOLOD issue" that all of sudden befell it. Test with the x86 version or vice versa the x64 version.

 

In the meantime maybe you could double check the .NET 4.0 installation and the Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019. Maybe a recent update to those causes issues.

 

If problem persists post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt (if it exists) and ..DynDOLOD\Logs\DynDOLOD_[GAMEMODE]_log.txt

 

If you see problems with LODGen.exe again, maybe you could test the earlier versions included in xLODGen beta 42 or beta 45.

I have already updated my .NET and VC++ redistributable a week ago to resolve a different problem with 2.65 (which btw also looked like a concurrency/synchronization issue).

 

Regarding attempting to reproduce this specific issue, I can only say that from my experience with multi-thread/multi-process programs such concurrency/synchronization issues are often quite hard to impossible to reproduce on a different system. I have seen synchronization issues which after they have been identified you scratch your head "how the hell did this ever work?" and yet it worked in production on many many machines without any problems until this one machine on which the issue "suddenly" surfaced. Hence my offer to help in any way I can to investigate it on my machine.

 

In the meantime, I possibly found a workaround, by disabling all three of the "FasterXXX=0" in the DynDOLOD_SSE.ini (possibly disabling only "FasterBase=0" is enough). When disabling all three the runtime only slightly increases (from ~ 14 mins for all worlds to ~ 15.5 mins). Since I have done this I have not seen the "Error reading NIF" even once. Oddly when trying to test the stability of these options by selecting only the Sovngarde world (for quicker runs so I can test it multiple times quickly), it seems to deadlock on "Preparing texture data" about 50% of the times. At this point I have run quite a few runs on all worlds (including Sovngarde) with these options and none of them deadlocked. I am not sure how to explain this.

 

I have also managed to reproduce the LODGen error with 2.5.6 (the version inside "Edit Scripts" of the xLODGen beta 42 archive):

 

 

============================================================

Skyrim Object LOD Generator 2.5.6.0

Created by Ehamloptiran and Zilav

Updated by Sheson

 

Log started at 19:13:35

Game Mode: SSE

Fix Tangents: False, False, False, False

Generate Tangents: True, True, True, True

Generate Vertex Colors: True, True, True, True

Merge Vertex Colors: True, True, True, True

Merge Meshes: True

Grouping: False

Remove Faces under Terrain: True

Remove Faces under Water: True

Remove Faces Z-Shift: 10

Use HD Flag: True

Ignore Materials: False

Alpha DoubleSided: False

Default Alpha Threshold: 128

Use Source Alpha Threshold: False

Use Backlight Power: False

Use Decal Flag: False

Specific level: No

Specific quad: No

Max Level: 32

Output: C:\Games\Skyrim_SE_mods\DynDoLOD\DynDOLOD\DynDOLOD_Output\Meshes\Terrain\sovngarde\Objects\

Using UV Atlas: C:\Games\Skyrim_SE_mods\DynDoLOD\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_SSE_atlas_map_sovngarde.txt

Using Flat Textures: C:\Games\Skyrim_SE_mods\DynDoLOD\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_SSE_flat_textures.txt

Using Alt Textures: C:\Games\Skyrim_SE_mods\DynDoLOD\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_SSE_alt_textures_sovngarde.txt

Generating object LOD for worldspace Sovngarde

Can not get hash for shader in meshes\dyndolod\lod\trees\srg_treepineforestsnow05_86f7fc82passthru_lod.nif block TreePineForestSnow05_LOD_FLAT:1 Invalid handle. System.ArgumentNullException: Invalid handle.

at System.RuntimeTypeHandle.GetToken(RuntimeType type)

at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.PopulateLiteralFields(Filter filter, RuntimeType declaringType, ListBuilder`1& list)

at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.PopulateFields(Filter filter)

at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.GetListByName(Char* pName, Int32 cNameLen, Byte* pUtf8Name, Int32 cUtf8Name, MemberListType listType, CacheType cacheType)

at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.Populate(String name, MemberListType listType, CacheType cacheType)

at System.RuntimeType.GetFieldCandidates(String name, BindingFlags bindingAttr, Boolean allowPrefixLookup)

at System.RuntimeType.GetFields(BindingFlags bindingAttr)

at System.Runtime.Serialization.FormatterServices.GetSerializableMembers(RuntimeType type)

at System.Runtime.Serialization.FormatterServices.InternalGetSerializableMembers(RuntimeType type)

at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)

at System.Runtime.Serialization.FormatterServices.GetSerializableMembers(Type type, StreamingContext context)

at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitMemberInfo()

at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter, SerializationBinder binder)

at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo)

at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)

at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[] headers, Boolean fCheck)

at LODGenerator.Common.Utils.ObjectToByteArray(Object obj)

at LODGenerator.ShapeDesc..ctor(String gameDir, NiFile file, NiTriBasedGeom geom, StaticDesc stat, Int32 quadIndex, List`1 PassThruMeshList, List`1 notLODFlag, Boolean skyblivionTexPath, Boolean useOptimizer, Boolean mergeVertexColors, Boolean fixTangents, Boolean useDecalFlag, Boolean terrain, Boolean verbose, LogFile logFile)

Log ended at 19:13:38 (0:2)

Code: 3005

 

 

This still happens very rarely for me (a total of 3 times till now, once with 2.65, once with 2.66 and LODGen 2.6.2 and now once with LODGen 2.5.6).

 

Btw using the new LODGen 2.6.2 (as opposed to version 2.5.6) DynDOLOD runs slightly faster and the result is smaller without any quality loss I can discern (do note I am not sensitive to delicate difference in quality). So at least from my point of view, very good job on the new LODGen.

 

---

 

Meanwhile, I have actually managed to clean my tree mods and reach a DynDOLOD result I am pleased with .

 

The only problem I still have, is that when generating "Ultra Trees"  (TreeLOD=0), as I close in on far away trees they switch almost instantaneously from the LOD to the full model. Its definitively not the 2.7 seconds in the DynDOLOD MCM menu. I have tried to increase this setting to the maximum of 5 seconds with no noticeable difference. This bothers my eyes enough that I think I even prefer the much less refined TreeLOD=1 LODs, on which the transition is gradual (most likely the 2.7 seconds from the config, although I didn't bother to measure it).

 

Is there something I can do to both have "Ultra Trees" and a gradual transition from the LODs to the full model?

 

BTW many thanks for this great tool and your dedicated support.

[sheson]

The only problem I still have, is that when generating "Ultra Trees"  (TreeLOD=0), as I close in on far away trees they switch almost instantaneously from the LOD to the full model. Its definitively not the 2.7 seconds in the DynDOLOD MCM menu. I have tried to increase this setting to the maximum of 5 seconds with no noticeable difference. This bothers my eyes enough that I think I even prefer the much less refined TreeLOD=1 LODs, on which the transition is gradual (most likely the 2.7 seconds from the config, although I didn't bother to measure it).

 

Is there something I can do to both have "Ultra Trees" and a gradual transition from the LODs to the full model?

 

BTW many thanks for this great tool and your dedicated support.

Traditional tree LOD switches instantly. It is not possible to control the time the engine needs to load all the required full models before it unloads the object LOD.

 

There is a setting to change the stipple fade, however it seems to only make things worse. https://forum.step-project.com/topic/13894-dyndolod-beta-for-skyrim-special-edition-and-skyrim-vr-267/page-74?do=findComment&comment=231233

 

The DynDOLOD SkyUI MCM Setting controls the delay of the fade-from-black after loading.

[erasmux]

Traditional tree LOD switches instantly. It is not possible to control the time the engine needs to load all the required full models before it unloads the object LOD.

 

There is a setting to change the stipple fade, however it seems to only make things worse. https://forum.step-project.com/topic/13894-dyndolod-beta-for-skyrim-special-edition-and-skyrim-vr-267/page-74?do=findComment&comment=231233

 

The DynDOLOD SkyUI MCM Setting controls the delay of the fade-from-black after loading.

That is a shame (not your fault, of course). I tried to add bEnableStippleFade=0 or bEnableStippleFade=1 to my skyrim/skyrimcustom/skyrimprefs INIs and I don't see any difference.

 

After some deliberation (with myself) and a few screenshots, I decided the 3D trees are too good to pass because of this issue. I have actually been using a much more broken "ultra trees" for some time now, so hopefully I don't even notice those harsh transitions unless I am specifically looking for them

 

Here are some 2D vs 3D trees:

 

Thanks again

[zilav]

There is a sudden increase of reports about corrupted nifs (and even corrupted lodsettings(!) files) in lodgen nexus comments too, and we are talking about lodgen versions which have not been updated for like 2 years and always worked perfectly. Considering that all reports come from MO users and they happen randomly, I'm 99% sure this is a concurrency MO bug in it's recent versions.

[erasmux]

There is a sudden increase of reports about corrupted nifs (and even corrupted lodsettings(!) files) in lodgen nexus comments too, and we are talking about lodgen versions which have not been updated for like 2 years and always worked perfectly. Considering that all reports come from MO users and they happen randomly, I'm 99% sure this is a concurrency MO bug in it's recent versions.

At least the errors I have reported above, I have reproduced without MO running at all so they are not related to MO in any way.

 

 

I am "99% sure" (not really but hey it's really easy to type 99% without any proof) this is a concurrency/synchronization issue(s) with DynDOLOD and/or LODGen. Such issues are very hard to track down and will usually work very well for a very long time and surface only in specific instances for unclear reasons.

Edited July 15, 2019 by erasmux

[zilav]

I am "99% sure" (not really but hey it's really easy to type 99% without any proof) this is a concurrency/synchronization issue(s) with DynDOLOD and/or LODGen. Such issues are very hard to track down and will usually work very well for a very long time and surface only in specific instances for unclear reasons.

Unless Sheson modified something in DynDoLOD, the lodgen's nif textures gathering code is single threaded. It is for sure in lodgen's on Nexus and people report corrupted nifs using MO there. So I'm 99% sure the reason is MO, just not in your particular case.

[erasmux]

Unless Sheson modified something in DynDoLOD, the lodgen's nif textures gathering code is single threaded. It is for sure in lodgen's on Nexus and people report corrupted nifs using MO there. So I'm 99% sure the reason is MO, just not in your particular case.

Actually according to the only xLODGen source I could find (here), and according to the stack trace from the issue I had here, it seems that lodgen does load nifs in parallel.

 

I will also add, that at least at one point I was quite familiar with the implementation of usvfs (the relevant part of MO2) and it only catches and redirects system calls such as file open requests. Meaning MO2 bugs may cause file open requests to fail, or in theory to open the wrong file, but it should be technically impossible for usvfs to effect the file contents (an up to date list of the functions usvfs hooks is here and you can see none of those hooks can effect the file contents). Additionally, as long as we are talking about files which existed and have not been renamed/moved/deleted from before usvfs was initialized (i.e. before the MO2 process spawned xLODGen and locked itself), there is no concurrency or synchronizations as nothing changes from the usvfs point of view (it is only interested in what virtual paths need to be mapped and to which actual paths).

 

That said, if you believe you have identified an MO2 issue, it should be raised with current MO developers.

 

BTW, any chance there are up to date sources for DynDOLOD and/or xLODGen and I missed them?

[Serio]

For some reason the mod is making my character freeze when entering Helgen during the opening scene. Something about it is disabling player movement when entering the keep. Character also bobs up and down as though stuck in a walking animation. I'm not sure how that's even possible, but it works after deactivating DynDOLOD.esp. I'm using Alternate Start LAL. Not sure if that has anything to do with it. 

[Serio]

For some reason the mod is making my character freeze when entering Helgen during the opening scene. Something about it is disabling player movement when entering the keep. Character also bobs up and down as though stuck in a walking animation. I'm not sure how that's even possible, but it works after deactivating DynDOLOD.esp. I'm using Alternate Start LAL. Not sure if that has anything to do with it. 

Nevermind. Just updated to 2.67 and the problem seems to have gone away.

[kranazoli]

DynDOLOD Beta for Skyrim Special Edition and Skyrim VR 2.67

 

https://youtu.be/fjuwLaCtvpA

 

Wierd flickering I always had, but found something interesting...

[sheson]

DynDOLOD Beta for Skyrim Special Edition and Skyrim VR 2.67

 

https://youtu.be/fjuwLaCtvpA

 

Wierd flickering I always had, but found something interesting...

Large reference bugs. 

[Caellidwen]

New to forum - hi

 

Trying to run DynDOLOD beta for Skyrim SE and I get this error from my computer:

 

 

[00:00:00.104]    DynDOLOD based on xEdit x64 (6CDD7EC8) starting session 2019-07-20 20:03:59
[00:00:00.109]    Using Skyrim Data Path: C:\Games\The Elder Scrolls V - Skyrim - Legendary Edition\Data\
[00:00:00.111]    Using Backup Path: C:\Games\The Elder Scrolls V - Skyrim - Legendary Edition\Data\TES5Edit Backups\
[00:00:00.114]    Using Scripts Path: C:\Users\Axia\Desktop\Desktop Downloads\DynDOLOD-Standalone.2.67\DynDOLOD\Edit Scripts\
[00:00:00.117]    Using Cache Path: C:\Users\Axia\Desktop\Desktop Downloads\DynDOLOD-Standalone.2.67\DynDOLOD\Edit Scripts\DynDOLOD\cache\
[00:00:00.121]    Using Temp Path: C:\Users\Axia\AppData\Local\Temp\TES5Edit\
[00:00:00.124]    Using ini: C:\Users\Axia\Documents\My Games\Skyrim\Skyrim.ini
[00:00:00.128]    Fatal: Could not find ini

I am not using legendary version of Skyrim, using Special Edition but it refuses to recognize that I am using special edition.  I have downloaded the beta version from this forum and from Nexus's page and both keep popping up this error.  Forgive me if I am being stupid for not realizing that I have to 'add' something to make the exe recognize special edition but I don't know where it is.  If someone would be kind enough to show me my ignorance I would be grateful.

 

I did try watching videos but none of them were showing any problems and just motored on which didn't help me.