Jump to content

DynDOLOD 3.00 Alpha 180


sheson

Recommended Posts

Hello,

I finished a DynDOLOD run and an error came up just after the Summary of Messages opened.

Error message box:

Spoiler

[Window Title]
DynDOLOD

[Main Instruction]
Access violation at address 000000000126DB3E in module 'DynDOLODx64.exe'.

[Content]
Read of address 0000000000000000.

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

After clicking OK, a Please Wait box showed for a few seconds of loading then the program saved its output (the esm etc.)

Here be my log files: https://mega.nz/folder/hPMkxBIA#srpHjV6hiEUnmRRVUytaOg

Edited by DWM19
spoilered error message correctly
Link to comment
Share on other sites

Hi,

I'm getting the following error message:  Access violation at address 0000000000E7DB3E in module 'DynDOLODx64.exe'. Read of address 0000000000000000.

But the esps and esm are generated and everything seems to be working.  The error pops up at the last minute.  I get the error with my full load order and without, and the error pops up after everything says it was generated okay. 

I'm running 1.5.97 (not downpatched) and DynDOLOD 3 Alpha-160 and Assets Alpha-47.  My logs are linked below.  The logs are without my full load order.

Thanks!

https://ufile.io/f/k0n87

 

Link to comment
Share on other sites

  • sheson changed the title to DynDOLOD 3.00 Alpha 161
7 hours ago, DWM19 said:

Hello,

I finished a DynDOLOD run and an error came up just after the Summary of Messages opened.

Error message box:

  Reveal hidden contents

After clicking OK, a Please Wait box showed for a few seconds of loading then the program saved its output (the esm etc.)

Here be my log files: https://mega.nz/folder/hPMkxBIA#srpHjV6hiEUnmRRVUytaOg

This should be fixed in Alpha-161

https://dyndolod.info
Always use the latest version.

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

https://dyndolod.info/Updating#New-DynDOLOD-Version

Link to comment
Share on other sites

6 hours ago, slanglois said:

Hi,

I'm getting the following error message: Access violation at address 0000000000E7DB3E in module 'DynDOLODx64.exe'. Read of address 0000000000000000.

But the esps and esm are generated and everything seems to be working. The error pops up at the last minute. I get the error with my full load order and without, and the error pops up after everything says it was generated okay.

I'm running 1.5.97 (not downpatched) and DynDOLOD 3 Alpha-160 and Assets Alpha-47.  My logs are linked below.  The logs are without my full load order.

Thanks!

https://ufile.io/f/k0n87

This should be fixed in Alpha-161

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Pay attention to all log messages. It should end with the log message 'DynDOLOD plugins generated successfully' and lines like 'LODGen generated object LOD for [WORLDSPACE] successfully' for each selected worldspace. Do not use the output if there were errors that stopped the process prematurely.

The message missing from the log means one or more plugins are incomplete.

Link to comment
Share on other sites

I think something has borked with my last generation with DynDOLOD 161.
I went via coc whiterunexterior16 from main menu in the game, same result if I do coc riverwood and walk straight to whiterun by foot.
I only can see stuff which is near to my character and the far away (fargid?) lod. Trees for example aren't present, only when I get closer the full models are loading, only billboards are in distance.
As you can see on the screenshots further down, first the whiterun castle lod is viewable, if I get closer it vanishes (no step in between) and only If I get close enough the full models are loading.
You can also see that there is no difference if LOD is active or not (tll command).
Can't tell what happened here, everything looked fine during generation.

Here are the logs

Here are some screenshots:

https://ibb.co/0BsxnQV

https://ibb.co/267MjVw

https://ibb.co/qkwQcs1

https://ibb.co/4mPR2pC

https://ibb.co/xSpfsGd

https://ibb.co/wyhM20g

https://ibb.co/F6Yr8vR

https://ibb.co/mcTbTbx

https://ibb.co/DtZzdR3

https://ibb.co/0Dk3m16

And this is just an example. I had no (critical) errors during generation nor any crashes. Or do I have to start a new game to get everything to work correctly? In the past it worked even if you coc from main menu.
Oh and is it correct, that the some points from the MCM are missing e.g. where you set 'NetImmerse Override' on/off? Haven't read anything regarding this in the changelog.
https://ibb.co/brBLH9W

https://ibb.co/cr5HBR9

https://ibb.co/Y7kV14q

Edited by PRieST
Link to comment
Share on other sites

49 minutes ago, PRieST said:

I think something has borked with my last generation with DynDOLOD 161.
I went via coc whiterunexterior16 from main menu in the game, same result if I do coc riverwood and walk straight to whiterun by foot.
I only can see stuff which is near to my character and the far away (fargid?) lod. Trees for example aren't present, only when I get closer the full models are loading, only billboards are in distance.
As you can see on the screenshots further down, first the whiterun castle lod is viewable, if I get closer it vanishes (no step in between) and only If I get close enough the full models are loading.
You can also see that there is no difference if LOD is active or not (tll command).
Can't tell what happened here, everything looked fine during generation.

Here are the logs

Here are some screenshots:

https://ibb.co/0BsxnQV

https://ibb.co/267MjVw

https://ibb.co/qkwQcs1

https://ibb.co/4mPR2pC

https://ibb.co/xSpfsGd

https://ibb.co/wyhM20g

https://ibb.co/F6Yr8vR

https://ibb.co/mcTbTbx

https://ibb.co/DtZzdR3

https://ibb.co/0Dk3m16

And this is just an example. I had no (critical) errors during generation nor any crashes. Or do I have to start a new game to get everything to work correctly? In the past it worked even if you coc from main menu.
Oh and is it correct, that the some points from the MCM are missing e.g. where you set 'NetImmerse Override' on/off? Haven't read anything regarding this in the changelog.
https://ibb.co/brBLH9W

https://ibb.co/cr5HBR9

https://ibb.co/Y7kV14q

It seems none of the three reasons given at https://dyndolod.info/FAQ#Entire-LOD-missing apply.

Check what happens if you disable Occlusion.esp. If that makes no difference something probably happened to the LOD level 4 files or the engine loading them. Test with default INIs.

The MCM is a bit different for the large reference bugs workarounds, or rather for the dynamic LOD being done by DynDOLOD DLL NG.

Unrelated, but what is this supposed to be doing?
<Warning: Large references found in non master plugin LargeRefResolution.esp RiftenWorld "Rifton" [WRLD:00016BB4]>

Link to comment
Share on other sites

4 hours ago, sheson said:

It seems none of the three reasons given at https://dyndolod.info/FAQ#Entire-LOD-missing apply.

Check what happens if you disable Occlusion.esp. If that makes no difference something probably happened to the LOD level 4 files or the engine loading them. Test with default INIs.

The MCM is a bit different for the large reference bugs workarounds, or rather for the dynamic LOD being done by DynDOLOD DLL NG.

Unrelated, but what is this supposed to be doing?
<Warning: Large references found in non master plugin LargeRefResolution.esp RiftenWorld "Rifton" [WRLD:00016BB4]>

Disable Occlusion.esp didn't do anything to this. I also looked at some of the created .bto files, they look quite good I checked 'Tamriel.4.4.-8.bto' as an example, because there are all trees missing when I am at WhiteRiverWatchExterior03 and looking down (good place to test DynDOLO IMO). The bto file itself looks absolutely fine.

I'll see what happens if I use dafault ini of skyrim - but I have to tell you, that I didn't mess with them since ages.

I'll also try and deactivate some SKSE plugins, maybe there is something odd happening (in the past I had a very confusing error with Dynamic Things Alternative, but that's not the case this time, but who knows.

Ok, that's why it's looking different.

Kind of forgot about that plugin and with the Large Reference Bug Workaround it might be obsolete. This was an old approach from me to solve the large reference bugs with this method

Quote

Alternatively, all large references of an affected cell could be moved underground out of view and new references replacing them could be added. These new reference wouldn't be large references. This is also a solution for large reference bugs triggered by the Initially Disabled flag in case it can not be removed.

from the help: https://dyndolod.info/Help/Large-References

Edit:
I checked what happens, if I disable DynDOLOD.esp, .esm and Occlusion.esp and output active, result was:
The whiterun castle was complete there, where it wasn't before. Still, the chunk with the trees (where I checked the .bto file) was 'empty'.


With also the SKSE plugin deactivated, all LOD are there, but also the fullmodels I think, because there is massive flickering.


Without the SKSE plugin, but all DynDOLOD plugins active I get an papyrus version mismatch error (absolutely obvious), less flickering (I know, there is something not working as supposed to be, thats also obvious) - I assume it's because of LOD and Fullmodel renderd at the same time, but the whiterun castle looks good and also the LOD 4 part is there and not vanished as it was, while the DynDOLOD NG SKSE Plugin is active. I only can assume that it's related to the plugin, but it looks like it is.
I'll mess with some SKSE plugins, deactivate a bunch and see, if there is any difference -> nothing found there.

Edited by PRieST
Link to comment
Share on other sites

7 hours ago, PRieST said:

Disable Occlusion.esp didn't do anything to this. I also looked at some of the created .bto files, they look quite good I checked 'Tamriel.4.4.-8.bto' as an example, because there are all trees missing when I am at WhiteRiverWatchExterior03 and looking down (good place to test DynDOLO IMO). The bto file itself looks absolutely fine.

To test if this has anything with the BTO files, remove/hide them all.

7 hours ago, PRieST said:

I'll see what happens if I use dafault ini of skyrim - but I have to tell you, that I didn't mess with them since ages.

Post results of actual tests.

7 hours ago, PRieST said:

Ok, that's why it's looking different.

What looks diffrent and why?

7 hours ago, PRieST said:

Kind of forgot about that plugin and with the Large Reference Bug Workaround it might be obsolete. This was an old approach from me to solve the large reference bugs with this method

Remove unnecessary plugins that overwrite large references when using the large references bugs workarounds.

8 hours ago, PRieST said:

I checked what happens, if I disable DynDOLOD.esp, .esm and Occlusion.esp and output active, result was:
The whiterun castle was complete there, where it wasn't before. Still, the chunk with the trees (where I checked the .bto file) was 'empty'.

You mean LOD works fine but the content of Tamriel.4.4.-8.bto is not showing? Looking from where?
You mean only the LOD for trees is not showing, but all the other LOD from the same file is?

If vanilla/generated LOD works without the plugins, set PartialWorldspace=0 and PartialPersistentCell=0 in D:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and generate LOD for just Tamriel for a test to see if there are any changes.

8 hours ago, PRieST said:

With also the SKSE plugin deactivated, all LOD are there, but also the fullmodels I think, because there is massive flickering.

You mean DynDOLOD DLL NG? It does not affect how the engine loads terrain, object and tree LOD meshes.

Link to comment
Share on other sites

32 minutes ago, sheson said:

Post results of actual tests.
You mean LOD works fine but the content of Tamriel.4.4.-8.bto is not showing? Looking from where?
You mean only the LOD for trees is not showing, but all the other LOD from the same file is?

So I went in the game with the default ini, and yeah I am surprised, because this is the result (and compared to the other screenshots, there are even more trees visible..hm):
https://ibb.co/568XKXv

This is with my ini settings, so maybe there is something wrong I'll have to check, but as I said even with earliere alphas from DynDOLOD it worked, because the only setting I touched was the setting for particles:

https://ibb.co/ncvSMZX

Quote

You mean DynDOLOD DLL NG? It does not affect how the engine loads terrain, object and tree LOD meshes.

And this again is with my ini settings, but without the DynDOLOD DLL NG loaded:
https://ibb.co/MfHTsJG

Quote

What looks diffrent and why?

I meant the MCM, that it looks different now than I was used to, nothing special.

Quote

Remove unnecessary plugins that overwrite large references when using the large references bugs workarounds.

Of course, will get rid of it the next generation - just forgot about it to be honest.

Quote

If vanilla/generated LOD works without the plugins, set PartialWorldspace=0 and PartialPersistentCell=0 in D:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and generate LOD for just Tamriel for a test to see if there are any changes.

I'll give this another test and see what the results are.

Edited by PRieST
Link to comment
Share on other sites

8 minutes ago, PRieST said:

So I went in the game with the default ini, and yeah I am surprised, because this is the result (and compared to the other screenshots, there are even more trees visible..hm):
https://ibb.co/568XKXv

If everything works as it should, then there is no need to generate with the changed settigs.

The DynDOLOD DLL NG is required for the full trees which are flagged as large references to to show to the edge of the uLargeRefLODGridSize where their object LOD starts. Otherwise full trees will only show to the edge of uGridsToLoad.

Link to comment
Share on other sites

2 minutes ago, sheson said:

If everything works as it should, then there is no need to generate with the changed settigs.

The DynDOLOD DLL NG is required for the full trees which are flagged as large reference to to show to the edge of the uLargeRefLODGridSize where their object LOD starts.

But than I'll have to figure out which setting is messing up the LOD loading for LOD 4, I don't have so much under [LOD] section which looks odd.

Link to comment
Share on other sites

The culprit is this in Skyrimprefs.ini under [General]

uLargeRefLODGridSize=11

Without that line everything looks fine.
But why? This wasn't a problem with earlier alpha versions.
This is from the DynDOLOD_SSE.ini:

; Because Bethesda simply does not comprehend people are modding exterior worldspaces ...
; set to 1 if uLargeRefLODGridSize=5 (value of uGridsToLoad) in SkyrimPrefs.ini, do this if it is certain that the large references system will not be used, so that no DynDOLOD.esm is created
; set to 0 if uLargeRefLODGridSize>5 (value of uGridsToLoad) in SkyrimPrefs.ini
IgnoreLargeReferences=0

 

Edited by PRieST
Link to comment
Share on other sites

Just now, PRieST said:

The culprit is this in Skyrimprefs.ini under [General]

uLargeRefLODGridSize=11

Without that line everything looks fine.
But why? This wasn't a problem with earlier alpha versions.
This is from the DynDOLOD_SSE.ini:

; Because Bethesda simply does not comprehend people are modding exterior worldspaces ...
; set to 1 if uLargeRefLODGridSize=5 (value of uGridsToLoad) in SkyrimPrefs.ini, do this if it is certain that the large references system will not be used, so that no DynDOLOD.esm is created
; set to 0 if uLargeRefLODGridSize>5 (value of uGridsToLoad) in SkyrimPrefs.ini
IgnoreLargeReferences=0

Removing a setting from the INI, means its default value is used in the game.
You can check it with console getini "uLargeRefLODGridSize:General"
Do not remove the setting, simply leave it at 11. All large references should be shown up to its distance.

The uLargeRefLODGridSize setting does not affect LOD generation. Whatever its setting it should not affect terrain LOD that was also shown missing in your initial screenshots.

Upload a BTO from an area that you believe has issues.

Link to comment
Share on other sites

31 minutes ago, sheson said:

You can check it with console getini "uLargeRefLODGridSize:General"

(Maybe a dumb question, because I could just have tried both ways) With or without quotation marks? Because with it I just get "unknown type"
https://ibb.co/tbj0kgm
But I checked, if I get the default SkyrimPrefs.ini, what the value is and it is set to 5 (which is working). In my case setting it higher as 5 it breaks somehow the LOD display.

Quote

The uLargeRefLODGridSize setting does not affect LOD generation.

Generation was fine, but the display ingame is the culprit.

Quote

Upload a BTO from an area that you believe has issues.

https://www.file-upload.net/download-15241320/Tamriel.4.4.-8.7z.html

Definetly that one (the same spot jus looking left if you compare it to the screenshots). But as far as I can tell the .bto looks absolutely correct.

Edit:
Comparison between

uLargeRefLODGridSize=5

https://ibb.co/wR6FT1M
https://ibb.co/Bs8cYRd

uLargeRefLODGridSize=7

https://ibb.co/t3hRkbP
https://ibb.co/dpK5Xy4

uLargeRefLODGridSize=9

https://ibb.co/Nr2PX9C
https://ibb.co/0K1tYgh

and

uLargeRefLODGridSize=11

https://ibb.co/kXKDCZV
https://ibb.co/Bcs1jxd

Edited by PRieST
Link to comment
Share on other sites

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.