The there is an HHA which is bigger than the other files in the folder (other than the Sounds folder) so It might be the stuff containing the character parts for the game
https://drive.google.com/file/d/171iCBn_qa0-JwuOTSD6KOsp4GqBv6Qul/view?usp=sharing

Please upload more than one sample (I'd recommend 3+) 
Edit: Just looked and the game does have another common.hha so I'll need that please

Edited April 11Apr 11 by NeoGT404

2 hours ago, Sirduckdude said:

The there is an HHA which is bigger than the other files in the folder (other than the Sounds folder) so It might be the stuff containing the character parts for the game
https://drive.google.com/file/d/171iCBn_qa0-JwuOTSD6KOsp4GqBv6Qul/view?usp=sharing

The file structure is very clear
uint32 magic;
uint16 padding;
uint16 version;
uint32 string_pool_size;
uint32 file_count;

char string_pool[string_pool_size];

struct FileEntry {
    uint32 folder_name_offset;
    uint32 file_name_offset;
    uint32 flags; // 0 = uncompressed, 1 = zlib (-15)
    uint32 data_offset;
    uint32 decompressed_size;
    uint32 compressed_size;
};

    file_data[];

I wrote a python script that can extract the data, it only requires file parameters, it looks like the texture is in .dds and the mesh is in .dts

hha.py

Edited April 11Apr 11 by wq223

Yeah I know, I already got that far as well but since my tool supports a lot of format and needs to detect them, how can you be sure the magic isn't just something like a hash? Also decompressing the .swf files might be undesirable if you want an untouched output (and it also doesn't decompress them if they're compressed with flag == 1 as well)

23 minutes ago, NeoGT404 said:

Yeah I know, I already got that far as well but since my tool supports a lot of format and needs to detect them, how can you be sure the magic isn't just something like a hash? Also decompressing the .swf files might be undesirable if you want an untouched output (and it also doesn't decompress them if they're compressed with flag == 1 as well)

It doesn't matter, you can also choose not to decompress. cws is a compression type header. After decompressing it, I restored it to fws. You don't need to do this step. In addition, it doesn't matter whether the main patch file header has a hash or a magic number, because it can be skipped directly during parsing. It is really not very friendly to your tool that needs to accurately detect the magic number.

1 hour ago, wq223 said:

The file structure is very clear
uint32 magic;
uint16 padding;
uint16 version;
uint32 string_pool_size;
uint32 file_count;

char string_pool[string_pool_size];

struct FileEntry {
    uint32 folder_name_offset;
    uint32 file_name_offset;
    uint32 flags; // 0 = uncompressed, 1 = zlib (-15)
    uint32 data_offset;
    uint32 decompressed_size;
    uint32 compressed_size;
};

    file_data[];

I wrote a python script that can extract the data, it only requires file parameters, it looks like the texture is in .dds and the mesh is in .dts

hha.py 3.24 kB · 1 download

Thank you!!!

i was able to get as far as sirduckdude, but i don't know how to convert the files to a format usable by other programs that arent torque3d (something like obj). that one dts converter plugin for blender, alongside shaper, throw up errors.

 

I'm not an expert on the 3D formats at all, but I can see there are 1-or-more vertex sections approximately like this :

// VERTICES
  4 - Unknown (1/3)
  4 - Number of Vertices
  
  // for each vertex
    4 - Point X (Float)
    4 - Point Y (Float)
    4 - Point Z (Float)
    
  4 - Number of UVs
  
  // for each UV
    4 - Texture U (Float)
    4 - Texture V (Float)

 

and down towards the end there seems to be a single block of face indices, simply as:

  4 - Number of Face Indexes
  
  // for each face Index
    2 - Point ID

 

eg, for the SPskull.dts:

 

There's a lot of other data before and between these sections though, can't currently determine how to accurately find these data blocks.

 

Over to the 3D experts now 🙂