[VFS] Improving VFS Support

[Hazno-dev]

VFS now correctly captures encoded size from cftFileTable.

Not presently being used, but my goal is to migrate over hacky changes from my XSX branch into more finalized impls. If you'd prefer I can wait until everything is more finalized. But I wanted to try and push individual features where i can instead of 1 giga commit.

https://wowdev.wiki/TVFS

struct CFileEntry
{
  int8_t eKey[FileManifestHeader.eKeySize];
  int32_BE_t eSize;                          // compressed
  int??_BE_t eSpecEntryOffset;               // Offset to the EstEntry, is of variable length based on estTableSize in header. See [this note](https://wowdev.wiki/TVFS#Note_on_Container_file/ESPec_table_field_sizes).
  int32_BE_t cSize;                          // uncompressed
  if(FileManifestHeader.flags & FileManifestFlags::INCLUDE_CKEY)
    int8_t cKey[16];
  if(FileManifestHeader.flags & FileManifestFlags::PATCH_SUPPORT) {
    uint8_t numPatchRecords;
    struct CFilePatchRecord{
      int8_t eKey[FileManifestHeader.eKeySize];
      int32_BE_t cSize;
      int8_t pKey[FileManifestHeader.pKeySize];
      int32_BE_t pSize;
      uint8_t age;
    } patchRecords[numPatchRecords];
  }
} fileEntries[];

[Hazno-dev]

I dont like how github throws up all commits to a branch into the PR

[Hazno-dev]

I reworked the build config parser slightly. It now supports lookup for iterated keys (i.e. vfs-1 vfs-2) with TryGetRecords<T>. and GetRecords<T>.
It now captures VFS manifests and c/e sizes.

Lookup now uses a generic function.

Lookup now has an "enforced" key lookup (keys which are mandatory):
GetRecord<T> will throw on missing.
TryGetRecord<T> will not.

[neptuwunium]

Don't add ? in out T?, and use MaybeNullWhen(false) to sort the nullability out.

[Hazno-dev]

without out T? it can't properly resolve IBuildConfigRecord. there are warnings for every usage of TryGetRecord because its trying to get IBuildConfigRecord<T?>. The other things I can implement but with this, removing nullable on it would just lead to warnings everywhere.

[neptuwunium]

MaybeNullWhen(false) inverts the nullability based on the return condition. It automatically makes the type nullable based on the return value; https://dotnetfiddle.net/5M4KFi

NotNullWhen(true) does not have this behavior: https://dotnetfiddle.net/8rKNcn

[neptuwunium]

(Notably this also doesn't box primitive values into Nullable<T>)

[neptuwunium]

I do wonder if this is one of the reasons why Diablo 4 Steam isn't correctly loading whilst Battle.net is (needing to actually use the ckey and stuff probably.) Ideally we properly parse the full CFileEntry

[Hazno-dev]

I do wonder if this is one of the reasons why Diablo 4 Steam isn't correctly loading whilst Battle.net is (needing to actually use the ckey and stuff probably.) Ideally we properly parse the full CFileEntry

I'm in the process of working on some broader changes to VFS parsing, and subsequently CKey lookup. Currently it's all bound to the encoding manifest, which feels iffy because CKeys originate from more locations and not all builds have an encoding file. I'm thinking of moving CKey mapping into the ClientHandler directly.

I don't have D4 steam but if you have it installed once I get it finished it'd be great to test it.

[neptuwunium]

Please rebase this onto the https://github.com/overtools/TACTLib/tree/encodingless-vfs-behavior branch

VFS files technically can operate entirely without an encoding table (as seen in Diablo 4)

There's still some work left to be done in that branch as Diablo 4 Steam has an entirely different way of handling it's product files which is fun but it has some conflicts with this PR already.