Closed jchoi071 closed 3 years ago
The extra data exists after the offset list (highlighted.) Setting the extra size field (at offset 18h) to zero will make gust_g1t process the files, however repacking will strip these bytes since they are skipped.
The solution is quite easy, just read extra_size
bytes after the offset list (header size + surface count * 4
), store it in the json as base64 encoded text or a hex byte string.
Thanks for the report. It looks like the extra section is for structures that have an extra flag applied into what I thought was an unused
byte but which seems to be an extension of the rest of the texture flags.
The reason I am deducing this is because I can count 5 textures with the extra bit set, and we have exactly 5x12 repeating bytes in the global extra data.
I have therefore updated gust_g1t
to take into account these findings, and I have confirmed that it should be able to unpack and repack the file you attached exactly. Now of course, if you do modify the texture to which the extra global data applies, I make no promise that the repacked .g1t
will work, since we still have no clue what this extra global data is meant to be used for, in relation to the texture.
gust_g1t can't extract the g1t files from this game; then again, it literally just came out a few days ago. The error that comes up is "ERROR: Can't handle G1T files with extra content". The Project G1M plugin for Noesis can extract the files perfectly fine, though it doesn't have a way to repack the result into a g1t file.
I've attached a g1t from this game if you need it.