Jump to content

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


sheson

Recommended Posts

 

getting error when running dyndolod 2.42

 

[00:00:08.268] [DynDOLOD.esp] Adding master "Solitude Expansion.esp"
[00:00:08.386]
[00:00:08.410]
[00:00:08.410] Exception in unit prepare line 543: FormID [1602E12D] references a master which is not available in file [C9] DynDOLOD.esp

 

 

FAQ: Exception in unit xxx line xxx: FormID [xxx] references a master which is not available in file [xx] xxx.esp 

 
A: There is a plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. 
 
If error persist upload/post to pastebin etc. the entire log as requested
Edited by sheson
Link to comment
Share on other sites

 

getting error when running dyndolod 2.42

 

[00:00:08.268] [DynDOLOD.esp] Adding master "Solitude Expansion.esp"
[00:00:08.386]
[00:00:08.410]
[00:00:08.410] Exception in unit prepare line 543: FormID [1602E12D] references a master which is not available in file [C9] DynDOLOD.esp

 

This was happening to me as well. Turned out I needed to rebuild my smashed patch. Try rebuilding any bashed/smash/skyproc patches you have before running DynDOLOD.

 

 

 

I have another problem though. With DynDOLOD active in my load order I have a consistent and repeatable crash when approaching the college of winterhold (with Immersive College of Winterhold installed). Right when I pass the general store in Winterhold towards the entrance where Faralda greets you. If I disable DynDOLOD.esp I have no CTD. Disabling the plugin via the MCM doesn't seem to be enough.

 

Any ideas on this one?

Link to comment
Share on other sites

I keep getting this error, and I am not sure how to troubleshoot  it: Exception in unit userscript line 326: Assertion failure (C:\Delphi\projects\DynDOLOD\Imaging\Imaging.pas, line 1168). I attempted running as admin, disabling AV and even uninstalling my AV. Currently using version 2.42. The full log is here. Any help appreciated! 

Link to comment
Share on other sites

This was happening to me as well. Turned out I needed to rebuild my smashed patch. Try rebuilding any bashed/smash/skyproc patches you have before running DynDOLOD.

 

 

 

I have another problem though. With DynDOLOD active in my load order I have a consistent and repeatable crash when approaching the college of winterhold (with Immersive College of Winterhold installed). Right when I pass the general store in Winterhold towards the entrance where Faralda greets you. If I disable DynDOLOD.esp I have no CTD. Disabling the plugin via the MCM doesn't seem to be enough.

 

Any ideas on this one?

Q: Skyrim: ILS or CTD
 
A: More LOD uses more memory and this can cause infinite loading screen (ILS) or crash to desktop (CTD) if the game is not setup correctly. Double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Or use alternative OSAllocator from crash fixes with pre-loader. Remove satefy-load if it is used to verify it doesn't cause CTD. Set ExpandSystemMemoryX64=false in enblocal.ini 
 
A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. 
 
Let me know what you find.
 

I keep getting this error, and I am not sure how to troubleshoot  it: Exception in unit userscript line 326: Assertion failure (C:\Delphi\projects\DynDOLOD\Imaging\Imaging.pas, line 1168). I attempted running as admin, disabling AV and even uninstalling my AV. Currently using version 2.42. The full log is here. Any help appreciated! 

Looks like a texture that is being put onto the atlas is causing trouble. It might have to do with the odd installation path of the game.

 

Check ..DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_SSE_tamriel_textures_used.txt for a list of textures to check and verify.

Link to comment
Share on other sites

Hey sheson,

 

thank you for the clarification. Unfortunately, the DynDOLOD log does not properly update even though I regenerated LOD, therefore hindering me from finding out about certain mods potentially causing large reference bugs.

 

Do you have information on whether the most popular mods from Arthmoor (USSEP and his town overhauls) also cause this issue (aka not having the unknown 2 flag set)?

 

Also, specifically about RWT 2, what would be your recommendation how to tacke this issue? I think flagging it .esm would not be so good, because then the whole water plugin would be placed high in load order and thus being overwritten by many other mods changing landscape, thus producing seams.

Edited by David2408
Link to comment
Share on other sites

Hey sheson,

 

thank you for the clarification. Unfortunately, the DynDOLOD log does not properly update even though I regenerated LOD, therefore hindering me from finding out about certain mods potentially causing large reference bugs.

Are you certain what you see is large reference flicker and the reference/plugin is not mentioned in the log? If that is the case I would like to know the plugin/form id and test.

 

There are more factors than the two DynDOLOD checks for that can cause the flicker, also with ESM/ESL files. I would consider adding additional checks as well.

 

Do you have information on whether the most popular mods from Arthmoor (USSEP and his town overhauls) also cause this issue (aka not having the unknown 2 flag set)?

 

Just check if DynDOLOD reports any of these plugins.

 

To test if the flicker is caused by large reference bugs, use tll in console to turn off LOD. If flicker goes away and the object is still there loaded as full model, then it is a large reference or full LOD.

 

To verify that the generated LOD is correct, open DynDOLOD\Edit Scripts\Export\LODGen_SSE_Tamriel.txt in a text editor and search for the form id (ignore the first 2 digits for the load order in case it changed) of the object. A line for a large reference has a column "-LargeRef".

Alternatively you could check the BTO that the object is part of a BSSubIndexTriShape that has "-LargeRef" in its name.

 

Also, specifically about RWT 2, what would be your recommendation how to tacke this issue? I think flagging it .esm would not be so good, because then the whole water plugin would be placed high in load order and thus being overwritten by many other mods changing landscape, thus producing seams.

Either the game is broken and unusable or the a plugin that causes large reference bugs are broken and unusable.

So I would either turn off large references or remove plugins that cause problems.

 

You could try moving the overwrites to an ESL.

 

In reality the game needs to be fixed, so spending any time on workarounds is a waste IMHO. Simple as that

Link to comment
Share on other sites

Are you certain what you see is large reference flicker and the reference/plugin is not mentioned in the log? If that is the case I would like to know the plugin/form id and test

Yes, I am certain because I used the method explained by you earlier in the thread to verify. But I probably expressed myself ambiguously, I meant that the DynDOLOD_log.txt is outdated (from previous LOD generation) and does not update itself when regenerating LOD. I have no idea why this is happening. I should instead check the log in the DynDOLOD executable, which is of course displayed correctly. I just forgot about it and later wanted to check the log.txt, when I noticed the txt-file shows plugins I do not have installed anymore.

 

Either the game is broken and unusable or the a plugin that causes large reference bugs are broken and unusable.

So I would either turn off large references or remove plugins that cause problems.

 

You could try moving the overwrites to an ESL.

 

In reality the game needs to be fixed, so spending any time on workarounds is a waste IMHO. Simple as that

Yeah it is true. I understand that the large reference system is inherently broken and I am sorry that you have to deal with all this.. would be nice if Beth fixed it.

 

Trying to move the MSTT to an additional ESL sounds pretty doable though, as RWT 2 has only 2 of these records.

Link to comment
Share on other sites

Just having manually scanned my load order in SSEEDIT, I have written down popular mods that can cause Large Reference Texture Flicker because of missing Unknown 2 Flag or/and missing .esm/.esl Flag (maybe it is helpful for others):

 

Legacy of the Dragonborn

No Snow Under The Roof

CLARALUX

Realistic Water Two

 

 

I can also confirm none of Arthmoor's most famous mods contain MSTT base record overrides.

 

And I am sure (but have no evidence) that JK's Skyrim causes Texture Flicker in Whiterun.

Edited by David2408
Link to comment
Share on other sites

 

I meant that the DynDOLOD_log.txt is outdated (from previous LOD generation) and does not update itself when regenerating LOD.

The log is appended when DynDOLOD.exe is closed. Scroll to the bottom for the most recent generation log.

 

 

Trying to move the MSTT to an additional ESL sounds pretty doable though, as RWT 2 has only 2 of these records.

It does not matter in what plugin type the MSTT overwrite is. The overwrites to references need to be in a ESM or ESL.

 

Those are two different things and they both trigger large reference bugs.

 

Whenever a reference is listed in the report, it will trigger the bug in the cell.

 

Whenever a large reference uses a MSTT record without the flag it will trigger the bug in the cell.

 

RWT happens to do both for some records, both have to be fixed.

 

Other changes that can trigger the bug regardless of plugin type are for example IsInitiallyDisabled flag, Enable/Disable via XESP, changed scale or bounds on the base record that make an object smaller below a limit for large references etc.

Edited by sheson
Link to comment
Share on other sites

 

It does not matter in what plugin type the MSTT overwrite is. The overwrites to references need to be in a ESM or ESL.

 

Sorry, but I don't really get what that means. "It does not matter in what plugin type the MSTT overwrite is" and "the overwrites to refrences need to be in a ESM or ESL" sounds kinda contradictory to me. ^^

 

Maybe I don't get a differentiation you are trying to make, but it sounds like you just said it does not and at the same time does matter what MSTT record-containing plugins are flagged as. 

 

As far as I understood, the correct approach would be to delete the MSTT base record override from RWT and create an identical record with Unknown 2 set in a new plugin flagged as .esm/.esl. Is this correct?

Edited by David2408
Link to comment
Share on other sites

Sorry, but I don't really get what that means. "It does not matter in what plugin type the MSTT overwrite is" and "the overwrites to refrences need to be in a ESM or ESL" sounds kinda contradictory to me. ^^

 

Maybe I don't get a differentiation you are trying to make, but it sounds like you just said it does not and at the same time does matter what MSTT record-containing plugins are flagged as. 

 

As far as I understood, the correct approach would be to delete the MSTT base record override from RWT and create an identical record with Unknown 2 set in a new plugin flagged as .esm/.esl. Is this correct?

MSTT (Movable Static) is a type of base record like STAT (Static).

A REFR (Reference) is a record that is placed into a CELL which "references" a base record.

 

If an ESP overwrites a REFR which happens to be large references, it will trigger the large references bugs. An ESM/ESL overwriting such a large reference will not trigger the large reference bugs. Certain settings on the REFR can trigger the large reference bugs regardless of ESM/ESL/ESP.

 

Any large reference using a MSTT base record without the flag set will trigger the large references bugs. It does not matter if the base record is defined or overwritten by an ESM/ESL/ESP.

 

Those are two different issues. The plugin type (ESM/ESL/ESP) only matter for REFRs.

Edited by sheson
Link to comment
Share on other sites

Where I find the Resources SE 2.42 beta?

2.41 beta is the most recent version of DynDOLOD Resources SE . That is why it is linked everywhere and that is why the last time DynDOLOD Resources SE was mentioned in the change log.

  • +1 1
Link to comment
Share on other sites

MSTT (Movable Static) is a type of base record like STAT (Static).

A REFR (Reference) is a record that is placed into a CELL which "references" a base record.

 

If an ESP overwrites a REFR which happens to be large references, it will trigger the large references bugs. An ESM/ESL overwriting such a large reference will not trigger the large reference bugs. Certain settings on the REFR can trigger the large reference bugs regardless of ESM/ESL/ESP.

 

Any large reference using a MSTT base record without the flag set will trigger the large references bugs. It does not matter if the base record is defined or overwritten by an ESM/ESL/ESP.

 

Those are two different issues. The plugin type (ESM/ESL/ESP) only matter for REFRs.

What the hell... This makes things much more complicated. Seems out of scope for me now, as the issue is twofold and I do not have enaugh knowledge on that whole topic. 

 

Thank you for the explanation, though.

Link to comment
Share on other sites

Hi, I generated "Skyrim 3D Trees and Plants BILLBOARDS 3.2.0" and I had a file in meshes / terrain / tamriel / tree / Tamriel.4.-44.28.btt (in the overwrite folder of Mod Organizer 2 )
I went into play but I do not see any changes, the LODs are still so ugly
I made a screen:
https://imgur.com/a/5PYVosD

You know why I have no good results? I followed the instructions to the letter

I thank you in advance for your help

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.