DynDOLOD Error: Load Order messed up

[Ardellian]

I've been experiencing an error in DynDOLOD SSE and idk how to solve the issue. It kept saying an error whenever I start it. I tried adding -sse in the arguments and in the shortcuts. Nothing worked so I'm hoping that someone could help me find out why it's not working. Btw I'm using MO2 and Wyre Bash.

 

Here's the error that is in multiple spots in the DynDOLOD logs:

Error: Load order messed up! Tried to find a file id higher than files loaded. 0 > -1. Try generating tree LOD for this load order. Stopping script.

Exception in unit userscript line 466: Error: Load order messed up! Tried to find a file id higher than files loaded. 0 > -1. Try generating tree LOD for this load order. Stopping script.

 

Here's what keeps popping up when I run DynDOLOD and i always had to click ok a lot:

Access violation at address 0000000000417d4f in module 'DynDOLODx64.exe'. Read of address FFFFFFFF80393980 (the numbers at the end here are always changing for each ok).

Edited August 18, 2017 by Ardellian

[sheson]

Please post the log(s).

 

Also not sure what "32 bit texgen simply does not work it refuses to read the master files" means. Post those logs as well.

 

We know this error is limited to x64 version. It is related to the (alternative) memory manager, which appears to be fine in x86.

 

The last plugin that is loaded the moment the first exceptions happens is not necessarily the cause - if it all. You could also try just reordering plugins. For example, try to move the plugin that loaded before the one in which the first exception happens to load much earlier.

Edited September 9, 2017 by sheson

[sheson]

Based on what we learned so far here is an archive with 3 different x64 versions to test for users who have this problem.

 

Simply put the exe files into the DynDOLOD folder of the standalone version. Then either start them directly (adding -sse command line parameter of course) or rename to DynDOLODx64.exe/TexGenx64.exe

 

Report which one works or not and which one works the fastest for you.

[Astakos]

Do all of these uploaded versions contain the fix for the "non-generated textures" that we were discussing on the other thread?

 

EDIT: Tested all 3 versions for TexGenx64...all 3 of them are giving me "Access Violation" errors on different spots in my load order (which was always the same).

Edited September 10, 2017 by Astakos

[sheson]

Yes it contains all other unreleased updates. There is only one branch that I keep changing.

 

If you could post the log for the shortest numbers of plugins loaded until the exception happened that could help. I had a load order that showed the exception, but it now works with the 3 latest compiles from that archive while it still fails on an old compile (not on the 2.26/2.31 versions though). It is a bit erratic...

Edited September 10, 2017 by sheson

[Astakos]

You want TexGen logs or DynDOLOD logs or both?

 

I will try tomorrow to start disabling plugins for all versions and post the logs...

[sheson]

Which doesn't matter. Just the one with the least amount of plugins loaded until the error happens. The plugin loading part is exactly the same.

[Karma]

1 and 3 of those Dyndolod exe that you uploaded work for me.

 

2 is giving me the same "Access Violation at address x in module 'Dyndolod-2.exe' read of address FFFFF12346578910" over and over until it finally spits out the same 'load order messed up' that the 2.31 release does.

 

3 seemed a tiny bit snappier than 1 and I don't think its my imagination.

 

I don't think my logs are going to tell you anything you don't already know since it seems you've fixed the problem in these two EXE files.

 

32 bit texgen is trying to find LE when I only have SE installed. Can I use this x86 texgen for sse?

Edited September 11, 2017 by Karma

[sheson]

Use the -sse command line for x86 and x64 version to make it see Skyrim SE. You can also just rename any of the working DynDOLOD exe from the test archive to TexGenx64.exe

[Astakos]

Which doesn't matter. Just the one with the least amount of plugins loaded until the error happens. The plugin loading part is exactly the same.

OkK sheson...this thing will drive me insane!!

 

Last night when you posted the 3 different versions for the 64-bit part, I downloaded them and started testing them one at a time in my main-playing profile in MO2.

None of them have been successful as I wrote you above.

 

Then today, I made another profile in MO2 (identical - completely identical to my main one) disabled all plugins (except the vanilla ones) and started enabling 10-10 at a time.

AND...YES...Version 1 is working fine...tested it with my actual gaming profile and it is A-OK.

I do not know what happened since last night and it is working now...really man nothing was changed!!!

 

With the other 2 versions...

 

Version 2

 

Reproducible "Access Violation" crash at plugin number 49 (mod index 31).

Log attached below.

 

Version 3

 

Another weird issue here...

Reproducible "Access Violation" crash at plugin number 181 (mod index B4)

But...if I enable 2+ plugins after #181 I still get the "Access Violation" message and if I press OK TexGen's creation window appears without any "Load order messed up" message.

If I enable 2-3 more plugins then crash with Load Order messed up" message...no TexGen's window.

 

At this point I must add that for both crashing versions it made no difference which plugin was at #49 or #181...any plugin at those spots would make TexGen crash,

 

Attached Log files for all my tests.

 

Hope it helps in one way or the other...! 

[sheson]

The load order messed up message only happens when something later needs to read data from a plugin and the internal file counter does not agree with the load order form id. What that means is, it is entirely possible that whatever DynDOLOD/TexGen need to do may just get away with it.

 

Generating textures with TexGen is probably fine after such exception. However I would not trust any saved esp in that state.

 

I can verify the random nature of this bug. I still have a reproducible MO setup and load order with "only" 24 plugins that still shows the bug when using a debug version of version #2. The release versions I uploaded however are all working fine for me.

 

What currently prevents me from tracing this error is, that I have not yet succeeded to replicate the problem on the development machine, despite basically copying the entire MO setup and what not.

 

So yeah. Any tiny change in whatever will make it work... or not. If you have this, just move one plugins that are before the one that has the error around in the load order, it might just be enough. I also see the same as you, the exception happens at a specific position at times and has nothing to do with the plugin that is currently at that position.

 

Whatever the cause, it will be something really silly.

Edited September 11, 2017 by sheson

[Karma]

renaming the #1 EXE to texgen and running 3 as Dyndolod through MO seems to be working fine now, thanks Sheson.

[sheson]

Gotcha. Looks like this was caused by an legacy x86 counter/integer/counter conversion, which only becomes a problem in x64.

 

It is one of those how the @#%$ did this not cause any problems all this time before and wtf has MO to do with it. I suppose it is all in the virtual memory addressing, guess we were lucky so far.

 

Please test this version

Rename to TexGenx64.exe if needed.

 

Please let me know that it works. Fingers crossed.

Edited September 11, 2017 by sheson

[Karma]

OKAY, so I got it working. What I did was:

 

Rename the Dyndolodx64-1.exe to TexGenx64.exe, run, add output to archive, add mod.

 

Dyndolodx64-3.exe was giving me errors, so I gave up and used the 32 bit .exe  with -sse argument. Add output to archive, add mod. Result

 

Edited September 11, 2017 by Karma

[Astakos]

Gotcha. Looks like this was caused by an legacy x86 counter/integer/counter conversion, which only becomes a problem in x64.

 

It is one of those how the @#%$ did this not cause any problems all this time before and wtf has MO to do with it. I suppose it is all in the virtual memory addressing, guess we were lucky so far.

 

Please test this version

Rename to TexGenx64.exe if needed.

 

Please let me know that it works. Fingers crossed.

 

Thanks sheson,

 

TexGen 64 tested with 1024 LOD textures generation and it worked just fine.

 

Problems with DynDOLOD though...

 

As you may remember, since I am generating full 3D LODs with TreeFullFallBack=1 @ 1024 Atlas, I cannot generate all worldspaces in one go..not even in two or three without having LODGen hanging and then DynDOLOD crashing.

 

Now...

1. Generated TreeLOD only for Bruma and Darkend (yes I have ported it - it is working fine) -> All Good

2. Then RESTART -> Falskaar -> All Good

3. Then RESTART -> Generated 2 worldspaces from the mod "The Island" and 1 from "Hammet's Dungeon Pack" -> All Good

4. Then RESTART -> Tried to Generate all remaining worldspaces except Tamriel -> DynDOLOD crash with the message: "Exception in unit functions line 334: Assertion failure (C:\Delphi\projects\DynDOLOD\wbImplementation.pas, line 12302)"

 

Then...

 

5. Cleaned DynDOLOD cache folder and Export Folder (and Logs) and redid steps 1-3 above -> All Good

6. RESTART -> Tried to generate the first 4 worldspaces that were referring 1 to "aaaWereBalokDungeonWorld" by Helgen Reborn and 3 to Beyond Reach -> DynDOLOD crashed with the same exception message as above.

 

DynDOLOD Log files for runs 1-4 and run 5-6

 

Let me know if you need anything else.

 

P.S.: I will be trying to do 1 worldspace at a time after step 3 to see how it behaves...but that will take some time before I post any new findings.

[sheson]

If LODGen stalls when doing all worlds at once, but works without error when doing single generations, you should really check CPU cooling, memory timings etc. I guess it could also be because all the processes consume lots of memory at once.

 

I could not yet reproduce that Assertion failure in line 12302 also trying several runs adding one worldspace after another. It might be that it only happens with a lot of mods or a mod that might have errors.

 

Use the latest beta version from this post. Nothing changed anymore in the particular code to the original problem in this thread, but you never know - always use the latest :)

Edited September 13, 2017 by sheson