Blackread

My bad Those 7 were ITMs which I had cleaned away in between running AP and going through the large ref bugs.

After running DynDOLOD it reported several overwritten large references in the newest 3.0 version of Alternate Perspective, but when I went to check in xEdit, some of the overwritten references hadn't been edited by anything. Here's a list of all the false positives: Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000C2C90] (places FXMistLow01Long [MSTT:0007776F] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20)) Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000C2CAE] (places FXMistLow01Long [MSTT:0007776F] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20)) Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000C3B92] (places BurntRubble04 [STAT:000C2CB5] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20)) Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000C3BAB] (places FXfireWithEmbersHeavySCALED [MSTT:00106112] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20)) Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000C3BAC] (places FXfireWithEmbersHeavySCALED [MSTT:00106112] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20)) Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000E248E] (places CollisionMarker [STAT:00000021] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20)) Warning: Overwritten large reference in AlternatePerspective.esp [REFR:000F82AB] (places FXfireWithEmbersHeavySCALED [MSTT:00106112] in GRUP Cell Temporary Children of HelgenExterior02 [CELL:0000982A] (in Tamriel "Skyrim" [WRLD:0000003C] at 4,-20))

Sure, it's xx000D62.

Looks like I solved the issue. It was caused by the Nordic Ruins of Skyrim.esp having an exact duplicate of the object placed in the same spot, so the LOD I was seeing was generated for this duplicate, which wasn't a large reference. Thank you for your help once again!

Thank you, it seems I misunderstood how the large reference bug works. I tried a vanilla game with just that one plugin enabled, and I didn't see any LOD unloading issues with that object. Then I ran DynDOLOD against that load order and the problem returned. However, now that I better understand how the large ref bug manifests I took a look at some other objects in the cell, and for example these stairs are in the same cell, and a large reference I believe, but do not have any such issues. The LOD on the side is there as it should, since the smaller side parts aren't large refs, and the mid part does not have its LOD model displayed as expected. I disabled the object in console to make sure the LOD wasn't hidden underneath. So I guess this isn't actually a large ref bug, but something else? Here are the logs again: https://ufile.io/f/m0uug Both logs behind the same folder link. This time DynDOLOD did warn about deleted references, as I didn't have the cleaned vanilla plugins active, and about one missing script file, which presumably is fixed by USSEP.

I'm getting a large ref flickering bug on a nordic ruin object. LODs were generated with the latest DynDOLOD 3 Alpha 95. The reference in question is 372BA which is one of the large arches outside Ragnvald in The Reach. According to xEdit the reference is added in Skyrim.esm and not edited by anything else in my load order. DynDOLOD reported zero large ref bugs (or any issues for that matter) after being run. Any idea what might be causing this issue? The LOD unloads when the object enters uGridsToLoad, but when it's in the large ref LOD grid the bug manifests. Here are the logs for the last DynDOLOD run: Last DynDOLOD Log DynDOLOD Debug Log

That did the trick, thank you. ^^

I still have a couple plugins that get unresolved IDs even when loading alone, I'll attach them here. But it looks like, at least in the case of these plugins, it happens with disabled large refs. I can't say what the exact conditions are for the wrong position glitch. What I can say though, is that running the RNAM script on COTN - Falkreath.esp after adding the ESM flag does not resolve the issue. Judging by the log output, in the case of this plugin, the script only adds new refs, and does not update the vanilla ones. There's also the issue of large ref occlusion planes, which will also be affected by this glitch. So even after fixing the longhouse, the occlusion planes would still be left behind, and they'd need to be fixed too. I'll attach the modified COTN - Falkreath.esp here too. There are other mods I have seen this happen with too, like the aforementioned Great City of Solitude moving the Red Wave and RedBag's Rorikstead moving some cliffs in the surrounding area (which I separated into their own plugin, still resulting in this glitch). When going through all the overwritten large references I saw that at least Quaint Raven Rock also had several of these references that were moved to different cells, but I didn't inspect what that place looked like ingame prior to fixing it. One other mod suffering from this is eFPS. There it's not very apparent though, because the planes are always inside buildings anyway. But I wager that many of the large reference planes they moved to other cells aren't actually where they expect them to be. Large Ref Plugins.7z COTN - Falkreath.7z

I got the same result with the latest version. However, I noticed that if I loaded only the plugin (and its masters) I wanted to generate RNAM for, I got the right form IDs. Is this how the script is intended to be used? Although this only worked for plugins that only had a single master editing the same worldspace. If there were more the same thing happened. Sorry my initial post was a little light on details, I thought this was a known engine limitation. I'll give the full reproduction steps with COTN Falkreath here. I did the same as you, took COTN Falkreath, flagged it as ESM without generating RNAM and generated LOD with DynDOLOD Alpha 95. Then this is how I can get the glitch to manifest: 1. From the main menu, coc whiterun. 2. After loading into the game I did the following console commands (to help with testing): tmm 1, tdetect, tgm. 3. Fast travel to Peak's Shade Tower, southeast from Falkreath. 4. Run to Falkreath. The route you take shouldn't matter, but I beelined over the cliffs. 5. Be greeted with this sight: 6. Run up the hill to inspect the place where the object should be, to find a gaping hole: That's all of the steps. However, if you instead coc straight to falkreathexterior01 (be it from the main menu or after coc'ing to whiterun first), the object is in the right place. On both occasions this is what the record looked like in xEdit: On these tests I coc'd from the main menu, but the same bug occured on my full modlist when starting a new game via Alternate Perspective, so I don't think the manner of starting the game is relevant. The LOD is generated and displayed correctly: If you situate yourself a suitable distance south of falkreath you can get a situation where both the LOD and the full model are displayed: CRC of the COTN - Falkreath.esp: When I took these screenshots I had uGridsToLoad = 5 and uLargeRefLODGridSize = 11. However, this time when I tested with uLargeRefLODGridSize = 5 the glitch still happened. Active mods and plugins: The game version was 1.5.97. Here are the modlist and plugins in a text file format, along with my ini files: https://loadorderlibrary.com/lists/falkreath-test I also did a quick test with the original COTN Falkreath plugin without the ESM flag, and the glitch did not happen. If there's anything I forgot let me know.

Another question related to large references... I tried running the Skyrim SE - Generate Large References script on some plugins, and it sometimes results in non-existent form IDs ending up in the RNAM table. This seems to happen when there is an overwrite swapping the base object of a reference. The resulting form ID has the plugin index from the overwriting plugin, but the rest of the ID is from the plugin where the reference was introduced, resulting in a mismatched ID. Here's the log output when running the script on Water for ENB.esm and DLC2SolstheimWorld: [00.00] Start: Applying script "Skyrim SE - Generate Large References" Gathering large references added by Water for ENB.esm Overwrite: [REFR:04021003] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDC6] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 15,16)) Overwrite: [REFR:04024528] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDAD] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 7,17)) Overwrite: [REFR:0402452C] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDCF] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 6,16)) Overwrite: [REFR:04024534] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of DLC2StoneWater02 [CELL:0400EDD0] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 5,16)) Overwrite: [REFR:04026BDC] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDA7] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 13,17)) Overwrite: [REFR:04026D14] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDAD] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 7,17)) Overwrite: [REFR:040274AE] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400ED85] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 14,18)) Overwrite: [REFR:0402868C] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of DLC2POIChest01 [CELL:0400ED48] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 9,20)) Overwrite: [REFR:04031957] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400ED83] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 16,18)) Overwrite: [REFR:04033EEF] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDA7] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 13,17)) Adding 10 large references to DLC2SolstheimWorld [00.10] Done: Applying script "Skyrim SE - Generate Large References", Elapsed Time: 00.10 And here are some of the resulting entries in the RNAM table: I was using the version of the script that comes bundled with xEdit 4.0.4

I was wondering, since DynDOLOD already warns about overwritten large references and large references with the Initially Disabled flag, would it also be possible to add a warning about large references that have been moved outside their original cell? At least on my setup these kind of edits seem to fairly consistently trigger an issue where the data of the last plugin that places it in the origin cell is used instead of the override which moved it to another cell. This is especially true whenever the large ref system is enabled (uLargeRefLODGridSize > uGridsToLoad). As an example, COTN Falkreath swaps the model of the Jarl's Longhouse and moves it up the hill (which is to say, into another exterior cell). If I have uLargeRefLODGridSize = uGridsToLoad it works fine, but if I enable large refs the longhouse ends up in its old position and using its old model. I can work around this with the disable & duplicate trick, but finding these issues would be a lot easier (and faster) if I had a list of all the records that need to be addressed, instead of having to manually check every overwritten large reference.

Thank you for the tips. To update on this, I found another mod that suffered from the same issue, our old aquaintance RedBag's Rorikstead. Although, it doesn't seem like every instance of a large ref being moved to another cell triggers this. E.g., COTN Falkreath moves the Jarl's Longhouse ref from its original position up the hill towards the nordic ruin, but there weren't any issues in Falkreath prior to me turning the large ref system on. After I did turn it on however the longhouse stood smack bang in the middle of the town square. xD It seems that if you have the large ref system on, any large refs being moved out of their origin cell is a quaranteed way of triggering the bug, but if the system is not on it will only happen rarely on some unknown condition. But since I am planning to be using large refs, I guess I have some patching work ahead of me... By the way, if you remember the crashes I had with RB's Rorikstead a couple weeks ago, turns out they were still happening after I moved my navmesh edits to a separate plugin. Only after going back to separating the large refs into their own plugin and removing ESM flag from the main plugin did the crashing stop.

Regarding this, do you happen to know what would happen if I were to generate the RNAM table with multiple plugins that make edits to the Tamriel worldspace? Would the tables be merged together with all the new additions, or would only the last override carry its changes over? Would I need to create a patch where I merge these edits together?

Yeah, I guess the duplication workaround is the best solution here. Thanks for the input. I was familiar with the DynDOLOD Large References manual page, but it doesn't mention moving large refs to another cell if I'm not mistaken. Thanks for the discussion link. I will probably have to fix that same occlusion related large ref bug myself too in the future.

Update: As a workaround it seems that saving the game, exiting to main menu and loading the save does put the boat back in the right spot, but I would rather fully resolve this issue if possible.

I'm posting this in multiple places in the hopes it catches the eye of someone more knowledgeable, because I've never encountered an issue like this before and I'm completely stumped by it. If I make a new game from the main menu, run to Whiterun and take the carriage to Solitude, Skyrim somehow does not recognize all the plugins that edit the large ship, the Red Wave, at the docks, but only uses the data from the second plugin of a total four: Realistic Boat Bobbing.esp. But if I instead coc straight to the docks (solitudedocks01), the data is read properly and the ship is at the right place. It seems that if I approach the docks from from an angle where the cell where Realistic Boat Bobbing places the boat (i.e., vanilla location) loads first, the boat ends up at the wrong place. But if I instead coc straight to the location where both cells are loaded or come from the direction of the Dainty Sload/Lighthouse, so that the cell of the new location is loaded first, the boat is at the right place. Here's what it looks like if I take the carriage and run down to the docks: https://i.imgur.com/jtmnQi9.png However, the door of the Red Wave does end up in the right position at all times: https://i.imgur.com/eiGXI12.png Here's what the record for the Red Wave looks like in xEdit with my load order: https://i.imgur.com/mJYSWZQ.png Here's what it looks like if I coc straight to solitudedocks01: https://i.imgur.com/YymhcTG.png One thing that occured to me is that I believe the ship is a large reference. All the plugins editing the ship are ESM flagged, but is there some limitation to moving large references between cells? Would I need to update the RNAM record somehow, and if yes, how would I go about doing it? xEdit does not seem to display the RNAM at all, or at least I haven't been able to find it.

Yes, I actually never meant to imply that this was a DynDOLOD issue. I mainly made a post here because there was a similar looking crash report that seemed to have been somewhat unresolved. I can't take credit for the separate large ref plugin trick, as it's actually from the DynDOLOD Large Ref guide. But it is likely the least error prone solution in many cases. I often just ESMify the whole plugin out of laziness. xD

In terms of the records edited by RedBag's Rorikstead, the relative order of the overwrites did not change between being an ESM or not. When ESM flagged the only plugins that were overwriting records from RedBag's Rorikstead were patches for RedBag's Rorikstead (non-ESM), that will overwrite the plugin regardless. In terms of assets, they are all packed in a bsa and all the overwrites are loose files, so no change there either. The DynDOLOD Output I was testing this with was generated with the ESMified version of the plugin, so if anything, it was the non-ESM plugin that should have made it invalid and unsafe. Of course, removing the ESM flag did change some things in the overwrites, because the DynDOLOD.esm plugin overwrites disabled large references with its activator thingy, and these were reverted when the ESM flag was removed and the plugin moved above DynDOLOD.esm. But if this was the cause of the crash, just removing DynDOLOD output should have resolved it, but it didn't. But prompted by your suspicion I decided to do some further testing. I placed the plugin as the last ESM plugin. This way, at least to my knowledge, the only thing that changes between adding and removing the ESM flag is the flag itself. With the flag the game crashed, without it didn't. Next I took the original plugin from RedBag's Rorikstead, with the ITMs and deleted navmeshes intact, and added the ESM flag to that. This produced no crashing. Next I ran the plugin through the QuickAutoCleaner. This removed the ITMs, but left the deleted navmeshes. No crashing. Then I copied over the four edited navmesh records which I had separated into a new plugin here https://www.nexusmods.com/skyrimspecialedition/mods/69952, deleted the Navigation Mesh Info Map and regenerated it in CK. Now the game started to crash again. Then I once again took the original plugin, cleaned ITMs, applied ESM flag, and this time used the separate plugin to overwrite the deleted navmeshes. These four navmesh records were edited in my LO by only Skyrim.esm, RedBag's Rorikstead.esp and my navmesh undeletion plugin. Now there were no crashes. Putting all this together I would conclude that you were right in that it was a navmesh related issue. Not in terms of conflicts, but some undetermined latent issue with my edits to the deleted navmeshes that would only manifest if the plugin had ESM flag applied to it. At this point I have pretty much tested all I can think of myself, and probably have reached the limits of my knowledge as well. I'll attach the broken plugin here in case you or someone else wishes to investigate this further. Thank you for your scepticism. It didn't make a big difference in the stability of my game as I had already resolved this issue in an alternative manner by separating the large ref edits into a plugin which I flagged as a master, but I did gain some more insight into the issue thanks to this more granular testing. Thank you for the advice in your bullet points, but I am already doing all of those things regularly. But they without a doubt will help others reading this thread. When it comes to Moon and Star though I can't say for sure what's going on with that one. My last experience with it was a couple years ago, around the time I published my ESMifier script. It very well may be that one was just a load order issue. I certainly wasn't as meticulous and thorough back then. Maybe I will revisit that subject some day again. RedBag's Rorikstead.esp

I don't think that's the whole truth here, as I have used the same script on many other plugins without issues, like all of the Great City/Town/Village mods by soldierofwar. But this falls very much outside my expertise too. Two other mods that produced crashing when ESMified were Moon and Star and the 2020 Grand Paladin remake. Other users have reported similar issues with these mods too.

I used this script for the process: https://www.nexusmods.com/skyrimspecialedition/mods/40260 It applies the ESM flag and flags some NPCs as persistent. However, RedBag's Rorikstead does not add any new NPCs, so the script only applies the ESM flag. I only have the lod texture fix from the mod page actually, I have not attempted to fix the other textures. Not really sure how I would go about doing so without messing the UV mapping.

A couple days ago I was googling for information related to a crash I was experiencing, and I found a post made here earlier this month: Having now solved this crash I thought I would make a reply here to provide some information that may help in the future, if someone else shows up with a similar crash. To be exact, I was actually experiencing two different crashes. One with the same address as Joe9075 https://pastebin.com/QftfaANk and another at a different address https://pastebin.com/fFsvKSQs. However, these both reference pathing related things, so I suspect they are very much related. My crashes were predominantly happening upon fast traveling or shortly after arriving at my destination, but they could also happen when simply running around. First I tried to solve this with the binary search method of disabling mods, and I did find a complete list of mods that, when enabled, caused the game to crash. They were as follows: Praedy's Staves AIO Salt and Wind - ApachiiSkyHairMale SE v1.2 Retexture Prince and the Pauper Simply Realistic Armor and Weapons Grass Cache DynDOLOD Output If even one of these mods was enabled the game would crash, and with all of them disabled it was crash free. However, I found this very unbelievable, as I had used some of them for a long time, and how could a hair texture replacer cause a pathing related crash? So I tried another approach and started reverting my recent changes to my list. Quite soon I found out that the real cause of the crash was actually my collection of ESMified plugins, and eventually I narrowed it down to the plugin from RedBag's Rorikstead. I removed the ESM flag, and the crashing was gone. As to why flagging this plugin as a master produced crashing, I have no idea. It seems that some plugins just don't like being ESM flagged, I have seen the same behavior in the past with a couple other mods too. Checking for errors and running the QuickAutoClean revealed nothing. Though the original plugin from RBR does have 31 ITMs and 4 deleted navmeshes, but I had already fixed these for my modified version. - name: 'RedBag''s Rorikstead.esp' dirty: - <<: *reqManualFix crc: 0x471AAB46 util: '[SSEEdit v4.0.4](https://www.nexusmods.com/skyrimspecialedition/mods/164)' itm: 31 nav: 4 dirty: - <<: *reqManualFix crc: 0xF229C160 util: '[SSEEdit v4.0.4](https://www.nexusmods.com/skyrimspecialedition/mods/164)' nav: 4 Anyway, I hope this information can help someone else experiencing the same crashes. If you have any questions I will try and answer them, assuming I get notifications for replies to this post.