This PR aims to start addressing `ESM` design issues that have silenced errors we incorporated into groundcover `ESM` loading approaches.
- We move the resolution of `parentFileIndices` from `ESMStore` to `ESMReader` as suggested in a `TODO` comment.
- We improve a highly misleading comment which downplayed the significance of `parentFileIndices`.
- We document important preconditions.
- We move a user facing error message to the highest level and improve its context.
- We remove an inappropriate `setGlobalReaderList` method. We now pass this reader list into the method that requires it.
- We remove a thoroughly pointless optimisation of `Store<ESM::LandTexture>`'s construction that has unnecessarily depended on `getGlobalReaderList`.
There should be no functional changes for `master`, but this PR should remove an issue blocking PR #3208.
With this PR we restore @elsid 's optimisations of countRecords we have unintentionally discarded in PR #3197. In addition, we give it a more appropriate name and add comments concerning its peculiar background.
The idea is to avoid std::map lookup for each CellRef. Instead generate a
sequence of added and removed RefNums into a vector then order them by RefNum
using a stable sort that preserves relative order of elements with the same
RefNum. RefIDs are stored in a different vector to avoid std::string move ctor
calls when swapping elements while sorting. Reversed iteration over added and
removed RefNums for each unique RefNum is an equivalent to what map-based
algorithm produces. The main benefit from sorting a vector is a data locality
that means less cache misses for each access. Reduces ESMStore::countRecords
perf cycles by 25%.
The resizing of LTEX store to the correct number of plugins was done in the load() method, but the load method won't be called if a plugin contains LAND records but doesn't contain LTEX records. For such plugins the Store<ESM::LandTexture>::search() function would then fail an assertion.
conversion from 'const float' to 'int', possible loss of data
conversion from 'double' to 'int', possible loss of data
conversion from 'float' to 'int', possible loss of data
