Jump to content

Recommended Posts

Posted

@Sheson

 

Has something changed with regards to the Output Path?

 

I usually use a desktop icon which has the following in the Icon properties target

 

D:\DynDOLOD\DynDOLOD.exe -SSE -o:D:\1-DynDOLOD-Out\

 

But my first run of 2.37 via the same icon has output to its own directory instead in ..

 

D:\DynDOLOD\DynDOLOD_Output\ <-- All folders / files (meshes and textures etc) end up in here

 

So it has ignored the icon output path -o:D:\1-DynDOLOD-Out\

 

Seems there is now a similar problem for TexGen, in version 2.38

 

TexGen Icon on my desktop has the following as the target ..

 

D:\DynDOLOD\TexGen.exe -sse -o:D:\0-TexGen-Out\

 

But TexGen is seemingly trying to output to the game folder

 

dwEe9EX.png

 

 

Which presents a problem, because TexGen does not have any kind of dialogue to change the Path like DynDOLOD does.

Posted (edited)

Seems there is now a similar problem for TexGen, in version 2.38

 

TexGen Icon on my desktop has the following as the target ..

 

D:\DynDOLOD\TexGen.exe -sse -o:D:\0-TexGen-Out\

 

But TexGen is seemingly trying to output to the game folder

 

dwEe9EX.png

 

 

Which presents a problem, because TexGen does not have any kind of dialogue to change the Path like DynDOLOD does.

TexGen uses the -o output path unless there are settings already saved from previous generations. They are stored in DynDOLOD_[GAME MODE]_TexGen.ini

 

TexGen/DynDOLOD never output to the data folder. That path is denied to protect people from themselves. Also the tools do not care about existing files in the output folder, they will just be overwritten.

 

The first option of the TexGen interface is setting the output folder, which you can change before clicking the start button.

 

The message from the screenshot is all unrelated to that. It is telling you that previous generated textures are already installed in the data folder. Earlier output should be removed from the data folder to avoid circular texture generations.

Edited by sheson
Posted (edited)
Crash when running DynDoLod for Skyrim SE, using DynDoLod Beta 2.37 and DynDoLod resources 2.37 

 

Log file to big too attach, so i uploaded it to github: https://github.com/rockett1/DynDoLod-error

 

Mod list:


 

Just before the error:

[00:23:24.403] JKs Skyrim.esp [REFR:000BACE7] (places MrkFrontWALLintMts01 [sTAT:000BACE0] in GRUP Cell Temporary Children of MarkarthOrigin [CELL:00020EE7] (in MarkarthWorld "Markarth" [WRLD:00016D71] at -43,1))

[00:23:24.423] JKs Skyrim.esp [REFR:000BACEA] (places MrkFrontWALLintMts04 [sTAT:000BACDD] in GRUP Cell Temporary Children of MarkarthOrigin [CELL:00020EE7] (in MarkarthWorld "Markarth" [WRLD:00016D71] at -43,1))

[00:23:24.444] JKs Skyrim_RWT_Patch.esp [REFR:0010B1D5] (places FXWaterfallBodyTall_static_nocollision [sTAT:9400AA67] in GRUP Cell Temporary Children of [CELL:00020EEB] (in MarkarthWorld "Markarth" [WRLD:00016D71] at -44,0))

[00:23:24.465]

[00:23:24.484]

[00:23:24.859]

[00:23:24.859] Exception in unit userscript line 326: Found a REFR reference, expected: ACTI,ADDN,ALCH,AMMO,APPA,ARMA,ARMO,ARTO,ASPC,BOOK,CONT,DOOR,FLOR,FURN,GRAS,IDLM,INGR,KEYM,LIGH,LVLC,LVLN,MISC,MSTT,SCRL,SLGM,SNDR,SOUN,SPEL,STAT,TACT,TREE,TXST,WEAP

 

How do i fix this? What does it mean?

 

(updating to DynDoLOD 2.38 now to see if that fixes it)

Edited by rockett
Posted

Oh dammit, sorry Sheson I forgot to go back into Wrye Bash and uninstall the previous TexGen output  :doh:

 

Going senile

No worries, that message exists to remind myself to disable the old TexGen output before doing a new run.

Posted

Just re-run TexGen and then DynDoLOD for 2.38, no errors all good. Please ignore this post, make sure you use the newest version of DynDoLOD to all those who read this.

Posted

Get DynDOLOD 2.38 beta from first post. It hopefully fixes all no model found issues.

I have tested this with the same load order that was getting bugs on 2.37 and they are gone in 2.38, thanks for the update.

Posted

I have tested this with the same load order that was getting bugs on 2.37 and they are gone in 2.38, thanks for the update.

Great. Thanks for the help.

Posted

1) requires dynamic LOD, since the tree changes based on quests.

 

2) That happens because those tree are done as static object LOD. They are skipped by traditional tree LOD generation because they have an enable parent. They are disabled for the intro. See c:\Skyrim\DynDOLOD\Docs\trees.ultra\DynDOLOD-Trees.html Trees on the Map section.

 

3) Changing fSplitDistanceMult changes the distances of the terrain LOD levels in relation ship to the object LOD levels. You can change it from the DynDOLOD SkyUI MCM Settings page. Changing these settings does not break anything.

 

4) ATM Only by increasing NearGrid I believe. If you use IgnoreLargeReferences=1 (large refs off for good) they might be automatically in the FarGrid or can be set to be with mesh rules for the model. I actually would have to verify myself to be sure what works.

 

5) Find the mesh rules 01burning and 01landburning and changing Grid to Never Fade LOD should work

3) setting fSplitDistanceMult to 0.5 resolved the holes in water

 

4) at first I used IgnoreLargeReferences=1 (LargeRefLODGridsize=5) but the lanterns were the same (only 2 ahead i guess) as using LargeRefLODGridsize=9 and setting the slightposts to FarLOD in Grid. (it was a bit tricky to get the item number in VR)

 

5) setting Never Fade LOD in Grid did not work, the giant camp fires still disappear after a while.

Posted (edited)

 

 

5) setting Never Fade LOD in Grid did not work, the giant camp fires still disappear after a while.

5) hmm I will check why that does not work and try to fix for next version if possible. In the meantime you could instead change Reference from Unchanged to Original for those mesh rules. Leave rest of the rules default.

Edited by sheson
Posted (edited)

Heya Shesson :) Thanks so much for what you did, the riverwood trader is now open again......... :p

So I redid a TEXGEN/DynDOLOD "construction" this afternoon. Everything went well I think. Just at the end thought LODGEN64 was hanging for quite a while and only one of the CMD windows closed on its own before DynDOLOD finished succesfully. the other window I had to close myself afterwards.

I made a full log folder + settings used in my google drive here for you if you wish to check out how things went for v2.38b. :)

Same load order/ mods.

Edited by KorruptkSwades

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.