v0.2.0 does not accommodate .6.ftexs file extensions

Atvaark / GzsTool

Fox Engine/MGSV/MGS dat, fpk, fpkd, pftxs and sbp unpacker/repacker

MIT License

66 stars 18 forks source link

v0.2.0 does not accommodate .6.ftexs file extensions #15

Closed folly-ah-duh closed 4 years ago

folly-ah-duh commented 4 years ago

For whatever reason, the source code has no references to the .6.ftexs extension. The release works as intended, so does this mean that the source code is misaligned with the release's executable?

https://github.com/Atvaark/GzsTool/blob/82f08c6f7ec5bc95046490797b53d837f6e05944/GzsTool/Utility/Hashing.cs#L20-L130

If I understand the situation, and if possible, Could you please describe how the release accommodates the .6.ftexs extension? Thank you!

Atvaark commented 4 years ago

If I remember correctly, these file extensions and their "TypeId" were dumped from the initial Ground Zeroes PC release. Since there is no known "TypeId" for .6.ftexs files it isn't supported for in v0.2.0.

Perhaps there was a new release of Ground Zeroes with .6.ftexs support? You could try creating a .ftex files with <6 .ftexs files.

folly-ah-duh commented 4 years ago

So I checked a couple of things:

Like you said, I see no references to .6.ftexs in the GZ executable, but 1 - 5 are there
I'm getting a number of .6.ftexs for various textures when I unpack data_01.g0s using your v0.2 release. I don't think I'm doing anything special that would cause .6.ftexs to unpack. Perhaps there's something wrong with my .g0s, and it needs to be revalidated? I'll try that when I get the chance, but my internet is rather slow. I'll update with more info soon.
I haven't tried yet, but I'll also compile 0.2's source code and spot any differences with the output

To clarify, my current goal is to reintegrate .g0s support into a later version of the project. It's a kludge right now- I'm copying the v0.2 dataflow and that's how I found myself with this problem.

folly-ah-duh commented 4 years ago

Ah I think I see what's happening now. The source code / release .exe parity is fine, it seems that the .6.ftexs files need to be explicitly listed in the gzs_dictionary.txt in order for the tool to unpack them properly. So for example:

/Assets/tpp/ui/texture/map/gntn_photo_alp_clp
/Assets/tpp/ui/texture/map/gntn_photo_clp
/Assets/tpp/ui/texture/map/gntn_photo_clp.6.ftexs
/Assets/tpp/ui/texture/map/gntn_photo_clp_nmp
/Assets/tpp/ui/texture/map/map_afgh/afgh_height_b_clp_alp

It's an odd quirk, but it is what it is. Sorry for the confusion, I should've noticed this earlier. Since the mystery's been solved, we can close this issue out. It'd probably be more trouble than its worth to embed some sort of .6.ftexs-checking logic into an executable.