Closed bananaturtlesandwich closed 11 months ago
I would prefer unrelated changed like these be broken up into separate PRs so I can review and merge them individually.
At it stands, I don't think there should be any assumptions of the internal pak file structure (such as inferring game name) by anything in this library. Paks are used for more than assets in shipping builds.
I would also prefer internal pak integrity checks be fully implemented rather than disabled. Disabling it along with tests depending on it makes it more likely they get unintentionally broken. Path hashes are quite small in relation to the rest of the pak (even just entry paths are significantly larger) so it shouldn't have a significant impact on performance. However, if you provide a benchmark (benchmarks would be nice to have in general) showing they do have non-negligible impact I'm open to reconsidering.
honestly with that in mind only the second change is worthwhile
should be fine now
this'll probably be the last api one now since I'm really happy with everything else (except files() returning a vec but otherwise it would leak a private type and passing in an aes key rather than a slice but I get users can make aes keys in other ways)