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

[sheson]

 

I just tried to launch TexGen via Mod Organizer 2 using the -sse argument and got the following error:

 

[00:00:00.000] TexGen based on xEdit x64 starting session 2018-01-04 02:42:19

[00:00:00.014] Using Skyrim Special Edition Data Path: C:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\

[00:00:00.025] Using ini: -sse\My Games\Skyrim Special Edition\Skyrim.ini

[00:00:00.036] Fatal: Could not find ini

 

I believe I used the exact same parameter for DynDOLOD 2.30 and it launched just fine. Did I miss something that changed between versions? Why is it appending "-sse" to the ini path?

 

Start the game from the launcher once, so the registry settings are updated with the correct path information.

 

If that is not it, double check the command line parameter. You maybe accidentally adding a switch that can be used to define the path to the INI.

Edited January 4, 2018 by sheson

[alt3rn1ty]

First run - Uninstalled all old non dynamic and generated files, waited out the 30 days plus a few indoors. Then installed all new requirements and generated new files, turned off Large References (just in the game settings) :

 

TexGen went fine, bundled up the output files into a zip for Wrye Bash, and I used just the wizard for the first run, selected all worlds, clicked High

 

No issues, the wizard completed. After installing all the output files found one minor issue, your plugins still have 2.30 in the plugin description :P

 

 

 

Having wandered around for a bit enjoying the scenery, all the birdies over solitude are not doing the synchronized olympic flying team, but all have unique flappiness some going faster some leasurely .. all desynced as expected by your new .patch

 

Animations are mostly good, but I think I found one snag :

 

Go to this bridge

 

Walk up the hill to the East, then when you are a good way up, turn around and look at the Waterfalls, the second one up is missing water, walk towards them downhill again. As you reach the Bridge the one that is missing will pop back in to the game ..

 

 

 

 

Thats all I have found to pick up so far .. Logs grab from this zip ..

 

>> Logs for the grabbing of <<

 

 

Edit : Forgot to mention .. Thank you once again for the ******* amazing amount of love piled into this project. Bloody marvellous, and I believe I have been lucky in having my first born spared from mutilation, she looks happy enough anyway :)

Edited January 4, 2018 by alt3rn1ty

[Sharlikran]

Sheson ignore the Wrye Bash errors. People are not understanding why it appears and when it is supposed to appear. I have been trying to explain it and people are skimming over my post or flat out ignoring it.

 

For skyrim it expects 8 bytes and for skyrim se it expects 12 just like it should. It does display an error for the dlc when it shouldn't but I have told the current maintainer to change that but he tends to ignore my posts.

[alt3rn1ty]

+ DynDOLOD.esp should be loaded after Bashed Patch anyway, so Wrye Bash will not even look at it if it loads later then the Bashed Patch (I'm currently not having any issues with the latest Nightly Build of Wrye .. See screenshot in my last post above).

 

From the DynDOLOD_Manual_SSE.html

 

 

 

Load/Overwrite Orders

Generated DynDOLOD.esm and DynDOLOD.esp can be sorted by LOOT or manually. Typically DynDOLOD.esm should be the last ESM (and after the Unofficial Skyrim Special Edition Patch even if it is not a master in DynDOLOD.esm) and DynDOLOD.esp the last ESP for the entire load order.

The DynDOLOD.esm contains only overwrites/data from other ESM files, including flagged ESP. The DynDOLOD.esp overwrites/contains data from the entire load order.

Edited January 4, 2018 by alt3rn1ty

[mohaderhangen]

Looks a bit like you might be using Open Cities Skyrim and did not follow the two step generation instructions. Hard to tell without load order / DynDOLOD log.

I generated the LOD like you described in the manual several times now and most of the problems disappeared, but some new always seem to appear. 

I had to split the log up since it's over 2 MB big.

1:  https://pastebin.com/gHwv3XXp

2: https://pastebin.com/daf05t4L

3: https://pastebin.com/xGaBw0QB

4: https://pastebin.com/jsGP3V6m

5: https://pastebin.com/UyGjXY0q

6: https://pastebin.com/1JZihzkK

I'm sorry if it's hard to read now. Is there a better way of posting logs?

 

Load order: https://pastebin.com/BwH7e1EV

 I hope this helps to identify the problem. 

And I also disabled Large References in the DynDOLOD ini and in SSE itself, if that changes anything.

Edited January 4, 2018 by mohaderhangen

[alt3rn1ty]

Found another problem waterfall, North of Bards Leap Summit, look South at the towers and two aquaduct falls, the further away you are the left hand one loses its falls

 

 

Edited January 4, 2018 by alt3rn1ty

[sheson]

After installing all the output files found one minor issue, your plugins still have 2.30 in the plugin description :P

The version of the plugin did not change since 2.30. It only changes if there are data changes in the plugins/jsons that require the newer versions of the papyrus scripts.

 

Regarding the waterfall you could test if is only with large references or without. Did you check upgrade NearGrid LargeRef? I assume it is a native waterfall. Tell me the form id.

 

Sheson ignore the Wrye Bash errors. People are not understanding why it appears and when it is supposed to appear. I have been trying to explain it and people are skimming over my post or flat out ignoring it.

 

For skyrim it expects 8 bytes and for skyrim se it expects 12 just like it should. It does display an error for the dlc when it shouldn't but I have told the current maintainer to change that but he tends to ignore my posts.

Good to know. Thx.

 

Found another problem waterfall, North of Bards Leap Summit, look South at the towers and two aquaduct falls, the further away you are the left hand one loses its falls

Which typically means LOD just turned off because you are out of the Grid (Near/Large/Far) whichever is doing its "LOD"

Edited January 4, 2018 by sheson

[sheson]

I generated the LOD like you described in the manual several times now and most of the problems disappeared, but some new always seem to appear. 

I had to split the log up since it's over 2 MB big.

I'm sorry if it's hard to read now. Is there a better way of posting logs?

 

Load order: https://pastebin.com/BwH7e1EV

 I hope this helps to identify the problem. 

And I also disabled Large References in the DynDOLOD ini and in SSE itself, if that changes anything.

The log keeps growing. Just delete it before doing a new set of generations. Consider zipping and uploading to a file service. The current way is fine though, since I could just stitch it together anyways and have a quick look.

 

The only thing sticking out (beside the fact the Skyrim is installed into Program Files and DynDOLOD is installed into the Skryim folder) is that the HomeMapMarkersForOpenCities.esp plugin was still loaded for the first generation. It should depend on Open Cities and also be removed I suppose. It probably doesn't change anything though, but please test anyways.

 

Do these tests:

 

Test with new game, coc whiterunexterior01 from main menu and then walk to the inside. 2nd test coc riverwood, tmm1 to enable markers on the map, fast travel to Whiterun.

 

Disable both DynDOLOD.esm and DynDOLOD.esp and test if the problem still happens.

 

Can you open console, click the stuck LOD and get a form id? Use disable/enable commands in console to see if you go the right object. What is its form id?

 

These tests only make sense if the problem is 100% and the stuck objects have a form id. If it only happens sometimes and they have no form id, I am afraid its the engine problem.

Edited January 4, 2018 by sheson

[alt3rn1ty]

I'm not at home now so will revisit when back off shift .. Until then one question :

 

Am I mistakenly thinking that turning off Large References in the game settings is recommended when using the new DynDOLOD ? .. Or should they be left on ? (the slider in the games launcher for Large Objects I have set at 0 before installing this new DynDOLOD as mentioned in my first post today, maybe after reading the docs I got this wrong and they should be left on ?)

 

Because besides switching that off, and using this DynDOLOD beta, those are the only changes to affect the waterfalls mentioned so far - Prior to using the new DynDOLOD and switching off Large Objects they were working fine at all ranges (its only recently that I was screenshooting the same areas a few days ago to highlight a few textures being obvious in having a repetitive patterns on some replacer textures I am trying out, so the waterfall missing today was instantly noticeable as being different to my previous setup)

 

 

Did you check upgrade NearGrid LargeRef? I assume it is a native waterfall.

 

Check upgrade NearGrid LargeRef = I havent got to wherever that is yet - Just used the wizard, selected all worlds, clicked High

 

All waterfalls reported are native, and normally work fine with the vanilla game.

Edited January 4, 2018 by alt3rn1ty

[mohaderhangen]

The problem persists in a new game. The Lod can be disabled but the ground is simply gone. Looking for the "stuck" LOD in SSEEdit seems normal to me , but maybe you can see anything.

https://imgur.com/a/7WYQm

[sheson]

I'm not at home now so will revisit when back off shift .. Until then one question :

 

Am I mistakenly thinking that turning off Large References in the game settings is recommended when using the new DynDOLOD ? .. Or should they be left on ? (the slider in the games launcher for Large Objects I have set at 0 before installing this new DynDOLOD as mentioned in my first post today, maybe after reading the docs I got this wrong and they should be left on ?)

 

Because besides switching that off, and using this DynDOLOD beta, those are the only changes to affect the waterfalls mentioned so far - Prior to using the new DynDOLOD and switching off Large Objects they were working fine at all ranges (its only recently that I was screenshooting the same areas a few days ago to highlight a few textures being obvious in having a repetitive patterns on some replacer textures I am trying out, so the waterfall missing today was instantly noticeable as being different to my previous setup)

The decision to use the large reference does not depend on using DynDOLOD or not, but if you are using plugins that modify large references and them causing noticeable texture flicker. Some plugins get away with their modifications because most people do not notice that both full and LOD models show at the same time because the models do not occupy the exact 3D space/planes that much.

 

Depending on that decision you need to set the MCM "Large Reference Fix" accordingly. (It will try to default to the correct setting which is determined when LOD was generated)

 

If you decide to not use large references you most likely want to check the "Upgrade NearGrid Large Refs" checkbox when generating LOD. Otherwise those thin waterfalls are probably not going to show past the loaded cells. Or use the INI setting IgnoreLargeReferences=1 to not care about large references at all. Then the thin waterfalls will show in their default NearGrid as they did in Skyrim.

Edited January 4, 2018 by sheson

[alt3rn1ty]

Thanks Sheson, all understood, will look into the MCM ( pretty sure this is one of those SKSE Menu things I am not familiar with yet  )

Edited January 4, 2018 by alt3rn1ty

[sheson]

The problem persists in a new game. The Lod can be disabled but the ground is simply gone. Looking for the "stuck" LOD in SSEEdit seems normal to me , but maybe you can see anything.

https://imgur.com/a/7WYQm

Hmm there might a bug, that happened because of one of the past beta updates. I will need to verify that. I may only get to it tomorrow.

 

In the meantime, the base record should still point to the STAT from Open Cities.esp. Just drag WRMainRoadPlains [sTAT:000193E6] from Open Cities.esp to DynDOLOD.esp and save. That should do it.

Edited January 4, 2018 by sheson

[mohaderhangen]

Hmm there might a bug, that happened because of one of the past beta updates. I will need to verify that. I may only get to it tomorrow.

 

In the meantime, the base record should still point to the STAT from Open Cities.esp. Just drag WRMainRoadPlains [sTAT:000193E6] from Open Cities.esp to DynDOLOD.esp and save. That should do it.

I dragged the record to DynDOLOD.esp which removed the bugged LOD but still didn't bring the floor back. After uninstalling DynDOLOD Output the floor was fine and everything worked correctly.

I'll now rerun DynDOLOD another time and see if it fixes the problems. 

 

Edit: Could this be caused by JK's Whiterun for Open Cities? I have to disable it during the first step so no LOD is being generated for it. 

Edited January 4, 2018 by mohaderhangen

[sheson]

I dragged the record to DynDOLOD.esp which removed the bugged LOD but still didn't bring the floor back. After uninstalling DynDOLOD Output the floor was fine and everything worked correctly.

I'll now rerun DynDOLOD another time and see if it fixes the problems. 

 

Edit: Could this be caused by JK's Whiterun for Open Cities? I have to disable it during the first step so no LOD is being generated for it.

This can only happen in the 2nd step when the DynDOLOD plugins are generated. It should use the last overwrite from Open Cities to create the record in DynDOLOD.esp. For some reason in your case it did not.

 

Make a screenshot from the advanced options window so I know what to use when I try to replicate tomorrow. (provided you still have the problem next time)

Edited January 4, 2018 by sheson