ra2phoenix

Ran the test exe on my full load order and confirmed all problems forwarding into Occlusion.esp are resolved.

Ran a basic test with just USSEP and Water for ENB enabled, on the current release version. Some cells that are broken: x9712, 9713, 9732, 963A, 97A0 I see in the logs that's it's copying the esm data on the affected cells. Logs attached: https://www.dropbox.com/scl/fi/l3iymffwkb39y50jcjps8/OcclusionLogs.7z?rlkey=1wg3l4n7htww7oa51a9dirtoh&dl=0 Reran the test with the beta exe linked above, and all of the issues appear to be fixed. I'll give my full load order a test with the exe to see if the various Encounter Zones, EdIDs, etc. are also correct but it looks like it should be good now.

Noticed some values were not being copied from the winning plugin into Occlusion.esp. By looking through the missed forwards in my large load order, the pattern is that every Cell with missing data has DynDOLOD.esm in the overrides but not DynDOLOD.esp. I'll try to generate this on a smaller load order that isn't 2k plugins, but maybe it's enough to go on - I believe that since the ESM is generated at the bottom of the "stack" during the DynDOLOD session, that it's treating it as the winning record for Occlusion.esp unless DynDOLOD.esp was also generated for that cell. There must be some mechanism that it uses to skip this new record when copying the base data for DynDOLOD.esp (or we'd see this problem there, and I don't based on Water for ENB waterflow edits etc.) that isn't replicated for Occlusion.esp generation. Tldr is that in a large load order there are many instances of the winning record's non-vanilla XLCN, EDID, XCWT not being correct in Occlusion.esp and in every single case there is a DynDOLOD.esm with vanilla data higher in the overrides. I'll try to replicate in a controlled fashion with logs tomorrow unless this is enough to identify a code problem.