This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=13148

Puterboy1, posted Mon Feb 10, 2020 4:57 pm (53908)

---

I would like to convert these into something viewable please, I think they may be texture/image files.

Allen, posted Fri Feb 14, 2020 9:15 am (54006)

---

Please try this noesis script.

Edit:
Updated.
Added texture type identification.

tex_StarWarsBountyHunter_gct.zip

Acewell, posted Fri Feb 14, 2020 10:46 pm (54016)

---

everything works fine in the smaller gct files but the base
offset variable breaks in the larger level gct file.
i think there is a padding calculation to be made.
sample here:
https://www.mediafire.com/file/pfu416c3 ... e.zip/file

Puterboy1, posted Sat Feb 15, 2020 12:11 am (54018)

---

Acewell wrote:

everything works fine in the smaller gct files but the base
offset variable breaks in the larger level gct file.
i think there is a padding calculation to be made.
sample here:
https://www.mediafire.com/file/pfu416c3 ... e.zip/file

Quite right. Not all of the texture files are perfectly presented. Some half one half of an image on the other side.

Acewell, posted Sat Feb 15, 2020 12:23 am (54019)

---

if you change line 24 from this:

Code:

baseOfs = bs.tell() 28

to this it works out for that larger sample:

Code:

baseOfs = bs.tell() 2876

it seems some padding calculation is needed only between the header table and data.

i'll see if i can find more larger samples to compare.

Puterboy1, posted Sat Feb 15, 2020 12:28 am (54020)

---

Acewell wrote:

if you change line 24 from this:

Code:

baseOfs = bs.tell() 28

to this it works out for that larger sample:

Code:

baseOfs = bs.tell() 2876

it seems some padding calculation is needed between the header table and data.

i'll see if i can find more larger samples to compare.

This is the image problem I am talking about.

Acewell, posted Sat Feb 15, 2020 12:42 am (54021)

---

Puterboy1 wrote:

This is the image problem I am talking about.

which file?

Puterboy1, posted Sat Feb 15, 2020 1:55 am (54022)

---

Acewell wrote:

Puterboy1 wrote:

This is the image problem I am talking about.

which file?

Did you not see the image I put up? It has two halves on the wrong side.

download/file.php?id=8013

Acewell, posted Sat Feb 15, 2020 3:02 am (54023)

---

Puterboy1 wrote:

Did you not see the image I put up? It has two halves on the wrong side.

and i asked you which file, as in file name. no one can do a thing with the image you posted.

edit
the problem you see was likely caused by the base offset
issue from the first script that i was already discussing with Allen.
you got to give him time to fix it before you go exporting any images.

Allen, posted Sat Feb 15, 2020 3:11 am (54024)

---

Acewell wrote:

everything works fine in the smaller gct files but the base
offset variable breaks in the larger level gct file.
i think there is a padding calculation to be made.
sample here:
https://www.mediafire.com/file/pfu416c3 ... e.zip/file

Acewell, thanks for correcting me!
I thought the file had at most 2 pictures. At present, no good padding calculation algorithm has been found, and only the "file size minus the header data size" can be used for calculation.

The script has been updated.

Acewell, posted Sat Feb 15, 2020 3:43 am (54026)

---

all is working good so far, thanks Allen!

Puterboy1, posted Sat Feb 15, 2020 7:34 pm (54043)

---

Acewell wrote:

all is working good so far, thanks Allen!

If you wanted the file with the imagery on the wrong side, here it is.

Acewell, posted Sun Feb 16, 2020 1:46 am (54047)

---

Puterboy1 wrote:

If you wanted the file with the imagery on the wrong side, here it is.

that image is correct, that is the way the data is stored.
there is likely another file telling the game engine how to handle it.

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

Puterboy1, posted Sun Feb 16, 2020 2:16 am (54049)

---

Acewell wrote:

Puterboy1 wrote:

If you wanted the file with the imagery on the wrong side, here it is.

that image is correct, that is the way the data is stored.
there is likely another file telling the game engine how to handle it.

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

I hope this means that images like the one I presented will be presented and exported correctly. Also, since either of you seem to have the game, have you checked the other files for anything interesting or a solution?

Allen, posted Sun Feb 16, 2020 7:06 am (54053)

---

Acewell wrote:

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

Thank you, I think you are right!
After analysis, are the following types correct? Actually I don't know much about the type of texture.
texType:
0=diffuse no alpha
0x2=specular alpha(black color)
0x4=Reflection
0x10=diffuse alpha(black color)
0x20=DXT1 alpha
0x80=atlas or duffuse no alpha
0x90=atlas or duffuse alpha(black color)

When equal to 0x80 or 0x90, I think if there is another type of suffix file with the same name, it is a textures atlas, otherwise it is a diffuse map.

Puterboy1 wrote:

I hope this means that images like the one I presented will be presented and exported correctly. Also, since either of you seem to have the game, have you checked the other files for anything interesting or a solution?

I don't have a game, I only have a sample from you.

Allen, posted Thu Feb 20, 2020 8:24 am (54111)

---

Acewell wrote:

Puterboy1 wrote:

If you wanted the file with the imagery on the wrong side, here it is.

that image is correct, that is the way the data is stored.
there is likely another file telling the game engine how to handle it.

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

I added a numeric type suffix to the file name to distinguish it.
People can modify it according to their own requirements.