Blackread

Ah thanks for the explanation, I wasn't aware that references disabled via enable parent also trigger the bugs. I can test this too. In the meantime, seeing as this will probably be the way moving forward, I generated full LODs with the workarounds enabled and checked the cells reported having bugs in the logs - which was painful, I doubt I'll do this ever again. I found very few references that had both the full and LOD model appear at the same time. Here's the full rundown: Here are the logs for the generation: https://mega.nz/file/oK0EXKZA#-j__STXxB7dBA8srl5Z7XqSgfQE-gMe932k_kSWJILg I also included the custom RedBag's Rorikstead plugin and my modified version of the main plugin it was designed to be used with. If this interests you and there's anything you need let me know. Of course my load order isn't super massive and it is already prepared for large references using the old methods, so I'm probably not the ideal test subject.

Using the workaround got rid of the issue. I found the workarounds guide a bit confusing though. It says that the advanced mode has a new checkbox Downgrade FarGrid references to NearGrid which is necessary without the workarounds, but it's available only when enabling the workarounds. Does that mean that if the workarounds are disabled the checkbox is always selected but hidden?

Hello sheson, I am once again looking for assistance with LOD overlapping loaded large reference models. This time I'm having problems with Obscure's College of Winterhold. The issue seems to affect all or almost all of the references OCW places in the cell 28, 27. Naturally they aren't large references by default, but have been made such in my game (with the usual script). Some examples are: xx4e43d1 xx4e43d3 xx4e43ce xx4e43cb xx4e43c4 Looking at things in xEdit I noticed that DynDOLOD.esm replaces the base objects in the equivalent vanilla references with ones that have had the Has Distand LOD flag removed. I was wondering if this is relevant and whether I should do a similar thing to the OCW references that replace the vanilla ones? Anyway, here are the usual logs: https://mega.nz/file/YT8xjbxD#EYzt1jNYLf2Na8Mu0JakqCRR8z9MBthBe739G1HJa14 Additionally, the first 3 or 4 times I started TexGen after updating to Alpha 98 I got a Duplicates Not Allowed error. I haven't been able to replicate this since, but I thought I'd share the logs for that too: https://mega.nz/file/cGdUDIib#WmOyEAiQg4AQaJERJHVG-qR1qIr-0iGNK7ELkl7c2GE

All right, I did some tests. Unfortunately simply running Soulcairn only with Alpha 97 produced no errors, so I couldn't really test that. But I did a few runs using the provided exe with all worldspaces, and there were no errors, so likely this has resolved the issue.

It is repeatable, but the referenced object is different every time. Here are a couple more examples: The latest DynDOLOD run went through successfully, here are the logs for that one: https://mega.nz/file/FfNW3TIL#Dy5virj2AnhOIn_K2nLiPnaMpAPSdlUMZUsl1n_kwjY Here are what I ticked in the FOMOD for The Soul Cairn: I had to reinstall the mod after the first errored out run, because I no longer remembered what I had chosen. But these were used for the three reports here. I believe that mod is the last override on all the records and/or models, if there are any. Some records are completely vanilla.

Got an error during my most recent DynDOLOD run: Here are the logs: https://mega.nz/file/lCUTEbBK#EIM3VlBQqyeBFtAOAxGB-b_CxmGMcbG5ezTktL9gsoU

Just wanted to say thank you for the "report moved large reference" feature. Makes my life much easier! Edit: Actually I may have misunderstood this. What does this exactly report?

Alright, thanks!

This video shows what I always did when testing: But in short, I would use the command "cow arnimaduplicate003 21 -3" in the main menu, run up the little hill on the left, and then enter free cam to go inspect the objects.

Almost. After the rock was placed in the right grid list, everything else worked except the rock itself. I assume this is because the rock was placed right on the cell border. It's a bit hard to see on the vanilla pic, but I made sure by disabling the object that there was indeed LOD mixed in. I nudged the rock one unit towards the 18 -2 cell, and after that there were no more issues. The LOD also had to be regenerated after moving the rock, otherwise it wasn't properly registered as a large reference. After this last tweak I haven't seen any more large ref bugs in the area!

Yes, it was in the grid list for 18 -3. Damn, I never noticed that it's in the wrong cell. Here's a screenshot I took while I was doing the testing that shows it (I had removed the tundra stream objects first). And yes, just tested it, the github script also put it in the wrong grid list. The attached script put it in the correct grid list! Seemed to do it a lot faster too.

I managed to fix it and you're not going to believe this. Just out of curiosity I started removing the large refs one by one from that cell, and after I removed the ref xx041be6 the bug disappeared. So I regenerated the refs and only removed that ref, no bug. And this time it carried over to my full modlist, just generated full LODs, no bugs in that cell. Here are the refs that remained: And here's the test plugin, large refs generated only for arnimaduplicate003 and xx041be6 removed, in case you're interested: https://drive.google.com/file/d/11dFgqgmNoOA5xWHO6L6l25zAg_h3VS_8/view?usp=sharing

Tested, same bug.

I forgot to mention, the two last tests I conducted were done with just the base game plugins and arnima.esm active. But I checked anyway, the only plugins to edit or add anything in that cell are DynDOLOD.esp which adds those tundra stream LOD objects and DynDOLOD.esm which adds an activator.

Well, I did do two more quick tests after all: Beyond Reach 4.6 overwritten with your plugin from 4.51 - bugged Beyond Reach 4.6 where I generated large refs to arnimaduplicate003 with the script you gave me - bugged So the only time the cell wasn't bugged was when I generated LODs with Beyond Reach 4.51 and then overwrote that one lod settings file with the one from 4.6. I think I'm just writing this off as unresolved. Edit: I just noticed, the new script you gave me produces overwrites for the Tamriel worldspace too, how interesting.

I honestly don't know. And now that I finally managed to regen my LODs it seems that even though the problem disappeared with just the mod itself loaded, it is still there with my full list. Maybe I'll get back to this later, but right now I'm feeling quite ready to give up.

The .lod files are still in the BSA. Not sure what has changed, but the CRC32 is different. Thank you for the texture path fix, TexGen ran succesfully to completion.

It appears that the file that fixes the issue is lodsettings\arnimaduplicate003.lod. Taking all other files from Beyond Reach 4.51 but that one file from 4.6 the cell is no longer bugged. At least with this barebones setup, we shall see if this behaviour carries over to my full mod list. By the way, with the 4.6 update TexGen aborts its execution with this error message: It seems the textures were relocated to textures\bscyrodiil\architecture\farmhouse in this update.

The LOD was disabled. But it seems that somehow, no idea how, the latest update to beyond reach has fixed this. And not even the plugin, I am still testing with the same plugin you gave me, but loading the game with the same LODs and the same plugin from yesterday but the new assets from today the bug is gone.

Ah, that explains. Well, this is a stubborn one. I've done everything I could think of, but the cell is still bugged: I've gone to a bare minimum list, I've reset my DynDOLOD rules to the default high, and I switched from papyrusutil to DynDOLOD dll. With vanilla meshes it's not as visible as the LODs are mostly covered, but it's still there. Can't think of anything else to try and fix it.

I did some quick tests with your plugin and comparing it to mine. With my generated LODs the bug was present with both. With the pregenerated LODs from the mod it was absent with both. I'll do a full LOD regeneration with your plugin just to be sure, as it looks like they are different based on CRC32. Here are the overwriting plugins: Worldspace: Beyond Reach - Skyrim Border Tweak.esp, DynDOLOD.esm, Missives - Beyond Reach.esp, Water for ENB - Patch - Beyond Reach.esp, ACMOS - Beyond Reach.esp, Clear Map - Water for ENB Patch.esp (this is my personal plugin patching the latter two together), Synthesis.esp, DynDOLOD.esp, Occlusion.esp Persistent Worldspace Cell: Beyond Reach - Skyrim Border Tweak.esp, DynDOLOD.esm, Missives - Beyond Reach.esp, DynDOLOD.esp Cell: DynDOLOD.esm, Occlusion.esp

Here it is: https://ufile.io/jews6e37 I have (manually) merged some fixes into it.

I'm afraid not. I removed the old large refs, redid them with this version of the script and regenerated LOD, but that cell was still bugged. But I did notice that a couple initially disabled references that were added with the old script were not added with this one, so that's helpful. With the old one I had to delete them manually afterwards when the DynDOLOD Summary reported them.

Tested it now, with uLargeRefLODGridSize=5 there's just LOD models as expected. The large references were generated with that version of the script.

After my latest DynDOLOD run I decided to run around the arnimaDuplicate003 worldspace from Beyond Reach to check what the lods look like and if there's anything I would need to fix. While doing this I came across a cell with large reference bugs. The plugin doesn't have large references by default, but I added them myself with the xEdit script. The cell with the bugs is 18 -3. So I started checking the objects in the cell to see if there were any that had the initially disabled flag. I couldn't find any in arnima.esm nor in DynDOLOD.esm or Occlusion.esp, which were the only plugins to edit the cell in question. DynDOLOD.esp does add some tundra stream objects in there that are initially disabled, but since they aren't large refs they shouldn't be the cause of this issue right? There are 8 large refs in the cell, 2 of which are tundra streams. I found 5 objects being affected by this, so it does seem to be a legitimate large reference issue. It also only affects just this cell, neighbouring cells are all completely fine. Do you have any ideas what might be causing this bug? DynDOLOD didn't report any large ref issues when running it. Here are the relevant log files: https://ufile.io/f/cmfrr Edit: Noticed that the tundra stream objects might not be affected by this, but I think their LOD is handled a bit differently?