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

[sheson]

sheson, on 17 Apr 2019 - 3:56 PM, said:

 

There is to post all that superfluous information about unrelated problems from the past you had with mods. Stick to the problem and information at hand.

It seems there is a problem with the load order. That issue might cause CTD. Read the DynDOLOD FAQ entry about CTD. It points to the readme with hints how to troubleshoot missing or invalid NIFs.

 

Sheson,

 

It can't be! Before that also got something like that info, and found out the issue is with MM, and later DynDOLOD (missing Dragonreach top)

 

Again:

 

It can't be load order issue, cause without DynDOLOD everything works fine. Load order does not change, after I generate DynDOLOD. (just the DynDOLOD files)

 

Everything else works fine, I can fast travel anywhere, no CTD at all. Nothing.

 

I can run for hours at Winterhold Restored installed, BUT just without DynDOLOD.

 

Beleive me, I know, what could cause CTD. ATM, 99% sure it is DnyDOLOD.

 

(before that also DynDOLOD waas the guilty one, not load order, or anything else.)

 

It is also can't be NIF issue. Got it Sheson:

 

Without DynDOLOD no issue at all. The NIF files are there!

 

I generated a new DynDOLOD, but just for Tamriel, without xLODGEN, just TexGen and DynDOLOD. Nothing else.

 

Please, answer that question:

 

1.     How could it be, that without DynDOLOD I have no issue at all?
2.     No CTD; No Load order issue; NIF files is there (and SSE AssestOptimized), etc...

How could it be, that without DynDOLOD I have zero issue?!

 

Something logic answer?

 

I read the manual.

 

So, I do not post anything, at all?!

 

For me it is obvious my CTD is because of DynDOLOD.

 

I thought this is the DynDOLOD support topic.

 

I have some idea, that maybe No Snow Under The Roof.

 

 

 

DynDOLOD_SSE_log

 

http://pasted.co/85e5e848

 

TexGen_SSE_log

 

http://pasted.co/2bc311f5

 

 

LODGen_SSE_Tamriel_log

 

http://pasted.co/259cf3be

 

 

Again, the only thing I can say, and repeat myself:

MEA CULPA; MEA CULPA; MEA CULPA

 

DynDOLOD does not cause CTD. The DynDOLOD Resources do not cause CTD. In case of principle bugs and problems that sometimes sneak in there are always plenty of users reporting the same issues.

 

CTDs are often caused by missing or corrupted NIFs. The way DynDOLOD uses them for LOD makes a difference - they can work fine when used "normally". We have troubleshooted this plenty of times in the past years.

That is why there is a FAQ entry and the readme explaining how to troubleshoot for that specific issue.

 

Other then that, the DynDOLOD plugins are build by copying records from other plugins in the load order.

If the CTD is caused by records in the plugins, it is also very easy to troubleshooting with a binary search removing all records that do not contribute to CTDs.

 

 

FAQ: Game: ILS or CTD

 

A: More LOD uses more memory and this can cause infinite loading screen (ILS) or crash to desktop (CTD) if the game is not setup correctly. This should generally not be a problem with Skyrim Special Edition or Skyrim VR, but for Skyrim double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Or use the alternative OSAllocator from crash fixes with pre-loader. Remove satefy-load if it is used to verify it doesn't cause CTD. Set ExpandSystemMemoryX64=false in enblocal.ini 

 

A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. 

 

A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. 

Edited April 17, 2019 by sheson

[steveowashere]

Hello Sheson!

 

I am trying to get DynDOLOD to run via Steam Play (wine) on Linux. I have an otherwise stable setup and everything is working great.

 

I'm encountering error when tree billboards are being generated with Texconv.exe / Texconvx64.exe

 

It gives the following errors:

Invalid value specified with -m (0)

Error: [Tamriel] Trees LOD generation error: Executing TexConv returned error: "Z:\home\steven\.steam\steam\steamapps\common\Skyrim Special Edition\DynDOLOD\Edit Scripts\Texconv.exe" -nologo -y -sepalpha -m 0 -f BC7_UNORM -bcquick -o "Z:\home\steven\Documents\Backups\Textures\Terrain\Tamriel\Trees" "Z:\home\steven\Documents\Backups\Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds"

Running Texconv.exe / Texconvx64.exe via command line shows that the program will run just fine and displays my correct GPU.

 

Installed and using latest 2.59 standalone and resources. It's a fresh install, so no chance of leftovers.

 

I've tried multiple output directories, permissions are not an issue.

 

I've tried setting textures back to BC1 & BC3.

 

Tried both 32 and 64 versions of DynDOLOD.

 

Attached are bugreport.txt & DynDOLOD_SSE_log.txt

 

Thanks for any help

 

bugreport.txt

DynDOLOD_SSE_log.txt

[sheson]

Hello Sheson!

 

I am trying to get DynDOLOD to run via Steam Play (wine) on Linux. I have an otherwise stable setup and everything is working great.

 

I'm encountering error when tree billboards are being generated with Texconv.exe / Texconvx64.exe

 

It gives the following errors:

Invalid value specified with -m (0)

Error: [Tamriel] Trees LOD generation error: Executing TexConv returned error: "Z:\home\steven\.steam\steam\steamapps\common\Skyrim Special Edition\DynDOLOD\Edit Scripts\Texconv.exe" -nologo -y -sepalpha -m 0 -f BC7_UNORM -bcquick -o "Z:\home\steven\Documents\Backups\Textures\Terrain\Tamriel\Trees" "Z:\home\steven\Documents\Backups\Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds"

Running Texconv.exe / Texconvx64.exe via command line shows that the program will run just fine and displays my correct GPU.

 

Installed and using latest 2.59 standalone and resources. It's a fresh install, so no chance of leftovers.

 

I've tried multiple output directories, permissions are not an issue.

 

I've tried setting textures back to BC1 & BC3.

 

Tried both 32 and 64 versions of DynDOLOD.

 

Attached are bugreport.txt & DynDOLOD_SSE_log.txt

 

Thanks for any help

It doesn't seem to makes much sense for TexConv to return "Invalid value specified with -m (0)" but accept the exact same command line when running it manually. Something in the environment must be different between executing the command manually and running DynDOLOD.

 

Have a look at this https://github.com/Microsoft/DirectXTex/issues/128. The mipmap levels also uses swscanf_s to check the value. 

 

You could test with the official version from https://github.com/Microsoft/DirectXTex/releases, renaming it to Texconvx64.exe should work.

 

Do not install DynDOLOD into Steam or Game folders. Is it normal for to have a hidden ".steam" folder in the path?

 

If all else fails, set the textures to use R8G8B8 and R8G8B8A8 in DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini so that TexConv is not executed.

 

For example:

 

ObjectLODDiffuseFormat=87

ObjectLODAlphaDiffuseFormat=88

ObjectLODNormalFormat=87

TreeLODDiffuseFormat=88

 

Then manually convert them once they have been created. You can also set ObjectLODDiffuseFormat=88 if you prefer to have a single object LOD texture.

Edited April 21, 2019 by sheson

[steveowashere]

 

Have a look at this https://github.com/M...XTex/issues/128. The mipmap levels also uses swscanf_s to check the value. 

Yes, this seems to be a wine issue then. I'll try to see if there are any workarounds. Otherwise i'll report it as a bug with wine.

 

 

 

Is it normal for to have a hidden ".steam" folder in the path?

Yes, that's Steam's doing. It puts everything there by default.

 

 

If all else fails, set the textures to use R8G8B8 and R8G8B8A8 in DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini so that TexConv is not executed.

I've tried this, but still the same error. It seems that texconv is still trying to do something. My DynDOLOD_SSE.ini settings for texture format is as follows:

ObjectLODDiffuseFormat=87
ObjectLODAlphaDiffuseFormat=88
ObjectLODNormalFormat=87
TreeLODDiffuseFormat=88

bugreport.txt

DynDOLOD_SSE_log.txt

DynDOLOD_SSE.ini

[sheson]

 

Yes, this seems to be a wine issue then. I'll try to see if there are any workarounds. Otherwise i'll report it as a bug with wine.

 

 

Yes, that's Steam's doing. It puts everything there by default.

 

I've tried this, but still the same error. It seems that texconv is still trying to do something. My DynDOLOD_SSE.ini settings for texture format is as follows:

ObjectLODDiffuseFormat=87
ObjectLODAlphaDiffuseFormat=88
ObjectLODNormalFormat=87
TreeLODDiffuseFormat=88

Ahh right I forgot. It is actually using TexConv to create mipmaps in the first place since that option is quicker than the build-on method. Sorry, looks like you are out of luck at the moment for tree LOD (Object LOD atlas should work because the mipmaps are generated internally). I might add a setting to control that in the next version.

Edited April 21, 2019 by sheson

[steveowashere]

Thanks for the help regardless! That option might be nice to have, but I don't know who else would need it besides crazy people trying to run modded Skyrim under wine.

 

I'll try to figure out if texconv can be fixed under wine in the meantime.

 

Otherwise I have a VM I can just run DynDOLOD there, not ideal, but still possible.

[sheson]

Thanks for the help regardless! That option might be nice to have, but I don't know who else would need it besides crazy people trying to run modded Skyrim under wine.

 

I'll try to figure out if texconv can be fixed under wine in the meantime.

 

Otherwise I have a VM I can just run DynDOLOD there, not ideal, but still possible.

Actually... I can just compile a version of TexConv that defaults to use 0 in case the number of the -m command line can not be determined. Maybe that works out for you.

 

Just replace them both TexConv.exe and TexConvx64.exe in the Edit Scripts folder with this version and see if it works, 

[steveowashere]

 That's a really good idea, but sadly it still is giving the same error. Thanks for the effort.

[sheson]

 That's a really good idea, but sadly it still is giving the same error. Thanks for the effort.

Try this version https://mega.nz/#!9FZBjSqK!v2ksMIYsDyepgQXVLKOz3GGGIYxciuNq47WGG8rnYjk

[steveowashere]

This didn't work either. But, a different error now

FAILED [mipmaps] (80070057)

[Log attached]

 

 

DynDOLOD_SSE_log.txt

[sheson]

This didn't work either. But, a different error now

FAILED [mipmaps] (80070057)

[Log attached]

Grrr, last try I can think of at the moment, see if this works  https://mega.nz/#!gNIxlaLB!xZ6fBbUZLoDrqvtEiNJ-5aiiUPMfDsSmKfR0-253j40

 

If that also fails, wait for next version. It so happens that "-m 0" is the same as not setting it all and it just doing it because formatting the command line is easy that way.

[steveowashere]

Grrr, last try I can think of at the moment, see if this works  https://mega.nz/#!gNIxlaLB!xZ6fBbUZLoDrqvtEiNJ-5aiiUPMfDsSmKfR0-253j40

 

If that also fails, wait for next version. It so happens that "-m 0" is the same as not setting it all and it just doing it because formatting the command line is easy that way.

Sadly, still nothing. Same error as above.

 

I'll try again when the new version drops.

 

Thanks for going above and beyond here, didn't expect so much support for running Windows software via Wine.

[jmarceno]

Hi I'm experiencing a very wierd behaviour with DynDOLOD 2.59 (have not tested other versions), don't really know if it is a bug or an expected behaviour.

 

It will always stop responding and not progress during the atlas creation (waited around an hour a nothing happenned, the screenshot is for this error) if I allow it to use more than 1 physical core. Sometimes it works with 3-4, but is umpredictable at best, with just 1 physical set via affinity, it always works, but takes very, very long time.

 

I'm using the x64 version, as with the x32 I always get a memory access violation, the attached log is for x32 as the x64 does no hard crash, it just stops responding if I use more than 1 physical core, so for the x64 i've attached a screenshot of the process stuck (0% and no change in memory allocation for more than an hour)

 

As the log will show, my desktop (or workstation to be more precise) has an odd configuration, with 2 physical procs, but what is strange to me, is that even if I restrict it to a single physical processor, but using all cores (or more than 1) it causes the same error.

 

 

If I try the Lodgen on EditScripts, I the below text.

 

============================================================
Skyrim Object LOD Generator 2.5.7.0
Created by Ehamloptiran and Zilav
Updated by Sheson

Log started at 11:41:54
Nothing to do
Log ended at 11:41:55 (0:0)
Code: 1
 

 

bugreport.txt

[sheson]

Hi I'm experiencing a very wierd behaviour with DynDOLOD 2.59 (have not tested other versions), don't really know if it is a bug or an expected behaviour.

 

It will always stop responding and not progress during the atlas creation (waited around an hour a nothing happenned, the screenshot is for this error) if I allow it to use more than 1 physical core. Sometimes it works with 3-4, but is umpredictable at best, with just 1 physical set via affinity, it always works, but takes very, very long time.

 

I'm using the x64 version, as with the x32 I always get a memory access violation, the attached log is for x32 as the x64 does no hard crash, it just stops responding if I use more than 1 physical core, so for the x64 i've attached a screenshot of the process stuck (0% and no change in memory allocation for more than an hour)

 

As the log will show, my desktop (or workstation to be more precise) has an odd configuration, with 2 physical procs, but what is strange to me, is that even if I restrict it to a single physical processor, but using all cores (or more than 1) it causes the same error.

 

 

If I try the Lodgen on EditScripts, I the below text.

 

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

Skyrim Object LOD Generator 2.5.7.0

Created by Ehamloptiran and Zilav

Updated by Sheson

 

Log started at 11:41:54

Nothing to do

Log ended at 11:41:55 (0:0)

Code: 1

 

Well typically works fine with multiple cores (and HT) on with one CPU.

 

The multi-threading is a bit brittle with Delphi and me not giving it all the required (if this was paid software) attention to potential deadlocks, resource or memory contention issues. Eventually xEdit and DynDOLOD will switch to the newer Delphi version - which seems to be much more picky in this regard as well. That means some time in the future that might just solve that issue for you.

 

The x86 version most likely just runs out of memory. The next version will use less memory when doing the atlas, so it should be able to create the atlas as well. It might run through require the same treatment as the x64 in your case.

 

The LODGen.exe process is started only once the atlas has been created so it should have no influence on this issue.

[softboy_rodvt]

Hello!

So over the past few days I've been having an issue with DynDOLOD apparently causing a CTD whenever I try to pull up the map from within an interior cell. Removing DynDOLOD's plugins from my load order allows me to use the map as much as I want, but with the plugins if I'm inside of an interior cell I have to exit into a worldspace and re-enter before I can use the map. Using the map when starting a new game with ASLAL, using coc qasmoke from the menu, or loading a save made in an interior cell results in an instant CTD. Because of this, I think it might have something to do with DynDOLOD's initializing process?

I've attached my SKSE log and minidump, and here's a paste of my load order.
 
If there's anything else I should post to help diagnose this I'll do my best