.bin format NFSMW 2005

[V12-POWER]

Yet another format, this isn't the geometry or textures bin but the game data bin/database.
The file isn't compressed, data can be modified with the file as-is and have results in game.
It has 2 big parts, the .bin and the .vlt

The .bin has 2 parts
1)"ErtS" with the plain text strings used in the database, it has a field which is size and offset at the same time, being the size, total.
2) Data. The values for game classes/nodes/rows are stored here, following the sequence of the text strings. Here are also some hashes (hash algorithm http://pastebin.com/KPfHFBwT)

However we can't know for sure how everything is tied and organized because there's no offsets for the data and the "ErtS" sub parts, they don't tie, they're in another section.

the .vlt part

1)"NpeD" it has the size right after, then a field with a value of 2, right after 2 fields that look like it's a hash, a blank field, a length/size value, 2 text strings, their "names" are the file name itself, 2 times. (db.vlt and db.bin respectively) Which their length is given in the aforementioned field. (It counts the zeroes at the end)

2)"NrtS" has the size after, and nothing else, just blank

3)"NtaD" has size after. It is the part that builds respective nodes/parents nodes, tells the game to replace rows (such as when you engine-upgrade a car, it replaces the default collection) defines classes, functions, etc. But it's all hash functions, there's no text. I could prove this thanks to VLTedit tool by arushan.

4)"NpxE" size right after, then a value tells us how many separate entries exist in the above sub part, then it defines each entry for the "NtaD" part.
Each definition for the entries has 2 hashes at the start, one is (guessing) the entry hash and the second is related to whether the entry has additional data for the .bin sub part or if it defines or gives properties of a node/class/row. This part has length in bytes for each entry, and the starting offset.

5)"NrtP" size after it and a field that indicates when the data starts, in fields length again. Basically here is where each text string of the "ErtS" section gets tied to it's respective data in the .bin and the "NtaD" sub part. Generally the format for defining it is:
*string starting offet* *definition length in fields* *.bin data offset*

When the format is like that, the middle field has a value of 3 always. Sometimes when this "ties" big nodes it has a long section before going onto the next string, the format is repeated, but it's obvious to see when the next string starts, because the starting offset gives it away.

Sometimes, the middle field has a value of 01 00 00 00 in contrary to 03 00 01 00, this means that it's a value of a bigger node, happens on bigger databse archives. Another characteristic is that the data starts from the last "ErtS" string offset and ends in the first string.
There is also a second part which points the string offsets to their respective NtaD entries. Mixed within that part is another "NtaD" entry offset to .bin data offset. It is easy to notice because one starts with the ErtS string offset (which are mostly odd offsets) and the other starts with a "NtaD" entry offset to the .bin data offset. This last example can have variations too, in the file I looked at, it had twice the amount of offsets/relations than for the "ErtS" strings, when organizing them together, they formed 40 byte long parts inside the "NtaD" strings.

I have included the files below. Can I get a hand doing a quickbms script for use with larger files?
Being tired of these read/write tools, I would like to be able to modify the database entirely, but first, get to organize.

[Aidan729]

Is this .bin for PC ? I've never heard of a binary file for a game(mostly console) not being compressed or encrypted.

[V12-POWER]

Is this .bin for PC ? I've never heard of a binary file for a game(mostly console) not being compressed or encrypted.

some .bin are geometry adn textures, this is a database file. THe .bin format has no restriction, it can contain info of any kind

[Aidan729]

Yes I'm aware of that I just find it odd that it isn't compressed that's all.

[V12-POWER]

yea me too lol. I find it odd that them being database files have not being cracked to being expanded.

[beedy]

Yet another format, this isn't the geometry or textures bin but the game data bin/database.
The file isn't compressed, data can be modified with the file as-is and have results in game.
It has 2 big parts, the .bin and the .vlt ...

Does anyone have a .vlt file which can be opened in VLTedit by Arushan? There is a another program called NFS-VltEd by nfsu360 but it requires fully installed NFS game to read files. I tried epic_pursuit.vlt in attached BIN folder but vltedit gives error. I also tried vlt’s from X360 NHL games but gives error too. Does anyone know is it possible to read .vlt files from NHL in any program?
X360 files looks very similar but different endianness: NpeD is DepN, NrtS is StrN and NtaD is DatN.