[1001Bits]

A v5 plugin can read another plugin's v2 id/offset table as its offset array, because every format shares one mapping name. That gives "Failed to find offset" for ids that are in the Address Library, or silently wrong addresses.

Reported on Base Object Swapper's page on 1.7.104 (Nexus thread):

IDDB.cpp(459): po3_BaseObjectSwapper.dll Failed to find offset for Address Library ID! ... Invalid ID: 401203. Game version: 1.7.104.0

As powerof3 pointed out there, 401203 is in the 1.7.104 database: the official versionlib-1-7-104-0.bin maps it to 0x31DFB70.

Why

• load_v2, load_v0 and load_v5 all use COMMONLIB_IDDB_OFFSETS_<game version>, and FMemoryMap::create opens an existing mapping of that name before mapping its own file. So the first plugin to load decides what every later plugin reads.
• v2 (and every commonlib-shared from before v5 support) stores sorted 16-byte { id, offset } pairs there. v5 maps the raw file and reads data + 0x60 as a std::uint32_t array.
• A plugin built with a pre-v5 commonlib-shared refuses the 1.7.104 file by itself, but tools that serve old plugins the format their loader expects (CompaSSE does this) let it build a v2 pair table under that name. Any v5 plugin that loads after it reads the pairs as offsets.
• The same failure shows up on CompaSSE's page: REL/IDDB.cpp(459): race compatibility-skse.dll Failed to find offset ... invalid ID: 400475 ... 1.7.104.0, gone after removing CompaSSE (comment). An earlier report of every SKSE plugin failing this way was traced by its author to "outdated custom data that CompaSSE.exe builds for !CompaSSE.dll to utilize when it runs old mods alongside new ones" (comment).
• Rebuilding that pair table from the real 1.7.104 file and reading it the way load_v5 does: of the 435,162 ids in the file, 217,576 read as 0 (the error above; 401203 is one of them) and 217,586 read as a wrong non-zero offset, which is worse because nothing reports it.
• The other order fails too: a v2 plugin that loads after a v5 plugin opens the v5 file's mapping instead of building its pair table, and stops with "Failed to create Address Library MemoryMap".

Changes

• load_v5 uses its own name, COMMONLIB_IDDB_OFFSETS_V5_<game version>, so v5 plugins share a mapping only with each other.
• After mapping, load_v5 checks that the mapped header matches the file it read, and fails with a message that says the mapping came from another plugin instead of the misleading "needs to be recompiled".

v0/v2 keep the old name, so they still share with older builds of the same format.

Testing

• Builds (x64-windows-static-md, no warnings)
• Offline check of the collision with the real 1.7.104 file (pair table read as a v5 array gives 0 for 401203)
• Not run in game

[shad0wshayd3]

If CompaSSE is breaking other plugins, then CompaSSE needs to be updated to not do that.
It is impractical for every other plugin to be recompiled with this change to fix it for one ill-advised utility.