World of Tanks Map format.

[SkaceKachna]

Cracked WGSD:
http://wiki.vbaddict.net/pages/WGSD

all important info is now known about those decals? There is a lot of uknown data, but you have matrix (=position,rotation,scale) and paths to textures, what more would you need?

Im starting to think they are XOR'ing some of the data.
I know for a fact they are doing this with some data in the .primitives_processed model files.

That would be hard to discover. Maybe the indicies are XORed in some way? And textures? I was unable to match either indicies or textures inside bin file. They have to be there, how else would you be able to construct the models?

[Coffee]

I found out something..

in BWSG the last Uint32 before the actual strings is the length of the total string section.
This is the same for BWST as well..
So the 3rd entry at the start is the Key.

[SkaceKachna]

Yes, that's all described inside the wiki I linked...

( http://wiki.vbaddict.net/pages/BWSG )

Also progress: BSMO contains primitives and their groups and materials for each group. Trying to link this all together now, it should yield the models...

[SkaceKachna]

I have big part of BSMO decrypted! It contains same data as .visual files, but in binary form.
Some things are still unsorted, will publish when everything will be known.

[Coffee]

Good job..
I understand must of the sections formats as well... That is.. as far as how things are stored..
The thing is, It doesn't mean anything if I cant figure out how to use the data.

It would be nice to load everything using the space.bin. It would for sure be faster than loading the model and its visual from the .pkg files.
I have been writing code to break up the BWSG.
It is by far the largest section in the data.
I'm going to dump each sub chunk in to its own file so I can try to figure out what these are and how to get anything useful from them.

[SkaceKachna]

BWSG contains vertices and maybe even indicies. That's all, if you try to run script provided with python, you should be able to extract its contents. I'm 100% sure about this as I compared some files. Not sure about the indicies part.

BSMO actually links everything together ... I'm about 68% sure

[Coffee]

I dumped all the end parts of the BWSG in to its own file.
I uploaded this to http://209.159.152.184:8080/junk/BWSG_DUMP.zip

I see no indices, vertices or any floats in these sections.
At least look at it and see if these match the chunks you get from your script.
The format of the file names is chunk_n1_n2.
n1 = the section 0 to 8 and n2 is just the running index.

[Coffee]

Cracked WGSD:
http://wiki.vbaddict.net/pages/WGSD

all important info is now known about those decals? There is a lot of uknown data, but you have matrix (=position,rotation,scale) and paths to textures, what more would you need?

Im starting to think they are XOR'ing some of the data.
I know for a fact they are doing this with some data in the .primitives_processed model files.

That would be hard to discover. Maybe the indicies are XORed in some way? And textures? I was unable to match either indicies or textures inside bin file. They have to be there, how else would you be able to construct the models?

I have never used the decals .. I could never figure out how to apply them to the texture.
I pretty sure they use a shader that does the blend along with the transforming.
It would be cool to add them though.

[SkaceKachna]

Ok, for example:
Chunk_08_0430
This is chunk assigned to (you can find how in the description of BWSG...):
content/Buildings/bld_Constructor01/bld202_vhouse/normal/lod0/bld202_vhouse01.primitives/vertices

if you compare contents of this chunk with actual file (you can find it in shared_content.pkg):
content/Buildings/bld_Constructor01/bld202_vhouse/normal/lod0/bld202_vhouse01.primitives_processed

you will find that part of the file (probably the vertices part) does actually match the chunk.

(match starts at 0000 008C)

[Coffee]

I dumped all the end parts of the BWSG in to its own file.
I uploaded this to http://209.159.152.184:8080/junk/BWSG_DUMP.zip

I see no indices, vertices or any floats in these sections.
At least look at it and see if these match the chunks you get from your script.
The format of the file names is chunk_n1_n2.
n1 = the section 0 to 8 and n2 is just the running index.

The vertex counts for the models looks to be correct. The values look strange as floats in my hex editor.
This is good.. I can load the models directly from the space.bin once we figure out the rest.

[Coffee]

in this table for BWSG

P Type Desc
0 uint32 key 1 - vertices name (ends with .primitives/vertices usually)
4 uint32 block from - starting index of blocks containing data of this model
8 uint32 block to - ending index of blocks containing data of this model
12 uint32 unknown
16 uint32 key 2 - vertices type (xyznuvtb and such...)

the Unknown is the vertex count

Nice work.. Keep it up!

[SkaceKachna]

Good find! That was one of the last unknown values in that chunk.

[Coffee]

Ok.. I found more to finish up BWSG

each item then looks:

P Type Desc
0 uint32 unknown (probably describing block type?)
4 uint32 unknown (probably describing block type?)
8 uint32 block size
12 uint32 chunk index
16 uint32 offset inside chunk

The 2nd Uint32 is the stride of each vertex. Each vertex type has a different amount of data
so the distance from vertex to vertex in bytes changes depending on its type.
xyznuv has a stride of 0x18
xyznuvtb has a stride of 0x20

The first uint32 is 0x0a if the section is skipped. Other wise, its zero.
I believe these skipped areas contain the models 'crashed' state

[Coffee]

Ok my friend....
I found the missing entries for WGSD.

Code: Select all

P	Type	Desc
0	uint32	 ? - always 0 so far
4	16 * float32	decal matrix
20	uint32	key referencing BWST - diffuse map
24	uint32	key referencing BWST - normal map
28	uint32	key referencing BWST - ?
 ?	 ?	rest is unknwon, altrought it seems to be static

BTW.. I think your P offsets are incorrect in that table?

I got the structure from looking at a old .chunk file I still have.

Here is my structure for the data in the order it appears in the data.

Code: Select all

  Public Structure WGSD_entries_
        Public unknown_1 As UInt32
        Public matrix() As Single '16 floats
        Public diffuseMapKey As UInt32
        Public normalMapKey As UInt32
        Public u_key As UInt32
        Public unknown_2 As UInt32
        '
        Public Flags As UInt32
        '
        Public off_x As Single
        Public off_y As Single
        Public off_z As Single
        Public off_w As Single
        '
        Public uv_wrapping_u As Single
        Public uv_wrapping_v As Single
        Public visibilityMask As UInt32
        '---------------------------
        'The strings below is not in the data.
        Public diffuseMap As String
        Public normalMap As String
        Public extraMap As String
    End Structure

This does indeed pull the correct decal DDS files.
It how ever does not for the extreMap.. I think this might be a key to the grid this decal is on.
It would make sense as this has to be blended with the textures on a specific map grid.
BWT2 might need to be decoded next. I'm sure its the info on the map's grid layout.
EDIT: I can't find that 3rd u_key in the BWT2 data.. It's has to be some where else.

A Single is the same as a Float.. It occupies 4 bytes of data.

[Coffee]

OK.. SpTr works fine..
It was an error in my code..
It's pulling the correct trees for each key now.