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

[sheson]

  On 7/12/2019 at 11:20 AM, Hadley said:

When I change the MCM Settings it even gets worse and even more Terrain is missing, but I realized I have this bug even if I run the Game without any Mods. I deleted my Inis and even with that I still have this bug. How is that possible? There has to be a easy way to fix this. I modtested SE quite a bit before and I never have seen this weird bug before.

This is a vanilla bug that is caused by the pre-computed occlusion data. Everybody has this bug.

 

There is no true fix. Changing the LOD distance settings can help to cover it up by shifting the LOD levels. CK is broken and can not calculate correct pre-computed occlusion.

 

A workaround is to remove the pre-computed occlusion data from the cell the bug happens in - in exchange for FPS.

There is a mod that removes the data for all cells, which obviously is a really bad idea.

Hence the link to the plugin created by Plockton.

Edited July 12, 2019 by sheson

[erasmux]

Having some stability problems with DynDOLOD (running the latest 2.66 standalone with the 2.66 resources package), and getting errors such as the following intermittently:

[00:01:02.806]    <Warning: Error when loading "meshes\lod\mine\minescaffoldtop0sided01_lod_0.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>
[00:01:02.837]    <Warning: Error when loading "meshes\lod\tundra\reach\tundrastreambend01reach_lod_0.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>
[00:01:02.853]    <Warning: Error when loading "meshes\lod\solitude\sthalmorembassy_lod.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>
[00:01:02.931]    <Warning: Error when loading "meshes\dyndolod\lod\trees\srg_treepineforest01_a84564afpassthru_lod.nif": Error reading NIF block 2 NiTriShape: Unknown NiObject: NiTriShape>
[00:01:02.931]    <Warning: Error when loading "meshes\lod\tundra\reach\tundrastreambend01reach_lod_0.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>

(Notice that in this example the same "meshes\lod\tundra\reach\tundrastreambend01reach_lod_0.nif" appears twice?!)

 

Usually there will be only 1 or 2 such errors (the above 5 errors is the worst case I have seen). Running DynDOLOD again and again with the exact same options will eventually result in an error free run (always clearing the cache, export and output folders between runs and without any other changes). I seem to get these errors more frequently generating "regular" LODs (i.e. running DynDOLOD with the default TreeLOD=1 and simply selecting High from the "wizard"). Running with "TreeLOD=0", which is the only usage I have done with previous versions, also generates such errors but less frequently, so it's hard for me to say if this is new to the new version.

 

I have also run into the following error in the LODGen_SSE_DLC2SolstheimWorld_log.txt (once):

Can not get hash for shader in meshes\dyndolod\lod\trees\treepineforestdeadashl01passthru_lod.nif block TreePineForestDeadAsh01:1 - L2_:0 - L1_:0 Invalid handle. System.ArgumentNullException: Invalid handle.

Rerunning DynDOLOD "resolved" the issue. This is similar to the error I reported here with 2.65, in that case rerunning DynDOLOD without any changes also "resolved" the issue (only clearing the cache, export and output folders).

 

I have also verified all the above files are the same as their sources (which are the DynDOLOD Resource SE package, oldrim EVT or Enhanced Landscapes; The "sthalmorembassy_lod.nif" I could not verify as it is not a loose file in any of my mods).

 

I can only guess this is some odd parallelism issue which causes the above instabilities.

 

Please let me know if there is further information or testing I can provide to help investigate this issue.

Edited July 13, 2019 by erasmux

[Andersdja80]

  On 7/10/2019 at 1:54 PM, sheson said:

If this happens with a new game the answer is simple:

There are papyrus scripts from DynDOLOD DLL in the load order and they load after / replace the papyrus scripts from DynDOLOD Resources.

 

In MO, right window, data tab, files in the Scripts folder matching SHESON_DynDOLOD_*.pex

It does not matter what MO says the source mod is. Some or all of files are scripts from DynDOLOD DLL and not DynDOLOD Resources.

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

[Andersdja80]

  On 7/14/2019 at 3:04 AM, Andersdja80 said:

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

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

[sheson]

  On 7/13/2019 at 9:29 PM, erasmux said:

Having some stability problems with DynDOLOD (running the latest 2.66 standalone with the 2.66 resources package), and getting errors such as the following intermittently:

[00:01:02.806]    <Warning: Error when loading "meshes\lod\mine\minescaffoldtop0sided01_lod_0.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>
[00:01:02.837]    <Warning: Error when loading "meshes\lod\tundra\reach\tundrastreambend01reach_lod_0.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>
[00:01:02.853]    <Warning: Error when loading "meshes\lod\solitude\sthalmorembassy_lod.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>
[00:01:02.931]    <Warning: Error when loading "meshes\dyndolod\lod\trees\srg_treepineforest01_a84564afpassthru_lod.nif": Error reading NIF block 2 NiTriShape: Unknown NiObject: NiTriShape>
[00:01:02.931]    <Warning: Error when loading "meshes\lod\tundra\reach\tundrastreambend01reach_lod_0.nif": Error reading NIF block 2 BSTriShape: Unknown NiObject: BSTriShape>

(Notice that in this example the same "meshes\lod\tundra\reach\tundrastreambend01reach_lod_0.nif" appears twice?!)

 

Usually there will be only 1 or 2 such errors (the above 5 errors is the worst case I have seen). Running DynDOLOD again and again with the exact same options will eventually result in an error free run (always clearing the cache, export and output folders between runs and without any other changes). I seem to get these errors more frequently generating "regular" LODs (i.e. running DynDOLOD with the default TreeLOD=1 and simply selecting High from the "wizard"). Running with "TreeLOD=0", which is the only usage I have done with previous versions, also generates such errors but less frequently, so it's hard for me to say if this is new to the new version.

 

I have also run into the following error in the LODGen_SSE_DLC2SolstheimWorld_log.txt (once):

Can not get hash for shader in meshes\dyndolod\lod\trees\treepineforestdeadashl01passthru_lod.nif block TreePineForestDeadAsh01:1 - L2_:0 - L1_:0 Invalid handle. System.ArgumentNullException: Invalid handle.

Rerunning DynDOLOD "resolved" the issue. This is similar to the error I reported here with 2.65, in that case rerunning DynDOLOD without any changes also "resolved" the issue (only clearing the cache, export and output folders).

 

I have also verified all the above files are the same as their sources (which are the DynDOLOD Resource SE package, oldrim EVT or Enhanced Landscapes; The "sthalmorembassy_lod.nif" I could not verify as it is not a loose file in any of my mods).

 

I can only guess this is some odd parallelism issue which causes the above instabilities.

 

Please let me know if there is further information or testing I can provide to help investigate this issue.

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.

Edited July 14, 2019 by sheson

[sheson]

  On 7/14/2019 at 3:04 AM, Andersdja80 said:

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.

  On 7/14/2019 at 3:10 AM, Andersdja80 said:

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]

  On 7/14/2019 at 5:49 AM, sheson said:

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]

  On 7/14/2019 at 9:48 AM, erasmux said:

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]

  On 7/14/2019 at 11:00 AM, sheson said:

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):

 

 

  Reveal hidden contents

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

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]

  On 7/14/2019 at 5:52 PM, erasmux said:

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]

  On 7/14/2019 at 6:07 PM, sheson said:

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]

  On 7/15/2019 at 6:07 AM, zilav said:

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]

  On 7/15/2019 at 9:53 AM, erasmux said:

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]

  On 7/15/2019 at 8:23 PM, zilav said:

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?