Immediate CTD On Vanilla Oldrim

Kraggy · December 1, 2018

After finding it impossible to diagnose a CTD when I added DynDOLOD to an existing Skyrim LE (Oldrim) installation I set up a completely new one, from scratch, using Vortex (to eliminate MO2 which I was using previously and with which I had several 'odd' experiences with its hooking mechanic).

Sadly, even after all this I am still getting a CTD a second or so after a character loads into the game. I really can't see how it's something I've done or not done, yet I also can't believe DynDOLOD is broken in such a basic way, so I'm posting this in the hope someone can give me an idea where to look; I have read some debugging document but it was for SE and referred to a DynDOLOG log file (with [GAMEMODE] in its name) which I don't have and presume is an SE-only feature.

The system on which this is happening has only the following additions to what is installed by Steam:

1) The masters are clean, as evidenced by running LOOT, after following the STEP notes.

2) SKSE 1.7.3 is installed using this .INI

"[Display]

iTintTextureResolution=2048

[General]

ClearInvalidRegistrations=1

EnableDiagnostics=1

[Memory]

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

[Debug]

WriteMiniDumps=1"

3) PapyrusUtil 3.3

4) The Unofficial Skyrim Legendary Edition Patch 3.0.13a

5) The Unofficial Hugh Resolution Path 1.2.1

6) ENBSeries 0.357 with these memory settings

"[MEMORY]

ExpandSystemMemoryX64=false

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=128

VideoMemorySizeMb=10000

EnableCompression=false

AutodetectVideoMemorySize=false"

I ran DynDOLOD using:

TexGen.exe 2.54.0.0 29/11/2018 (1300041408)

DynDOLOD.exe 2.54.0.0 29/11/2018 (1300041408)

LODGen.exe 2.5.2.0 23/11/2018 (1299648096)

DynDOLOD Resources-59721-2-45-1541431877.7z

Vanilla Skyrim and Dragonborn billboards High Res 1024 version 1.4.0

Since I'm new to Vortex I may not know the correct place to look but I think the load order is in AppData\Local\Skyrim\loadorder.txt:

"Skyrim.esm

Update.esm

Dawnguard.esm

HearthFires.esm

Dragonborn.esm

Unofficial Skyrim Legendary Edition Patch.esp

HighResTexturePack01.esp

HighResTexturePack02.esp

HighResTexturePack03.esp

Unofficial High Resolution Patch.esp

holycow.esp

DynDOLOD.esp"

I run the program using a save which was created just after a new character exited the Helgen intro sequence. As I say, within a second or two of the character appearing the game CTDs, when I disable the DynDOLOD_Output mod the crash doesn't happen.

SKSE creates a CrashDump file but it's 0 bytes long, SKSE's log file as these lines at the end

"save name is Save 3 - Kerin Skyrim 00.37.23

full save path: C:\Users\robin\Documents\My Games\Skyrim\Saves\\Save 3 - Kerin Skyrim 00.37.23.skse

dispatch message (2) to plugin listeners

no listeners registered

loading co-save

dispatch message (3) to plugin listeners

no listeners registered

cleared save path

Skyrim has crashed in a known crash location (on exit while destroying TESIdleForms). No crashdump will be written in release builds."

As far as I can see I've configured what the GP DynDOLOD video refers to "Sheson's memory patch" correctly and have nothing except the absolute minimum of mods which are needed to create and run DynDOLOD; I decided not to add SkyUI as the GP video said that is not required (although clearly it's very helpful) so as not to add more moving parts.

I apologise for this long post but hopefully you can see that I've no idea how to proceed to diagnose what I presume is a very simple problem but one which I've spent the last day trying to deal with. I absolutely expect it's something stupid I've done (or not done) but I don't know what else to read that I haven't already done so, several times. :)

Edited December 1, 2018 by Kraggy

sheson · December 1, 2018

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 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.

From the manual

Configuration files and settings use the game mode as identifier. It is TES5 for Skyrim, SSE for both Skyrim Special Edition and Skyrim VR and ENDERAL for Enderal. Throughout the documentation substitute the 'x' like in xEdit.exe or the [GAMEMODE] like in 'DynDOLOD_[GAMEMODE].ini' with the current game mode.

So whenever you see [GAMEMODE] substitute it with TES5

Test with new game by using coc whiterun from main menu.

Nobody should be using Vortex voluntary unless you want to help beta test it.

Edited December 1, 2018 by sheson

Kraggy · December 1, 2018

I just found this slightly different behaviour loading a save taken still in the Helgem sequence right before exiting into the game world for the first time.

While the Papyrus log in the first crash only contained the initialisation text, the one from this case has the following:

"Loading Version: 33

Init...

-done

Registering functions...

-done

Storage Reverting...

Done!

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_.json

JSON: File does not exist, init empty root object...

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_.json

JSON: File does not exist, init empty root object...

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD__Objects.json

JSON: File does not exist, init empty root object...

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD__Objects.json

JSON: File does not exist, init empty root object..."

Also this time SKSE created a crash dump but I don't know what tool can be used to look at it, like before I did find some comments on these but they were based on SE and so I have no idea if they're relevant.

sheson · December 1, 2018

To test if there is a problem with DynDOLOD using PapyrusUtil, test with the alternative DynDOLOD DLL to see if it makes a difference.

Kraggy · December 1, 2018

Thanks for the reply Sheson.

I have seen those references before but thought that such a basic system as I have wouldn't need extensive debugging, after all it's nothing more than the vanilla game with common tools and installed using a well know and long standing method.

Anyhow, I ran with Memory Blocks Log but frankly don't know what an 'error' would look like:

"logging of blocks enabled

logging max values only

Timer disabled

Block1 Block2

512MB 256MB

85 8

85 9

85 10

85 11

... I edited out umpteen lines counting up both memory regions ...

278 98

279 98

281 98

281 99"

As far as I can see this confirms I have configured the SKSE memory patch correctly as it shows Block 1 is 512Mb which I believe it what that patch does.

[edit]

I was typing this reply as you posted your second one, I'll go look at that replacement DLL now.

Edited December 1, 2018 by Kraggy

Kraggy · December 1, 2018

I download what I think was the correct file from the link you gave me, installed it into Vortex and verified it seemed to be correct as I saw a DynDOLOD.DLL appear in the Data\SKSE\pligins folder, it is dated 5 November 2018.

The game still crashed, though this time I didn't see the PapyrusUtil log output I posted before, this time it was like it was previously, only having these lines:

"Loading Version: 33

Init...

-done

Registering functions...

-done

Storage Reverting...

Done!"

Also, the MemoryBlocksLog.log file ended at "203 99".

I disabled the replacement DLL and once more the PapyrusUtil log showed the JSON: output, while the MemoryBlocksLog.log ended at the '203' line again.

sheson · December 1, 2018

The memory patch is working correctly.

The minidump can be upload here http://www.osronline.com/page.cfm?name=Analyze

This is how the PapyrusUtil log should look when everything is installed correctly:

Loading Version: 33

Init...

-done

Registering functions...

-done

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel_Objects.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.json

In case DynDOLOD can not properly resolve the worlds name (to Tamriel) it usually uses "None" instead of empty as the log lines you posted seem to indicate. There should be some kind of message on screen (but it might not have the time to show them) or maybe something in the Papyrus logs. But same problem, it might not have the time to actually get out the message in time.

Generally, make sure that none of the SKSE, PapyrusUtil and DynDOLOD Resources papyrus scripts are overwritten by older versions. It can also happen that an archive gets not fully unzipped so that not all files are installed.

Only DynDOLOD DLL papyrus scripts should overwrite the DynDOLOD Resources papyrus script in case you want to use DynDOLOD DLL.

If all that seems to be in order install Crash Fixes. If that doesn't pop up with a human readable error message, enable the debug mode as explained in readme and then check/upload/pastebin the papyrus log.

If the log doesn't reveal anything, upload/pastebin the contents of SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.json and SKSE/Plugins/DynDOLOD_Data/DynDOLOD_Worlds.txt so I can verify if it is OK.

Edited December 1, 2018 by sheson

Kraggy · December 1, 2018

Okay, now I see the Papyrus output isn't what you'd expect, so I guess that's likely going to be the cause of the crash somewhere down the line.

Just FYI, I went ahead and installed the pre-load DLL tools you referred to earlier "Or use 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 "

After doing so and ensuring OSAllocator was set to 1 I got the following output in CrashFixPluginsLog.txt

"01 Dec 13:04:59 Game has crashed with exception address 0xC500B0!"

I'll go take a closer look at the parts of the system you just referred to.

I really appreciate this help Sheson, without it I'd simply have abandoned my attempts after finding the problem even existed with such a 'vanilla' and simple game setup. I'll get back to you when I've done the research.

sheson · December 1, 2018

upload the minidump to http://www.osronline.com/page.cfm?name=Analyze and post its output. While chances are slim it might tell something of use.

To clarify, when I say payrus log I mean c:\Users\[username]\Documents\My Games\Skyrim\Logs\Script\Papyrus.0.log, so check that in addition to the log from PapyrusUtil.

It might give an idea how the game got before it crashed.

Kraggy · December 1, 2018

I uploaded one of the crashdumps to the site you linked to and this was the start of its report:

FAULTING_IP:
TESV+8500b0
00c500b0 8b4204 mov eax,dword ptr [edx+4]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00c500b0 (TESV+0x008500b0)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000004
Attempt to read from address 00000004

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_READ

PROCESS_NAME: TESV.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000004

READ_ADDRESS: 00000004

FOLLOWUP_IP:
TESV+8500b0
00c500b0 8b4204 mov eax,dword ptr [edx+4]

FAULTING_THREAD: 00000218

PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_READ

Not much use I guess, since it died in the TESV.exe rather than another identifiable user-added module, I'll pursue the script issue in a bit.

Kraggy · December 1, 2018

For this test I removed the stand-alone DynDOLOD.DLL to go back to the current DynDOLOD release and re-checked my setup for Crash Fixes and have these flags enabled, as cut/pasted from C:\Steam\steamapps\common\Skyrim\Data\SKSE\Plugins\CrashFixPlugin.ini

"[Patch]

UseOSAllocators=1

RecordCrashInfo=1

WarnBadENB=1"

When the crash happens this is the info that gets written to the file in Data\Plugins\CrashLog

"Crash info:

2018_12_01_14-03-18 - C500B0: V(1); EAX(0); EBX(1BA7020); ECX(0); EDX(0); ESI(2C169140); EDI(0); EBP(EAB6438); ESP(2146E5D8); STACK(4D94F2 C60260 C60337 EBFB90 E30F9B EC0BC4 E30F9B EBFD5F E30F9B EC0BC4 E30F9B FFFFFF 55E377);

Not so useful info (don't post unless asked):

...<SNIP>..."

which simply shows the same crash point as the dump analyzer did. You asked about these DynDOLOD files on the Data\SKSE\Plugins directory:

DynDOLOD_Worlds.json

{

"string":{

"plugin":"dyndolod.esp",

"tamriel":"tamriel",

"windhelmworld":"tamriel",

"riftenworld":"tamriel",

"markarthworld":"markarthworld",

"whiterunworld":"tamriel",

"blackreach":"blackreach",

"skuldafnworld":"skuldafnworld",

"deepwoodredoubtworld":"deepwoodredoubtworld",

"sovngarde":"sovngarde",

"solitudeworld":"tamriel",

"whiterundragonsreachworld":"tamriel",

"japhetsfollyworld":"japhetsfollyworld",

"katariahworld":"tamriel",

"windhelmpitworldspace":"tamriel",

"labyrinthianmazeworld":"labyrinthianmazeworld",

"dlc01falmervalley":"dlc01falmervalley",

"dlc01soulcairn":"dlc01soulcairn",

"dlc1hunterhqworld":"dlc1hunterhqworld",

"dlc2solstheimworld":"dlc2solstheimworld",

"dlc2apocryphaworld":"dlc2apocryphaworld",

"bunchofnumbers":"5N4O8S0E8H2S42O3T5T0I8M1B7U0S3",

"debug":"false"

},

"int":{

"tamriel":4710,

"windhelmworld":4710,

"riftenworld":4710,

"markarthworld":19184,

"whiterunworld":4710,

"blackreach":22424,

"skuldafnworld":21020,

"deepwoodredoubtworld":22085,

"sovngarde":21388,

"solitudeworld":4710,

"whiterundragonsreachworld":4710,

"japhetsfollyworld":23547,

"katariahworld":4710,

"windhelmpitworldspace":4710,

"labyrinthianmazeworld":24028,

"dlc01falmervalley":22792,

"dlc01soulcairn":19386,

"dlc1hunterhqworld":22247,

"dlc2solstheimworld":17327,

"dlc2apocryphaworld":20402

},

"float":{

"nearmultiple":1.25,

"farmultiple":1.5,

"nevermultiple":1.75,

"ugrid":10240,

"neargrid":22528,

"fargrid":43008,

"fminsecondsforloadfadein":2.70000004768372

}

DynDOLOD_Worlds.txt

[Config]

bunchofnumbers=5N4O8S0E8H2S42O3T5T0I8M1B7U0S3

plugin=dyndolod.esp

nearmultiple=1.25

farmultiple=1.5

nevermultiple=1.75

ugrid=10240

neargrid=22528

fargrid=43008

fminsecondsforloadfadein=2.70000004768372

debug=false

[Worlds]

tamriel=tamriel

windhelmworld=tamriel

riftenworld=tamriel

markarthworld=markarthworld

whiterunworld=tamriel

blackreach=blackreach

skuldafnworld=skuldafnworld

deepwoodredoubtworld=deepwoodredoubtworld

sovngarde=sovngarde

solitudeworld=tamriel

whiterundragonsreachworld=tamriel

japhetsfollyworld=japhetsfollyworld

katariahworld=tamriel

windhelmpitworldspace=tamriel

labyrinthianmazeworld=labyrinthianmazeworld

dlc01falmervalley=dlc01falmervalley

dlc01soulcairn=dlc01soulcairn

dlc1hunterhqworld=dlc1hunterhqworld

dlc2solstheimworld=dlc2solstheimworld

dlc2apocryphaworld=dlc2apocryphaworld

Finally from the crash run, the Papyrus log file shows the same 'empty' world name as you observed before.

You also mentioned possible script conflicts, I have a command-line tool with an enhanced DIR command which shows the resolution on Hard Links which shows these files in the Scripts directory (I've only shown the scripts being changed by mods added in Vortex, all the rest in Scripts are from the SKSE 1.7.3 release archive):

"Directory of C:\Steam\steamapps\common\Skyrim\Data\scripts\*

10/09/2015 04:21 929 ___A___________ ActorUtil.pex

= C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\ActorUtil.pex

05/09/2016 14:43 8,182 ___A___________ JsonUtil.pex

= C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\JsonUtil.pex

15/09/2016 09:19 2,099 ___A___________ MiscUtil.pex

= C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\MiscUtil.pex

09/05/2016 20:47 999 ___A___________ ObjectUtil.pex

= C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\ObjectUtil.pex

05/09/2016 13:44 7,955 ___A___________ PapyrusUtil.pex

= C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\PapyrusUtil.pex

05/11/2018 01:45 617 ___A___________ SHESON_DynDOLOD_Alias.pex

= C:\Modding\Common\VortexMods\skyrim\DynDOLOD Resources-59721-2-45-1541431877\Scripts\SHESON_DynDOLOD_Alias.pex

05/11/2018 01:45 14,476 ___A___________ SHESON_DynDOLOD_Firstborn.pex

= C:\Modding\Common\VortexMods\skyrim\DynDOLOD Resources-59721-2-45-1541431877\Scripts\SHESON_DynDOLOD_Firstborn.pex

05/11/2018 01:45 14,034 ___A___________ SHESON_DynDOLOD_LODObject.pex

= C:\Modding\Common\VortexMods\skyrim\DynDOLOD Resources-59721-2-45-1541431877\Scripts\SHESON_DynDOLOD_LODObject.pex

05/11/2018 01:45 8,766 ___A___________ SHESON_DynDOLOD_Master.pex

= C:\Modding\Common\VortexMods\skyrim\DynDOLOD Resources-59721-2-45-1541431877\Scripts\SHESON_DynDOLOD_Master.pex

05/11/2018 01:45 23,753 ___A___________ SHESON_DynDOLOD_MCM.pex

= C:\Modding\Common\VortexMods\skyrim\DynDOLOD Resources-59721-2-45-1541431877\Scripts\SHESON_DynDOLOD_MCM.pex

05/11/2018 01:45 4,234 ___A___________ SHESON_DynDOLOD_Quest.pex

= C:\Modding\Common\VortexMods\skyrim\DynDOLOD Resources-59721-2-45-1541431877\Scripts\SHESON_DynDOLOD_Quest.pex

23/03/2016 20:59 19,558 ___A___________ StorageUtil.pex

= C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\StorageUtil.pex"

I hope somewhere among all this is something that catches your eye, right now I don't see any more debugging options in the .INI files I'm aware of I can turn on.

Kraggy · December 1, 2018

Okay, so I think I found one problem here .. wrong mod order!

Being new to Vortex I wasn't really aware of how it ordered mods and I guess hadn't concentrated enough on that aspect and I realised it was saying Papyrus was loading AFTER DynDOLOD which seemed to be wrong even though the DIR listing I posted before looked okay to me, so I reordered them with Papyrus before DynDOLOD and ...

... the game still crashed. :(

BUT, the Papyrus log is critically different:

"Loading Version: 33

Init...

-done

Registering functions...

-done

Storage Reverting...

Done!

Storage Loading...

MODS Load

Loading mod list...

Done!

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel_Objects.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel_Objects.json"

also, I noticed a DynDOLOD log file:

"DynDOLOD Plugin 2.45.0 for Skyrim Script Extender 1.7.3 for Skyrim 1.9.32.0

Reading file C:\Steam\steamapps\common\Skyrim\Data\SKSE\Plugins\DynDOLOD_Data\DynDOLOD_worlds.txt"

So the missing world name is resolved but seems to have been a re-herring, the crash still occurs at the same point:

"01 Dec 14:57:11 Game has crashed with exception address 0xC500B0!"

No nearer a solution I fear. :(

Edited December 1, 2018 by Kraggy

sheson · December 1, 2018

Please post the papyrus log with debug set to true in the DynDOLOD worlds json.

Generate LOD from scratch in case the load order of plugins changed (not counting PapyrusUtil)

I would suggest if possible, to make the game folder vanilla, then fully manual install SKSE, resources, DynDOLOD DLL, generate LOD and install manually as well. Not need for holycow.esp

Kraggy · December 1, 2018

Okay, I'll do that .. I originally did start off this clean install manually but in the end it seemed a bit easier, though with hindsight Vortex made it harder to fine-tune the mod order, I'll do it all by hand this time.

Thanks.

Kraggy · December 1, 2018

Well that took some time :), but sadly after a complete re-installation the game CTDed as it did earlier.

I did a manual clean install using downloads from Nexus today (except for the DynDOLOD DLL which was from the link you provided earlier):

1) A fresh download from Steam

2) The .ESMs were cleaned as per S.T.E.P. including the 3 wild edits in Dawnguard, LOOT showed no errors

3) SKSE 1.7.3 and PapyrusUtil 3.3 were installed and a SKSE.INI was created like this:

[Display]

iTintTextureResolution=2048

[General]

ClearInvalidRegistrations=1

EnableDiagnostics=1

[Memory]

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

[Debug]

WriteMiniDumps=1

4) DynDOLOD DLL and its scripts were installed from DynDOLOD-DLL+Scripts-TES5.1.9.32.7

5) The DynDOLOD Resources were installed from DynDOLOD Resources-59721-2-45-1541431877.7z, only the 00 'core' content was installed

6) Billboards were installed from Vanilla Skyrim and Dragonborn billboards High Res 1024-75269-1-4.7z

I didn't include anything else, not even the Unofficial patches, I wasn't sure which order to do the DynDOLOD steps, but the scripts seemed to have the same timestamps so I presumed the order didn't matter.

After this a Save from earlier in the day was loaded to check things were okay at this point, this save was entirely 'vanilla' with no mods at all being required.

Once this was done I ran TexGen, which failed, complaining about the lack of an [Archive] section in Skyrim.ini.

Looking at the .INI from my earlier attempts I found this section, along with much else wasn't in the new .INI but then rembered the GP video does mention this, so as a quick fix I simply copied the whole Skyrim.INI from the morning's attempts and TexGen was then happy to create the output textures, which looked on the face of it the same as the earlier runs.

I copied the 'textures' directory in the TexGen output directory to Skyrim\Data and let it overwrite any conflicts and then ran DynDOLOD with these settings:

1) All worlds selected.

2) Medium quality, no load rules for Candles or FXGlow.

3) All 'generate' options were set, but the options on the right (Windows, Fake..., etc.) were not set.

The files in DynDOLOD_Output (the .ESP was a bit smaller than before but I put that down to my not including the Unofficial patches this time) were copied to Skyrim\Data and then I ran the game to get to the initial menu to enable the DynDOLOD.esp in plugins.txt.

As you requested I set the DEBUG value in DynDOLOD_worlds.json to "true" and ran the game in the same way I did before doing the DynDOLOD steps:

"Loading Version: 33

Init...

-done

Registering functions...

-done

Storage Reverting...

Done!

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel_Objects.json

JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel_Objects.json"

There doesn't seem to be any more debug output than se saw before yet this is what's in "Data\SKSE\Plugins\StorageUtilData\DynDOLOD_Worlds.json":

"

{

"string":{

"plugin":"dyndolod.esp",

"tamriel":"tamriel",

...<SNIP>...

"bunchofnumbers":"3N3O0S8E0H7S18O4T31T7I0M0B0U3S8",

"debug":"true"

},

"

Did I change the wrong JSON, I don't think there's another one anywhere? Do I have to proccess this file in some way for the change to take effect?

Checking the SKSE logs they looked like before, crashdumps were created but were empty. Right now I'm utterly devoid of ideas, this thing looks pretty simple, if a bit involved when doing manual mod installs, and yet it's crashing on such a relatively simple DynDOLOD setup.

I am using the right DynDOLOD for the LE version of Skyrim aren't I? I haven't somehow got hold of an 'SE' version?

Edited December 1, 2018 by Kraggy

sheson · December 1, 2018

The debug in the json/txt world file is for the papyrus scripting as explained in the readme.

It will cause the papyrus scripts from DynDOLOD to print additional info to the papayrus log c:\Users\[username]\Documents\My Games\Skyrim\Logs\Script\Papyrus.0.log, which needs to be enabled in the Skyrim.INI

I have to wonder why the archive setting was not in the INI though. That means it was not default. To make sure there no weird settings in INIs causing general problems make sure to make them default. You do this by removing them and starting the launcher.

Keep a backup for later.

Edited December 1, 2018 by sheson

Sign In

Immediate CTD On Vanilla Oldrim

Question

Kraggy

Top Posters For This Question

Popular Days

Top Posters For This Question

Popular Days

35 answers to this question

Recommended Posts

sheson

Kraggy

sheson

Kraggy

Kraggy

sheson

Kraggy

sheson

Kraggy

Kraggy

Kraggy

sheson

Kraggy

Kraggy

sheson

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Forums

Forum Activity

Game Guides

Nexus

Important Information