You're right, it's table index and offset. I just cracked entire bswg file and extracted the vertices parts from it.
Just give me some time to write script and description how it works.
There are still some unfigured data, but finally, entire file is described!
Sorry I wasn't answering your questions, but I'm just so excited I finally found something! Also I was deep inside the code.
I know they have converted a lot of string numbers in to actual real floats in the data.. Like matrices.
We will need to be able to associate the correct matrix with each models vertices and indices.
Also.. almost all buildings on the maps contains 2 sets of UVs and 3 textures...
Some have 4 textures if they are also using the PBS shaders.
I'd love to change the world but I can't get my hands on the code.
Note that table structure is reocurring theme,
BWST is only table of key -> string
BWMO contains only tables in this format (with some references to BWST - BW strings?)
Basically everything we sorted out yesterday.
Id recommend you bracket "( )" the math. I have seen strange things happen in different compilers.
I can help a lot with the cdata files and also how the ctree data works.
For now Lets figure out how to reassemble the data for the models.
I know that the SpTr file contains matrices, each followed by its key and than 2 unt32s both always equaling 1.
At the end of this file there is some extra data. Some of these are floats and on ensk.. match the 1/2 width of the map. This could be a coincidence. There is what appears to be a key in there. One thing I said before is all the trees will use the same shader and flag settings.
ONLY BWSG contains the speedtree paths. Consider SpTr hacked!
There is something I noticed about BWSG.
Almost every entry ends with "/vertices"
Where, BWST contains all kinds of names including .dds texture names.
Also.. BWST has no other tables than the index and the strings.
You can find the keys in BWST's index table in BWSG's 2nd table.
This in turn points in the the large chunks at the end.
I have a feeling (not tested) that these large chunks are a list of keys from
both the BWST and BSMI or some other matrix file. BMSI contains 4585 matrices.
There is no matching keys in the BSMI (matrix file) for entries in BWST.
They must come from some where else.
Also,
there are duplicate names in BWST. I WAS WRONG.. THERE DOES NOT APPEAR TO BE DUPLICATE NAMES IN BWSG
There has to be a matrix for every model on the map so
this makes since.
The mission as I see it is to find where all the keys are to put the names in groups that are in BWST.
I believe BWST contains the data for creating the .visual needed for each model. It contains many more strings than BWSG.
Last edited by Coffee on Fri Jan 22, 2016 5:39 pm, edited 1 time in total.
I'd love to change the world but I can't get my hands on the code.
Yes, so far keys from BWST are used in:
WGSD ((multiple times, always pointing to strings that ends with .dds)
BSMO (multiple times, always pointing to strings that ends with .primitive)
- both consists only of tables (same format as other)
Here are all the keys for gaf010_FenceTile2.primitives I can find using the .visual as reference
There are 312 found keys matching 37066838 in BWSG
BWSG:
37066838 gaf010_FenceTile2.primitives/vertices
1FEFB938 xyznuvtb
Lot of fence tile sections..
There are indeed 311 entries in table 2 for these models for the ENSK map.
In order to place the models on the map I need at least the transform matrix data for each model.
If the models are in the sandbox, I can get everything else from there.
I'd love to change the world but I can't get my hands on the code.
I won't be able to progress next few days, need to study. Just note almost every chunk has the more ENTRY_SIZE and ENTRY_COUNT structures with some entries pointing to BWST...
)![[roll]](./images/smilies/icon_rolleyes.gif "rolleyes"){kind=icon}