Kraggy

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_Worlds.json JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.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?

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.

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...-doneRegistering functions...-doneStorage Reverting...Done! Storage Loading...MODS LoadLoading mod list...Done! JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.jsonJSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.jsonJSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.jsonJSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel.jsonJSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Tamriel_Objects.jsonJSON 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.0Reading 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. :(

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=1RecordCrashInfo=1WarnBadENB=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=5N4O8S0E8H2S42O3T5T0I8M1B7U0S3plugin=dyndolod.espnearmultiple=1.25farmultiple=1.5nevermultiple=1.75ugrid=10240neargrid=22528fargrid=43008fminsecondsforloadfadein=2.70000004768372debug=false[Worlds]tamriel=tamrielwindhelmworld=tamrielriftenworld=tamrielmarkarthworld=markarthworldwhiterunworld=tamrielblackreach=blackreachskuldafnworld=skuldafnworlddeepwoodredoubtworld=deepwoodredoubtworldsovngarde=sovngardesolitudeworld=tamrielwhiterundragonsreachworld=tamrieljaphetsfollyworld=japhetsfollyworldkatariahworld=tamrielwindhelmpitworldspace=tamriellabyrinthianmazeworld=labyrinthianmazeworlddlc01falmervalley=dlc01falmervalleydlc01soulcairn=dlc01soulcairndlc1hunterhqworld=dlc1hunterhqworlddlc2solstheimworld=dlc2solstheimworlddlc2apocryphaworld=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.pex05/09/2016 14:43 8,182 ___A___________ JsonUtil.pex = C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\JsonUtil.pex15/09/2016 09:19 2,099 ___A___________ MiscUtil.pex = C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\MiscUtil.pex09/05/2016 20:47 999 ___A___________ ObjectUtil.pex = C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\ObjectUtil.pex05/09/2016 13:44 7,955 ___A___________ PapyrusUtil.pex = C:\Modding\Common\VortexMods\skyrim\PapyrusUtil - Scripting Utility Functions-58705-3-3\scripts\PapyrusUtil.pex05/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.pex05/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.pex05/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.pex05/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.pex05/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.pex05/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.pex23/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.

I uploaded one of the crashdumps to the site you linked to and this was the start of its report: 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.

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.

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...-doneRegistering functions...-doneStorage 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.

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 onlyTimer disabledBlock1 Block2512MB 256MB85 885 885 985 1085 11 ... I edited out umpteen lines counting up both memory regions ... 278 98279 98281 98281 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.

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...-doneRegistering functions...-doneStorage Reverting...Done! JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.jsonJSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_Worlds.jsonJSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_.jsonJSON: File does not exist, init empty root object...JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD_.jsonJSON: File does not exist, init empty root object...JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD__Objects.jsonJSON: File does not exist, init empty root object...JSON Loading: Data/SKSE/Plugins/StorageUtilData/DynDOLOD__Objects.jsonJSON: 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.

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=1EnableDiagnostics=1[Memory]DefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256[Debug]WriteMiniDumps=1" 3) PapyrusUtil 3.34) The Unofficial Skyrim Legendary Edition Patch 3.0.13a5) The Unofficial Hugh Resolution Path 1.2.16) ENBSeries 0.357 with these memory settings "[MEMORY] ExpandSystemMemoryX64=falseReduceSystemMemoryUsage=trueDisableDriverMemoryManager=falseDisablePreloadToVRAM=falseEnableUnsafeMemoryHacks=falseReservedMemorySizeMb=128VideoMemorySizeMb=10000EnableCompression=falseAutodetectVideoMemorySize=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.7zVanilla 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.esmDawnguard.esmHearthFires.esmDragonborn.esmUnofficial Skyrim Legendary Edition Patch.espHighResTexturePack01.espHighResTexturePack02.espHighResTexturePack03.espUnofficial High Resolution Patch.espholycow.espDynDOLOD.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.sksedispatch message (2) to plugin listenersno listeners registeredloading co-savedispatch message (3) to plugin listenersno listeners registeredcleared save pathSkyrim 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. :)

Okay, thanks for clearing that up, the log ends with what seemed to be good results: [00:05:29.034] LODGen.exe for LabyrinthianMazeWorld completed succesfully[00:05:29.064] DynDOLOD Worlds completed successfully.[00:29:50.323] [24:24] Saving: DynDOLOD.esp[00:29:51.365] [24:25] Done saving. but I just wanted to be sure as I'm trying to figure out a CTD loading a save after installing DynDOLOD's output. Thank you.

Thanks for that info Sheson, I simply want to remove any unnecessary mods from the modlist as I'm getting a CTD immediately after loading the 3rd of the Autosaves the game creates during a new game and trying to follow the 'readme' on how to figure it out.

The GP video on DynDOLOD shows several mods being added for DynDOLOD to run, such as vanilla billboards and DynDOLOD Resources as well as TexGen's output .ESP, but the video ends without referencing these added mods after DynDOLOD's output has been installed. Also I had to run the LoS patch in DynDOLOD Patches. Are these needed when running the game or can they be disabled leaving only the data in the DynDOLOD outout? Thanks.

First, I've watched the GP video and TexGen/DynDOLOD seem to be basically working but there's an error in the log file from DynDOLOD which I don't understand what it's telling me: "C:\Steam\steamapps\common\Skyrim\Data\ Not allowed!" I found this message was reported by a user in an old thread but that part of his post didn't seem to be addressed as he had another more obvious problem that was then discussed: https://forum.step-project.com/topic/11997-dynamic-distant-objects-lod-dyndolod-227/page-12?hl=not+allowed&do=findComment&comment=204057 I don't have that problem, all I have is the second error the reported. Looking in "C:\Modding\Skyrim LE\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_LODGen preset default.ini" the Data path only exists on one line: which seems perfectly reasonable. Can someone tell me what DynDOLOD is complaining about here and is there anything I need to do to fix it? I have no idea how I can verify if everything worked correctly, I've scanned the log and see nothing a newbie to this would see as an error. The output from DynDOLOD exists with a DynDOLOD.esp of 3.29MB so it created something! Thanks. [edit] FYI, I'm using MO 2.1.5, the GP video was for MO1 and pointed out the "let MO manage archive" checkbox that MO2 doesn't have, I presumed this step isn't therefore needed but I mention it in case it's relevant.

I thought the hooking mechanic was likely to be the cause of the A/V taking interest, but there's no complaints from it, MO simply goes into its locked state then shortly after unlocks and the output pane shows the sub-process has ended. I DID get a moan from the Acronis imaging system I use for backups, it has some kind of anti-malware in it that I wasn't aware of till now (and is now disabled) but Malwarebytes has never uttered a peep. Thanks for at least letting me know this is a 'tech' issue that's likely not avoidable, I'll have to find some way of controlling the A/V when running MO.

Forgot to say, there are no USVFS logs in MO2's log folder for the failed sessions .. also, the problem will occur running any tool, such as the Skyrim launcher directly instead of via SKSE64 so it doesn't seem to be an SKSE64 problem, even though the 'bad' SKSE log seems to show SKSE has a problem that couldn't be the case running, say, LOOT.

So I've read the info in the Github "troubleshooting" page telling you to disable A/V, but are the MO devs really not interested in trying to make MO work with such critical tools? In the hope that they may at least be interested in this problem I'll post this here even though it may simply be deleted as breaking the rules. I'm using MO2 2.1.5 on Skyrim SE, and have a totally repeatable problem; the first time I run something from MO2 (usually of course SKSE) it'll work, the game will run just fine, but most of the time after the first time it won't run. Sometimes, maybe 1 in 10 or so, it will, mostly it doesn't. Exiting MO2 and re-loading doesn't work, however 100% of the time if I Quit Malwarebytes it works and carries on working. Comparing the SKE64 logs for the 'good' and 'bad' cases shows no difference in SKSE64.log and SKSE64_loader.log except for process IDs, memory handles, etc., but SKSE64_steam_loader.log shows the problem. In the 'good' case there's this: while in the 'bad' case all there is is this: Clearly the A/V is causing some process hooking mechanic to fail (I'm not deep enough into process hooking to begin to know what may be going on) and it seems MO2 is exiting without any error information to go on. Like I say, I know A/Vs are supposed to be disabled if they cause problems but frankly, with a tool like MO being used to run a game the MUST connect to the Internet (and of course it does so itself too) disable A/V isn't really appealing. :)

Aha! So the DX9 DLL is a dummy version of a standard DLL, that thought never occurred to me. The Windows search order is well known to me so I realised it would pick up the local DLL and assumed this was needed as maybe a standard Windows system may not have this particular DX DLL. Having now looked at the DLL in a hex editor I can now see text strings inside it referencing ENB function names which presumably are arguments to GetProcAddress() and from your description the point at which he calls down to the 'real' DX DLL; what a cute programming trick, simple when you figure it but not something that's immediately obvious! While watching some of Weasel's videos (as I mentioned in another thread I had posted and which you had kindly replied in) I saw what I now presume is another of these DLLs called something like D3DX9_42.dll which I assume is another of these; I forget which mod. this was part of I'll have to re-scan the videos to find it again. In that case I saw both DLLs were present in the Skyrim directory so I guess that's another DX DLL someone 'hijacked' for this trick. I appreciate the help, understanding this was important to me as I was delving into the more technical side of what mods do. :)

Thanks Greg, I was poking around YouTube last night and came across another series of Weasel's videos which looked at modding SkyrimSE. I had initially not looked at those because he started before MO2 was released and was using NMM, but then I say that mid-way through the series MO2 had been released and he moved over to that and has one video looking at both migrating from MO1 and a 'cold install' of MO2, that video was extremely helpful and gave me an understanding of the issue I raised here as well as others that were confusing me. I've decided to abandon trying to re-mod Skyrim LE .. I was still trying to use LE since (a) STEP isn't anywhere near finished for SE and (b) there are some LE mods that aren't available for SE .. but it's clear now that the time I'll spend learning my way round MO (1 or 2) would be better spent on SE, while keeping Vortex as a replacement for NMM for my existing LE setup. Thanks.

Okay, thanks for that, as I saw when I did use the dummy .ESP the .BSA was enabled. Since posting my question I came across a GamerPoets video talking about migrating from MO1 to MO2 where it had an explicit section on this aspect for those moving to MO2, had I seen that before I'd not have troubled you. :) While trying to find the answer before posting here I went hunting for an MO2 'manual' but all I could find is this one https://wiki.step-project.com/Guide:Mod_Organizer which doesn't say what version is it but seems clearly to be MO1, is there something similar for MO2? Without it I fear following the MO1 docs is going to end in tears when differences in functionality exist, such as this. Thanks, I appreciate the help.

So an update on this, I discovered that Weasel in a later video updated his version of the Unofficial Patch and in doing so made what I think is an important difference in the way he installed it. The first time round (as in the video I linked to) he DIDN'T install the .ESP from the download, and at 5:18 in the video he shows the PLUGINS tab doesn't have a listing for the Patch, but when he installed the update is DID install the .ESP and, as expected, a PLUGINS entry for it was made. I did the same thing and found the NOW the .BSA checkbox is SET and after some playing around it seems clear that the absence of the .ESP is the reason in my first install the .BSA was UNCHECKED. So, one problem I had is resolved, the .BSA is now CHECKED, however I'm still left with not understanding why all the .BSA entries are grayed out .. I've now installed SKYUI and it's in the same state. Is this a problem? It's different from MO1, obviously, but is it a problem I need to worry about? Thanks.

I'm following the STEP guide while also watching videos such as Dirty Weasel's, eg. since I've never used MO before and have hit a problem with MO2 while doing so. I realise Weasel was using MO1 and now we're on MO2 so it's possible that this is a change in MO2 but at the moment I don't know how to proceed. I've installed the "Unofficial High Resolution Patch" as per the video and it's in the Left Pane and enabled but then I hit the problem. At timestamp 5:21 in the video he shows going to the Archives tab in the Right Pane, scrolling down and setting the checkbox against "Unofficial High Resolution Patch.bsa" but that line is grayed out; when I expand the "Unofficial High Resolution Patch" node in the Archive tab the line for the .BSA with a checkbox is grayed out and the checkbox is NOT SET. Also, the .BSA lines for the "DLC: HighResTexturePack" nodes are also grayed out, but in those cases the checkbox is SET. The fact that in my system all these BSAs are grayed out and in the video they're not makes me think I haven't setup MO2 correctly but I see nothing in the program or the installation steps I followed which would explain this; it's as if MO2 is telling me I can't manage the archives in MO2, I notice that in the video there's a checkbox in MO1 that enables this, in my MO2 there's no such checkbox. Can someone suggest what is wrong here and how I can fix it? Thanks.

I've followed the steps in the guide about installing ENBoost ( https://wiki.step-project.com/ENBoost#Recommendations ) and have the three listed files in the SKYRIM base directory but as far as I can see they're not actually 'wired in' anywhere; nothing refers to ENBOOST.exe in any .INI or otherwise. Yet in Task Manager I see ENBOOST is listed as part of the SKYRIM LAUNCHER process so 'something' ran it, but how? I realise this isn't a 'problem' with STEP but I don't know anywhere else but here where I could ask about this and Googling found many mentions of ENBoost but no mention of just HOW it runs, and I don't like something 'magically happening' without understanding it, so I'm hoping you'll pardon the 'off topic' nature of this post.

I always hated Bethesda used Steam for their DRM, life was so much easier back with Morrowind just for this kind of thing. I'll take a look at the effort it'll require to set up an MO2 implementation of my Vortex setup so that I can use MO2's tech. to allow side-by-side modding with a tool that can obviously cope, if that doesn't look useful I'll archive my current installation and create a new one for STEP. Thanks a lot for taking the time to look at what I'm wanting to do and giving it some thought, you have at least confirmed my fears that there are technical issues that could cause me pain. :(

Oh, if only Vortex was built on the same architecture as MO/MO2 you'd be correct that I wouldn't need two installations, but sadly Vortex doesn't use a 'virtual' system like MO, it uses NTFS Hard Links. I know how Links work and I have some idea of how MO's virtual system is implemented by API hooks, what I have no idea is whether these two techs work together or fight each other. Obviously I could 'suck it and see' but unless I can be confident things will 'just work' then I don't want to risk destroying my current game .. and history tells us that Morrowind/Oblivion/Skyrim can break over time and a re-start from a 'good' save can take you a back a long time in the past. :(