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

[sheson]

Sent a PM.  Thank you!

To help me troubleshoot, could you load the entire load order without the DynDOLOD plugins into xEdit and let it build the reference info for all plugins (no need for the vanilla ones). Right click anywhere in the left tree view, select Other, Build Reference Info. It will only list the ones for which the info wasn't built yet.

 

Then lookup 000B679A and 0002ED7A, click the "Referenced By" tab at the bottom of the right window and let me know which plugins use those base records?

 

I only need to know the names of the non-vanilla plugins. If the list is long, just make a screenshot.

Edited July 5, 2018 by sheson

[PMBagpuss]

Sent the images via drive/pm. 

 

Non-vanilla plugins listed against

 

000b679a

Winterhold Restored.esp

Legacy of the Dragonborn.esp

 

0002ed7a

JK's Skyrim.esp

Winterhold Restored.esp.

[LukeCreed13]

Since you are using MO and most likely never used the in-game MOD menu or other mod managers that do not have virtualization there is nothing odd about not having a plugins.txt in that folder.

 

 

See what happens when you execute the x86 version DynDOLOD.exe

 

See what happens when you set IgnoreLargeReferences=1 in the INI.

 

Test if xEdit can add a new plugin by opening the entire load order in xEddit and then creating an overwrite for any record in any plugin.

For example type form id 7 into the field top left to bring up the Player, right click the entry in the left tree view, select Copy as override into..., check <new file>, enter a filename and click OK etc. No need to save if it worked.

Sorry for the late reply, I tried each of the things you suggested me. Running the x86 version resulted in an access violation error. Setting IgnoreLargeReferences to 1 resulted, again, in an access violation error. I can add a new plugin with xEdit without problems though. So I decided to do a full reinstall of Skyrim Special Edition, reinstalled the game, the mods and DynDOLOD, but I still get an access violation version. Trying again to run the x86 version and make changes to the INI didn't work - but still, I can make a plugin in xEdit without any problem.

Edited July 6, 2018 by LukeCreed13

[sheson]

Sorry for the late reply, I tried each of the things you suggested me. Running the x86 version resulted in an access violation error. Setting IgnoreLargeReferences to 1 resulted, again, in an access violation error. I can add a new plugin with xEdit without problems though. So I decided to do a full reinstall of Skyrim Special Edition, reinstalled the game, the mods and DynDOLOD, but I still get an access violation version. Trying again to run the x86 version and make changes to the INI didn't work - but still, I can make a plugin in xEdit without any problem.

Not being able to add plugins from scratch is rather odd and smells of UAC or antivirus interfering or something with MO. So far you are the only one with this problem ever.

See if starting DynDOLOD directly works. You would have to install Resources directly into data for that test. Should be easy to remove is nothing else is installed to data.

 

I will see if I can add a better message to the next version so we might see what is going on.

Edited July 6, 2018 by sheson

[LukeCreed13]

Not being able to add plugins from scratch is rather odd and smells of UAC or antivirus interfering or something with MO. So far you are the only one with this problem ever.

See if starting DynDOLOD directly works. You would have to install Resources directly into data for that test. Should be easy to remove is nothing else is installed to data.

 

I will see if I can add a better message to the next version so we might see what is going on.

Tried to run both DynDOLOD and DynDOLODx64 outside of MO2 and I still get an access violation error. Even tried to reboot the system in safe mode just in case and run both again, but still access violation error. Well, if nothing works, I might just wait for a future update of DynDOLOD, but I think it's something related to my system's UAC anyway, even If I have it already set at the lowest level.

[Flups]

Hi, when I run Texgen64.exe out of MO2 it stops at removing temporary files. No matter if MO2 runs as administrator or not.

Can someone help ?

Thank you very much.

Edited July 7, 2018 by Flups

[sheson]

Hi, when I run Texgen64.exe out of MO2 it stops at removing temporary files. No matter if MO2 runs as administrator or not.

Can someone help ?

Thank you very much.

"Something" is preventing TexGen from removing temporary files. Fix/Remove that "something". Could be UAC, antivirus, MO2 etc.

 

Pay attention to the install instructions and which folders not to install into.

 

All LOD textures have been generated at that point. You can close (kill) TexGen and delete the DynDOLOD-temp folder and all its contents in the TexGen output folder manually.

[Flups]

"Something" is preventing TexGen from removing temporary files. Fix/Remove that "something". Could be UAC, antivirus, MO2 etc.

 

Pay attention to the install instructions and which folders not to install into.

 

All LOD textures have been generated at that point. You can close (kill) TexGen and delete the DynDOLOD-temp folder and all its contents in the TexGen output folder manually.

Thanks a lot. I will check everything ! For now I chose the manual option to try how it is going with DynDOLOD64.exe.

[sheson]

Tried to run both DynDOLOD and DynDOLODx64 outside of MO2 and I still get an access violation error. Even tried to reboot the system in safe mode just in case and run both again, but still access violation error. Well, if nothing works, I might just wait for a future update of DynDOLOD, but I think it's something related to my system's UAC anyway, even If I have it already set at the lowest level.

Get beta 2.41 and see if it works. If not post/upload ..DynDOLOD/bugreport.txt that should be created in same folder as *.exe

[supersemantic]

Hello, I'm sorry if this is well-trodden ground or something, but I'm running into the above issue trying to run DynDOLOD for Skyrim SE. I attached both the full log file and a specific portion of the log file that's relevant, since poking around in xEdit told me that that cell in particular is a part of the WhiterunWorld worldspace (1A26F). More specifically, it's an unlabeled bit of Sub-Block 1, -1 of Block 0, -1, at <8, -4>.

 

Now I'm gonna be honest, I have no clue what any of that actually means. But for whatever reason DynDOLOD has a problem with it. I checked for errors on that cell with xEdit, and also ran an error check for Skyrim.esm itself. While Skyrim.esm had quite a number of errors, xEdit never found any problem with that cell itself. It found a handful of errors that mention Whiterun at all, but none of them have to do with the cell, and only a couple have to do with WhiterunWorld at all. I went ahead and attached a snippet of the xEdit log for that, too.

Is this just something that I'm doing wrong because I'm dense? It wouldn't be the first time. Thanks for taking the time to look at this.

partial error log.txt

DynDOLOD_SSE_log.txt

xedit whiterun.txt

[LukeCreed13]

Get beta 2.41 and see if it works. If not post/upload ..DynDOLOD/bugreport.txt that should be created in same folder as *.exe

Nope, still access violation error. Here's what bugreport.txt says: https://pastebin.com/VAsH2jDC

[sheson]

Nope, still access violation error. Here's what bugreport.txt says: https://pastebin.com/VAsH2jDC

Looks like the required file ..DynDOLOD\Edit Scripts\DynDOLOD\hardcoded\Skyrim.Hardcoded.keep.this.with.the.exe.and.otherwise.ignore.it.I.really.mean.it.dat is missing or something is preventing access.

 

The DynDOLOD startup log should have a line like

 

[00:00:01.621]    Background Loader: [skyrim.Hardcoded.keep.this.with.the.exe.and.otherwise.ignore.it.I.really.mean.it.dat] Loading file

Hello, I'm sorry if this is well-trodden ground or something, but I'm running into the above issue trying to run DynDOLOD for Skyrim SE. I attached both the full log file and a specific portion of the log file that's relevant, since poking around in xEdit told me that that cell in particular is a part of the WhiterunWorld worldspace (1A26F). More specifically, it's an unlabeled bit of Sub-Block 1, -1 of Block 0, -1, at .

 

Now I'm gonna be honest, I have no clue what any of that actually means. But for whatever reason DynDOLOD has a problem with it. I checked for errors on that cell with xEdit, and also ran an error check for Skyrim.esm itself. While Skyrim.esm had quite a number of errors, xEdit never found any problem with that cell itself. It found a handful of errors that mention Whiterun at all, but none of them have to do with the cell, and only a couple have to do with WhiterunWorld at all. I went ahead and attached a snippet of the xEdit log for that, too.

 

Is this just something that I'm doing wrong because I'm dense? It wouldn't be the first time. Thanks for taking the time to look at this.

 

You are using patch files from DynDOLOD Resources SE 2.41 with DynDOLOD 2.40. 

 

Make sure to use DynDOLOD Resources versions only with matching or higher DynDOLOD Standalone versions but never with older versions.

 

 

Edited July 8, 2018 by sheson

[minos55]

Just noticed I deleted the \Edit Scripts\DynDOLOD\cache 2 times before runing texgen and dyndolod, is there something wrong with that? do we need the cache files when we run dyndolod?

[sheson]

Just noticed I deleted the \Edit Scripts\DynDOLOD\cache 2 times before runing texgen and dyndolod, is there something wrong with that? do we need the cache files when we run dyndolod?

There is no need to worry about the files in the cache folder either way even when generating 3D tree LOD. They are always created anew.

[Omni23]

Hi, I'm new to using DynDOLOD and am trying to follow the Ultimate Trees SE guide. However, when I launch Texgen -sse it runs as DynDOLOD -sse. Both programs work fine without adding "-sse" and launching them for normal Skyrim. Any idea how to fix/or what could be causing this?