sheson Posted July 25, 2018 Author Posted July 25, 2018 (edited) 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 July 25, 2018 by sheson
tjbassoon Posted July 27, 2018 Posted July 27, 2018 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?
zoid8806 Posted July 27, 2018 Posted July 27, 2018 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!
sheson Posted July 27, 2018 Author Posted July 27, 2018 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.
David2408 Posted July 27, 2018 Posted July 27, 2018 (edited) 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 July 27, 2018 by David2408
sheson Posted July 28, 2018 Author Posted July 28, 2018 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
David2408 Posted July 28, 2018 Posted July 28, 2018 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 testYes, 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 thatYeah 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.
David2408 Posted July 28, 2018 Posted July 28, 2018 (edited) 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 DragonbornNo Snow Under The RoofCLARALUXRealistic 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 July 28, 2018 by David2408
sheson Posted July 28, 2018 Author Posted July 28, 2018 (edited) 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 July 28, 2018 by sheson
David2408 Posted July 28, 2018 Posted July 28, 2018 (edited) 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 July 28, 2018 by David2408
sheson Posted July 28, 2018 Author Posted July 28, 2018 (edited) 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 July 28, 2018 by sheson
sheson Posted July 28, 2018 Author Posted July 28, 2018 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
David2408 Posted July 28, 2018 Posted July 28, 2018 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.
KountervibeJVC Posted July 31, 2018 Posted July 31, 2018 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 uglyI made a screen:https://imgur.com/a/5PYVosDYou know why I have no good results? I followed the instructions to the letterI thank you in advance for your help
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now