This is a big API change, and it's probably not in it's ideal
shape right now. Physis makes a big assumption that the pool of
game data that you're reading from is in the compressed, SqPack
format like in retail. However, as the projects that use Physis
expand - so does the scope of data people want to punt into it.
For example, we have Icarus that makes it easy to read Excel data
but it can only do so through SqPack which makes it less useful in
scenarios where you want to read unpacked Excel modded files or
perhaps Excel data from the network.
So I created a Resource trait that GameData now implements (and
it's now called SqPackResource.) In a similar vain, Physis comes
with an UnpackedResource and a ResourceResolver to chain multiple
Resources together.
These have unknown instance objects, and were tripping up our parsing. I
don't know what these are yet, but I added them anyway.
I also made sure that the parser doesn't return None for technically
valid but empty LGB files.
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.
This is a bit of an awkward API, because we have to manually keep the
CRC list up-to-date when in other cases that's left up to consumers. I
added a comment about how to figure out this value.
As suspected - this was a little slow, and can be corroborated with
Hotspot. This is only a marginal increase in performance, it isn't huge
but still worth doing.
Apparently we were reading packed booleans wrong the whole time
(whoops!) They are packed into *bytes*, oops... That is fixed now, and I
also expanded write support for packed booleans. It makes the assumption
that the byte is always at the end of the row, but I think that's OK for
now.
I also added a good test-case for this, the PhysicsGroup EXD. It has a
lot of rows, and some packed booleans thrown in. The columns also have
out-of-order column definitions (as in, their offsets don't increase in
order.)
Now we can re-create OpeningSystemDefine, and is added as a new test
case to test reading/writing string columns. This was actually quite
fun, it turns out that they like aligning the data sections to a 4-byte
boundary for some reason.
Expanding upon the EXH tests of this same data, we can successfully
write it back (hence why it's testdata now!) A lot of the writing logic
is specific for this EXD, but it's a start.
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.
Apparently X-Patch-Length is only for the base repository, and so isn't
a reliable indicator. But it's pretty simple to add them all together to
get a close number.
