World of Tanks Map format.

[SkaceKachna]

BWSG Progress!
After the string table in BWSG, there is another table, that has the same start

entry_size uint32 (in my case 20)
entry_count uint32 (in my case 19 - 2 less than previous table)
unknown, uint32?

a the end of each entry in this table, there is weird uint32 ... which matches the uknown number in the string table!
This is how the table looks inside hangar_v2 .bin file .... I split each entry into 4 uint32, last being the cryptic value, which is probably some kind of ident?
The string at the end is string from first table which has matching unknown value....

Code: Select all

 Unknown |Unknown |Unknown |Unknown |  Key   | String
00000000,00000001,0000007E,38680637,6E8602DF particles/mesh_particles/lights/Hangar_v2_lights/hangar_v2_uplights.primitives/vertices
00000001,00000002,00000024,38680637,47C44BA1 xyznuvtb
00000002,00000003,0000001D,38680637,CAEEF31E content/Environment/hangar_v2/group/normal/lod0/group5.primitives/vertices
00000003,00000004,0000001A,38680637,8CC42139 content/Environment/hangar_v2/group/normal/lod0/group2.primitives/vertices
00000004,00000005,00000008,38680637,64E2E7A5 content/Environment/hangar_v2/group/normal/lod0/group6.primitives/vertices
00000005,00000006,00000028,EC1E4741,FFA9D14C xyznuv
00000006,00000008,00000014,EC1E4741,8BBE133F content/Environment/env616_Background_trees/env616_Background_Trees_04.primitives/vertices
00000008,00000009,00000128,38680637,D7BB4F5C content/Environment/env616_Background_trees/env616_Background_Trees_03.primitives/vertices
00000009,0000000A,00000DF3,38680637,B4B63C62 content/Environment/hangar_v2/backgroung/normal/lod0/Background1.primitives/vertices
// NOTICE THE INDEX SKIPPED ONE HERE
0000000A,0000000C,00002E39,38680637,309D82D0 content/Environment/hangar_v2/group/normal/lod0/group4.primitives/vertices 
0000000C,0000000D,00000008,38680637,B94DA052 content/Environment/hangar_v2/hangar/normal/lod0/hangar_v2_part02.primitives/vertices
0000000D,0000000E,00001AB5,38680637,5A5DA05B content/Environment/hangar_v2/hangar/normal/lod0/hangar_shadow_part01.primitives/vertices
0000000E,0000000F,000008B5,38680637,49275C42 content/Environment/env616_Background_trees/env616_Background_Trees_02.primitives/vertices
0000000F,00000010,00000010,38680637,2F2AE981 content/Environment/env616_Background_trees/env616_Background_Trees_01.primitives/vertices
00000010,00000011,000019F9,38680637,E98D8899 content/Environment/hangar_v2/hangar/normal/lod0/envIN_007_hangar_v2_props_09_03.primitives/vertices
// NOTICE THE INDEX SKIPPED ONE HERE
00000011,00000013,000002E0,38680637,BD19F57E content/Environment/hangar_v2/group/normal/lod0/group1.primitives/vertices
00000013,00000014,00002527,38680637,4A26E0EF content/Environment/hangar_v2/hangar/normal/lod0/hangar_shadow_part02.primitives/vertices
// NOTICE THE INDEX SKIPPED ONE HERE
00000014,00000016,00000982,38680637,DB0C79B6 content/Environment/hangar_v2/group/normal/lod0/group3.primitives/vertices
00000016,00000017,0000013D,38680637,00000014 //FAILED TO FIND MATCH IN FIRST TABLE

Those strings from first table were left unmatched

Code: Select all

00000658 particles/mesh_particles/lights/Hangar_v2_lights/hangar_v2_godrays.primitives/vertices
38680637 content/Environment/hangar_v2/backgroung/normal/lod0/Background2.primitives/vertices
EC1E4741 content/Environment/hangar_v2/hangar/normal/lod0/Floor_part01.primitives/vertices

[Coffee]

Ok...
Looking at the strings in BWSG...
0270: Cryptic:ec1e4741 : content/MilitaryEnvironment/mle019_GerBoxes/normal/lod0/mle019_GerBoxes3.primitives/vertices
If I search further in BWSG I find this

[SkaceKachna]

Ok, I think I figured it out now:
BWSG
1. table -> Table of strings associated to keys
2. table -> Uses said strings to ??

1.table

Code: Select all

0  uint32 position in contents (from beginning of table end)
4  uint32 size of string
8  uint32 key

Example of contents:

Code: Select all

KEY     STRING
64E2E7A5 content/Environment/hangar_v2/group/normal/lod0/group6.primitives/vertices
00000658 particles/mesh_particles/lights/Hangar_v2_lights/hangar_v2_godrays.primitives/vertices
E98D8899 content/Environment/hangar_v2/hangar/normal/lod0/envIN_007_hangar_v2_props_09_03.primitives/vertices
FFA9D14C xyznuv
....

2. table

Code: Select all

0  uint32 some kind of index
4  uint32 some kind of index, bigger then first
8  uint32 uknown?
12  uint32 key refering to first table
16 uint32 key refering to first table

Example contents:

Code: Select all

Index1  | Index2 |Unknown | Index1 | Index2 
00000000,00000001,0000007E,38680637,6E8602DF
00000001,00000002,00000024,38680637,47C44BA1
00000002,00000003,0000001D,38680637,CAEEF31E
....

can be then converted to:

Code: Select all

key1 content/Environment/hangar_v2/backgroung/normal/lod0/Background2.primitives/vertices
key2 particles/mesh_particles/lights/Hangar_v2_lights/hangar_v2_uplights.primitives/vertices

key1 content/Environment/hangar_v2/backgroung/normal/lod0/Background2.primitives/vertices
key2 xyznuvtb

key1 content/Environment/hangar_v2/backgroung/normal/lod0/Background2.primitives/vertices
key2 content/Environment/hangar_v2/group/normal/lod0/group5.primitives/vertices

I'm smelling something similiar to packed XMLs

[Coffee]

Nice work..

Notice my posted image how the highest index = 01B2 (B2010000) in that table...
Now.. Look at the total length of the next table.
Each data length is 0x14 long and the total entries are 01b2!

[SkaceKachna]

I think there is something wrong with my code .... I'm 100 % sure those two keys should be
xyznuv content/Environment/hangar_v2/group/normal/lod0/group6.primitives/vertices
or
xyznuvb content/Environment/hangar_v2/group/normal/lod0/group6.primitives/vertices

(vetrices type -> vertices name) ... key1 is repetetive (2 values in file I'm scanning), key2 is changing every line

[Coffee]

XYZNUVTB and like items describe what type of vertex it is.
there are at least 3 used on the map

[Coffee]

I have more info on what I have found in the BWSG section.
The last table in the BWSG (for enks) has 9 entries of 4 bytes in lenght.
Each int32 is the length of the next section. They are LONG sections of data.
I added all these together and it does indeed = the total length of the remainder of the file.

[SkaceKachna]

Yes. I'm suspecting the table format is wrong.
It should be
TABLE

Code: Select all

0 uint32 entry_size
4 uint32 entry_count

then each entry

Code: Select all

0 uint32 key
4 uint32 position
8 uint32 size

[Coffee]

Example contents:

Code: Select all

Index1  | Index2 |Unknown | Index1 | Index2 
00000000,00000001,0000007E,38680637,6E8602DF
00000001,00000002,00000024,38680637,47C44BA1
00000002,00000003,0000001D,38680637,CAEEF31E
....

You are off by the first column here.
The first column is right after the entry count.

[SkaceKachna]

OK BWSG file so far:
1. TABLE

Code: Select all

0 uint32 entry_size
4 uint32 entry_count

then you read each entry as follows

Code: Select all

i + 0  uint32 key
i + 4  uint32 position
i + 8  uint32 size

Then you can read size of strings table:

Code: Select all

8 + entry_count * entry_size uint32 size of strings

You can then use read string for each entry, where position is relative to

Code: Select all

8 + entry_count * entry_size + 4

2. TABLE
Begins right when 1. table ends (position: 8 + entry_count * entry_size + size_of_strings + 4)

Code: Select all

0 uint32 entry_size
4 uint32 entry_count

then you read each entry as follows

Code: Select all

i + 0  uint32 key1 (vertices name)
i + 4  uint32 unknown
i + 8  uint32 unknown
i + 12 uint32 uknown
i + 16 uint32 key2 (vertices type)

There is hoewer bit of data with unknown contents after this, which should contain positions of vertices in file

[SkaceKachna]

You are off by the first column here.
The first column is right after the entry count.

Yes, you're right, I was off by one column in both tables. My new description should be correct thought...
Also, you were correct about last table, there is definetly 3.TABLE. Contents are unknown toughgt:

Code: Select all

00000000,00000020,00000FC0,00000000,00000000
00000000,00000020,00000480,00000000,00000FC0
00000000,00000020,000003A0,00000000,00001440
00000000,00000020,00000340,00000000,000017E0
00000000,00000020,00000100,00000000,00001B20
00000000,00000018,000003C0,00000000,00001C20
00000000,00000018,000001E0,00000000,00001FE0
0000000A,00000008,000000A0,00000000,000021C0
00000000,00000020,00002500,00000000,00002260
00000000,00000020,0001BE60,00000000,00004760
00000000,00000020,0005C720,00000000,000205C0
0000000A,00000008,000171C8,00000000,0007CCE0
00000000,00000020,00000100,00000000,00093EB0
00000000,00000020,000356A0,00000000,00093FB0
00000000,00000020,000116A0,00000000,000C9650
00000000,00000020,00000200,00000000,000DACF0
00000000,00000020,00033F20,00000000,000DAEF0
00000000,00000020,00005C00,00000000,0010EE10
0000000A,00000008,00001700,00000000,00114A10
00000000,00000020,0004A4E0,00000000,00116110
00000000,00000020,00013040,00000000,001605F0
0000000A,00000008,00004C10,00000000,00173630
00000000,00000020,000027A0,00000000,00178240

[SkaceKachna]

Here's script that extract all informations currently known by me:
http://cerno.ch/~kamen/upload/test-bswg.py

3. TABLE -> purpose uknown
4. TABLE -> one item, length of rest of the file

We now have entire BWSG file covered!

[Coffee]

The very last part of the BWSG is where most of the data is stored.
For ensk, it has 9 sections each rather large.
Im guessing that some of these unknown uint32s point in to these chunks
Seeing how there are 9 chunks.. we need find where this index is and that none of the other indexes are larger than one of these chunks.

Code: Select all

04000000 : Entry Size..
09000000 : COUNT followed by each sections size (and they are large!)
E0FF3F00
B0FD3F00
D0FA3F00
E0FC3F00
50FB3F00
60FD3F00
40FC3F00
70FE3F00
20281000

As I said before.. I added all these together and it equals the length of the rest of the file.
If some of those unit32s are indexing in to this, there should be a length of the data as well.

[SkaceKachna]

3. TABLE item

Code: Select all

12 uint32 item in 4.table
16 uint32 position relative to item in 4.table

4. TABLE contains only single entry in hangar_v2.bin which is pointer to start of the vertices data
In larger maps, 4. Table actually has (as you said) more entries pointing to various parts of file...

EDIT: YES! Uint32 at 12 is actually index (counting index, no key or something) in 4. TABLE

[Coffee]

This look right?
This is table 3.