Ok some stuff about DAT files and my tool.
-AFAIK, all chunk IDs should show up in the chunk list, but maybe some models have chunk types that I didn't decode, the tree is just to see the 3d part hierarchy.
-I'd try cloning starting with a simpler model: Headgear (helmets, caps). A nice project: a separate white officers' cap to have one officer pose as kaleun.
-I have received some requests for the source code of my tool. I don't particularly like releasing it, because it is extremely crappy, just a testbed while I was decoding the file, quick, dirty, ugly... you name it. On top of that it's C#, and I was learning the language as I was typing. All said... here you are, a full copy of my VS project, the meaty bits are in Form1.cs...
Consider it all public domain.
http://cursos.usal.es/~felipe/dc/datconvertsrc.zip
-About moving ship parts: this is quite easy, just locate the desired chunk using my tool, hex edit the x,y,z coordinates, and you're set (look at type 4 chunks in the notes below).
-Finally, here are the notes I took about the file format, they are not complete, but can help anyone who whishes to keep at it:
Code:
SH III DAT FILE FORMAT
Skip the first 20 bytes they seem to be always the same.
Next 4 bytes are a long with the header string lenght.
Next is the author name and the "using Kashmir" stuff, total lenght as read above.
Next, file is made of "chunks". All chunks are like this:
ChunkType 4 bytes
Chunk Subtype/Version 4 bytes
chunk_size long (4 bytes)
Data (chunk_size bytes)
Chunk types and internal structure of each one:
type 0: EMPTY chunk
it's just 12 "00" bytes, so type, subtype and size are 0
type 1: 3D chunk
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this part inside the file. References usually found inside NODE (type 4) chunks
???????: 1 byte //don't know about this one
nverts: 4 byte long //number of vertices
vertex data: nverts * 3 floats// these are vertices, 3 floats per vertex
ntri: 4 byte long //number of triangles;
triangle data: there are ntri triangles and their texture mapping, each one is as follows
vertex1: unsigned 2-byte int
vertex2: unsigned 2-byte int
vertex3: unsigned 2-byte int
texture coord1: unsigned 2-byte int
texture coord2: unsigned 2-byte int
texture coord3: unsigned 2-byte int
????????????: one byte
ntxcoords: 4 byte long //number of texture coordinates
texture coords data: ntxcoords * 2 floats // texture coordinates are 2D
some objects end here, but some have "TMAP" and a bunch of floats after this, dunno what is that yet so I skip it
type 2: TEXTURE REFERENCE?
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this part inside the file. References usually found inside NODE (type 4) chunks
then a bunch of bytes that I haven't figured yet, usually ending with a texture filename.
type 3: TGA FILE
these are the TGA files, just packed after the type, subtype and chunk size.
type 4: NODE (these tell us how parts are related to each other, in a tree-like hierarchy)
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this node inside the file. References usually found inside NODE (type 4) chunks
parent_id: 8 bytes //reference to the "parent" node. root nodes have 00 00 00 00 00 00 00 00 as parent
3dpart_id: 8 bytes //reference to the 3d part managed by this node, 00 00 00 00 00 00 00 00 if this is a "dummy" node with no visible 3d part
????????: 1 byte, seems to be always 00.
????????: 1 byte, seems to be related to the number of different type 2 nodes referenced from this one.
x offset: 4 bytes float //x offset from parent node
y offset: 4 bytes float //y offset from parent node
z offset: 4 bytes float //z offset from parent node
then comes the type 2 chunk references and some stuff I don't yet understand
type 6: DATA?
these are children of type 10 chunks, they seem to hold effects, commands, interactions, etc...
first 8 bytes are the reference to the type 10 parent. rest is strings and numerical values.
type 8: LABEL
these are used to label other nodes
format is:
8 byte parent chunk reference
string with label
type 10: DATA?
these seem to group type 6 chunks and attach them to type 4 nodes
first 8 bytes: id of this chunk
second 8 bytes: id of parent node
then comes some data, usually strings and numbers.
type 102: SCALE?
these come usually near the end of the files, they are a bunch of floats, probably some global scaling, have to test it
type 1001: INDEX
this one seems to be an index, there are chunk ID's and the corresponding file postition, might have to update this if some chunk has its size altered, but some tries suggest this doesnñr affect loading.
There are more chunk types, haven't had time to check them