Closed KABoissonneault closed 6 months ago
Gah, stupid logic screw up on my part. The second assignment should have been |= and that's the fix I'd have made. Your fix does make it a bit clearer though. Thumbs up from me for merging.
BTW If you see anything like this in my DFU code in future please feel free to just let me know and I will deal with it. (slower maybe tho) While I appreciate the fix and the long explanation, I think you can probably use your time better.
Before the change, the logic for whether to cache the result of
WorldDataReplacement.GetDFRegionAdditionalLocationData
was as follows:AddLocationToRegion
pretty much always returns true. Therefore, if we have any loose files,success
is assigned true in the first loop, and the second loop will dosuccess = true & true
, andsuccess
will stay true.If we do not have any loose files,
success
stays false, and the second loop will dosuccess = false & true
, makingsuccess
false.This means setups where a region has new locations in packed mods but not locations in loose files always fail to cache the result, resulting in poor performance and log spam. This process is called each time a map pixel is loaded.
How to repro:
betony restored.dfmod
in a release build (editor builds never cache results, so that doesn't change)locationnew-*-19.json
(new betony locations)With this change, I changed the logic to
We still only cache if no errors occur in the process, but at least we don't need to go through loose files to start as true.