This avoids the issue of hash collisions, within any one archive, a plugin's archives, or between different plugins' archives. That means that sorting has accurate data on what the asset counts loaded by plugins are, and what the asset overlap between plugins, so it can make better decisions when adding overlap edges.
It does require that the archives include the folder and file names, which is apparently not strictly required, but it seems that having the names is practically required[1][2], and I verified that the parsing code can handle archives from all of the supported games (apart from Morrowind, which doesn't have its BSAs read by LOOT). That testing covered 321 archives containing 771246 folder records and 3404007 file records, including some mod BSAs/BA2s.
If an archive doesn't have the flags set for containing folder and file names, then libloot will log an error and effectively ignore its contents, so the new behaviour means that some archives that were (potentially inaccurately) taken into account before may now be ignored. Falling back to using the hashes for archives that don't have names would be an option, but that complicates comparison against archives that do have names, and I have no evidence that the fallback would be useful in practice.
This doubles the size of each map key and set entry (from 8 to 16 bytes), introduces another level of indirection when comparing keys or values, and also means that the name strings need to be stored, further increasing memory usage.
I tested the performance impact when sorting Skyrim SE and Starfield load orders, using LOOT v0.29.1 and comparing against using it with libloot v0.24.4:
- The Skyrim SE load order had 1630 plugins and 18 BSAs totalling 3.14 GB (not including Skyrim.esm's or its BSAs, which LOOT doesn't fully load).
- Loading plugins (which includes parsing BSAs) was ~ 2% (5 ms) faster
- Sorting was ~ 1% (21 ms) faster
- Memory usage after sorting was 1 MB (< 1%) higher
- These differences are probably within margin of error
- The Starfield load order had 31 plugins and 72 BA2s totalling 20.2 GB (not including Starfield.esm or its BA2s, which LOOT doesn't fully load).
- Loading plugins (which includes parsing BA2s) was ~ 96% (423 ms) faster
- Sorting speed was unchanged
- Memory usage after sorting was 11 MB (12%) higher
It looks like the accuracy improvement is also faster, and the memory usage cost is relatively modest.
[1]: https://en.uesp.net/wiki/Oblivion_Mod:BSA_File_Format
[2]: https://en.uesp.net/wiki/Skyrim_Mod:Archive_File_Format
Feedback from Robert on Discord[1] is that hash collisions can be very common for certain mods.
Since erroring causes that archive's assets to be ignored, it results in less accurate sorting behaviour than not erroring, and if there are many hash collisions then logging them just produces noise.
Instead, count the number of collisions and debug log a single statement if it's non-zero, so there's still some indication to aid debugging any unexpected sorting behaviour it causes.
[1]: https://discord.com/channels/473542112974077963/473542230095822848/1498060566344896673
The linked Discord message (and a few following messages) is:
> pretty sure for Skyblivion we have > Many duplicates all over our files
and i mean A LOT
> but 100s of thousands of files that i'd expect
> [...]
> quirks of the hashing formula the game uses
>
> -- Robert in #support at 2026-04-27, 21:36 PM
It drops compatibility with Python 3.11, but I don't think that matters: the dev container is based on Debian Trixie, which has 3.13, and CI is configured to use 3.13.
This was done by running `doxygen -u Doxyfile`, using doxygen v1.9.8, as that's the oldest version used in CI, and the latest version (1.16.1) doesn't warn about any other settings being obsolete.
Oliver Hamlet
Oliver HamletandGitHub
dependabot[bot]andGitHub