Jump to content

Recommended Posts

Posted (edited)

Ah sheson my dear sheson do I have the redo the entire dyndolod generation if a cmd crashed ?

 

Please don't tell me I have to redo everythiiinnggg :cry:

No, you can just restart LODGen for each worldspace in expert mode with the already existing export file for object LOD.

 

Set Expert=1 in '..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAMEMODE].ini'

 

Start DynDOLOD.exe. Select the worldspace. The Execute LODGen.exe button at the bottom should become available, click it to restart object LOD generation.

 

If it still stops/crash bring command prompt top foreground, check error message and fix problem or copy/screenshot error message for us to troubleshoot.

RIP ME dyndolod crashed, welp that settles it

If DynDOLOD.exe and LODGen.exe both crashes randomly check CPU cooling etc.

Edited by sheson
Posted (edited)

I did make a post about it (but it was taken down with no reason?) but I am getting an error after I finish generating LODs with DynDOLOD for LE: 'Access violation at address 00964F7A in module 'DynDOLOD.exe'. Read of address 00000846'

 

EDIT: Was moved to another topic, don't mind me, just being an idiot

Edited by DirefulSpy
Posted

Oh great I'll keep that in mind just in case.

 

Okay it's the first time that happened on several generations, i'll keep an eye on it, i have around 65° on full load on my i5 2500k

Posted (edited)

Hi

 

I have downloaded the standalone but my Texgen.exe launches the Dyndolod.exe so I can't run Texgen.

 

I have renamed the exe's to TexGen -sse.exe and DynDOLOD -sse.exe so that they recognise SE and not original Skyrim. 

 

Is there a problem with the download linked at the start of this thread?

 

Can anyone help?

Edited by m1sf1t711
Posted (edited)

Hi

 

I have downloaded the standalone but my Texgen.exe launches the Dyndolod.exe so I can't run Texgen.

 

I have renamed the exe's to TexGen -sse.exe and DynDOLOD -sse.exe so that they recognise SE and not original Skyrim. 

 

Is there a problem with the download linked at the start of this thread?

 

Can anyone help?

 

 

Do not rename the exe files. TexGen mode only works when the executable is named TexGen.exe or TexGenx64.exe, any other executable name will run the DynDOLOD mode.

 

Command line arguments are supposed to be added after the file name. See ..DynDOLOD\Docs\DynDOLOD-Shortcut.txt for help.

Edited by sheson
Posted

Do not rename the exe files. TexGen mode only works when the executable is named TexGen.exe or TexGenx64.exe, any other executable name will run the DynDOLOD mode.

 

Command line arguments are supposed to be added after the file name. See ..DynDOLOD\Docs\DynDOLOD-Shortcut.txt for help.

Hi

 

Many many apologies.

 

I realise I was being a numpty and misreading the shortcut.txt instructions.

 

Everything seems to be working perfectly now.

 

So sorry for wasting your time.

Posted

Hello,

 

I am experiencing z-fighting / texture flicker on certain mountains around Whiterun. Using the console, I think the offending records are:

0010d28d
0010d28e
0010d292
0010d917
0010e299
0010e29a

These are all different type of Distant Cloud LOD. 

 

I also noticed that throughout the DynDOLOD_SSE_log.txt there is a message "Missing DATA - Flags 0x4 RealisticWaterTwo.esp _WTRIceFloes01_Anims [MSTT:5403261B]" but I'm not sure if that is related or not.

 

Would really appreciate some help to identify the cause of this.

loadorder.txt

Posted

Hello,

 

I am experiencing z-fighting / texture flicker on certain mountains around Whiterun. Using the console, I think the offending records are:

0010d28d
0010d28e
0010d292
0010d917
0010e299
0010e29a

These are all different type of Distant Cloud LOD. 

 

I also noticed that throughout the DynDOLOD_SSE_log.txt there is a message "Missing DATA - Flags 0x4 RealisticWaterTwo.esp _WTRIceFloes01_Anims [MSTT:5403261B]" but I'm not sure if that is related or not.

 

Would really appreciate some help to identify the cause of this.

Clouds typically do not z-fight since they are transparent. DynDOLOD does not change cloud references or their base records. DynDOLOD does not change how the engine works.

 

If plugins cause the large reference bugs texture flicker, solutions are to set uLargeRefGridDistance to 5, convert the plugin to an ESM or to remove the plugin. In case of converting to ESM the data flag 0x4 needs to be set on the MSTT so that the large reference bugs are not triggered.

Posted (edited)

Hi sheson, I have this issue with ultra trees : 1532181320-screenshot30.png

 

On nifskope no issues(yes I loaded the 3d mesh) and the 2d counterpart has no issues either : 1532181482-2018-07-21-15-49-00-treeoak05

 

logs sho nothing wrong either

Edited by Monobloc
Posted (edited)

Hi sheson, I have this issue with ultra trees : 1532181320-screenshot30.png

 

On nifskope no issues(yes I loaded the 3d mesh) and the 2d counterpart has no issues either : 1532181482-2018-07-21-15-49-00-treeoak05

 

logs sho nothing wrong either

I am assuming the tree model used for LOD is a custom one and not from a mod. LOD does not support all shader settings/types when using "PassThru". It is probably caused by shader flags. Carefully compare shader type/flags/setttings and texture list with 3D LOD tree models included in DynDOLOD Resources to spot differences.

Edited by sheson
Posted

I opened your dyndolod ressources/meshes/dyndolod/trees/ztrees file, changed textures, copied it into the enhanced oaks standalone folders and it's still white?

Posted

Clouds typically do not z-fight since they are transparent. DynDOLOD does not change cloud references or their base records. DynDOLOD does not change how the engine works.

Thanks for the reply. You'll have to forgive me as I'm quite new to modding, but those records were what the console displayed when I clicked the area that was flickering. I hoped that they might lead to what was causing the issue.

If plugins cause the large reference bugs texture flicker, solutions are to set uLargeRefGridDistance to 5, convert the plugin to an ESM or to remove the plugin. In case of converting to ESM the data flag 0x4 needs to be set on the MSTT so that the large reference bugs are not triggered.

Do you mean uLargeRefLODGridSize? I can't find any info on uLargeRefGridDistance.

 

Is it possible that other plugins could be triggering the large reference bug and if so, would they also show as errors in the DynDOLOD log? Lastly, should I add the flag 0x4 to the record or will there be a data field that already exists that I need to edit?

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.