I broke this when changing a split to split_once I think, and it stayed
broken longer than it ever should have. To stop that from happening
again, more tests are added to catch this.
I updated our dependencies like binrw to 0.15, which is pretty nice as
that means we no longer depend on Syn 1.x. I also finally upgraded to
bitflags 2.x, which doesn't really mean anything except we're on
better supported version.
Additionally, I removed some bitrotten code that no longer compiles.
This was mostly benchmark stuff, but since I don't actively keep track
of that I felt it was better to remove it. I can always add it back once
I'm ready to tackle that again.
This simplifes the handling of "new installs" in applications like
Astra, who may end up calling GameData::apply_patch on an "invalid"
GameData struct. We should allow applications to still hold onto these
so it keeps track of game_directory.
I'm an idiot, these row ids are here for a reason and are important for actually
reading Excel sheets. The API has changed to a read_row() function that takes a
row id, and I'll improve it before release.
This is to make way for another dat module (for the stuff under the user
folder.) This kind of re-organization was inevitable anyway, and I gave the
structs new SqPack-y names to fit their new home.
Now it reads much more of the index file format, and tries to handle
index1/index2 differences more opaquely. I'm not yet happy with the API, it
needs a bit more work.
So we had a couple copies of a Platform enum, so now there's a public
one in the common module. It wasn't possible to specify what platform
the GameData is, so now it's part of initialization. While I'm at it,
remove the stupid reload_repositories() requirement and make that a
private part of the API.
We can simplify some of the repository code since there's now two
separate functions for base/expansion repositories. Added tests to make
sure reading doesn't regress like it did before.
In Hotspot it was revealed that a huge chunk of performance is lost due
to repeated IndexFile::from_existing calls, which may be on the same
index file. Now GameData transparently keeps a cache of these in memory
which speeds up the slowest link here.
Currently, we not handle repairing version files well, so I
sought to seek a solution to the problem. This is one of part of the
puzzle, by implementing a simple "game repair". This is not
IndexedZiPatch support, but simply checking if we can restore version
files if possible, or otherwise wipe the directory.
