Guild Wars .DAT File

[BlackDragon]

I started working on this again and have made some progress. I hope to have some specs/file formats for the various ffna types soon.

BD

[BoyC]

Nice to know you're still at it! I'm too swamped in work to look into this again... maybe after the first gw2 beta

[Irina]

Great to see you're still working on it If you find out how to decode the files (and if I have time) I'd love to add it to the GWDatBrowser .

[BlackDragon]

You know...It's funny. There haven't been many updates to GW in a while now, but the minute I start working on this again, we get updates out the whazoo, thus destroying all my breakpoints and scrambling all the adresses

Hey Anet, if you read this, just give us the file formats already!

BD

[saracen]

I started working on this again and have made some progress. I hope to have some specs/file formats for the various ffna types soon.

BD

Hopefully, like me, you found that the ffna does just contain different files, it's an archive in itself. Or at the very least, has different sections.

In fact, I may have already mentioned that here - but I can't be bothered to read back on everything

Anyway, I can't remember the exact format, but it was something like this:

Code: Select all

Entry Header:
  4 bytes - Unknown.
  unsigned int - Length
  unsigned int - Position

I believe the entries were linear. for example:

Read "FFNA" and 1 character (indicates the FFNA type), then read in an Entry Header. After you've jumped to it's position and read it's length - your file pointer should already be at the next entry. So just keep reading.

[BlackDragon]

Yeah, I found that out already. Some of the data is also doubly-processed: Not only is it compressed, but even after you uncompress it it STILL needs processing done on it to make it useful.

The first ffna file read in is type 4, which seems to have to do with the MOTD. It goes through a lot of processing before it is even useable. The type of 2 (with a subtype) are the model files, type 3 are map files and there are other misc. types.

Anyway, after the type-4 file is loded in and decompressed they run it through ANOTHER decompression routine to build what I think is a lookup table for text; might not be, might just be text itself but I think it is a dictionary. You can actually clear out that entire file, leaving only the headers, and all that will be missing is the MOTD

Because Anet seems to use custom formats for everything it makes it take a little longer but we'll get there soon, as long as real-life doesn't intrude too much

BD

[saracen]

From a networking point of view, the MOTD is handled differently, in that I think it's the only compressed data sent from the login server rather than the file server.

When I captured it while it streamed in (I never found it in the DAT) it wasn't compressed multiple times, however it does obviously require a parser. I believe it was a XML derived format - it also sends ALL languages (or atleast it used to) - So make sure you don't comfuse the unicode as binary data for compression or whatever.

They do have a commonly used string table I believe and you'll probably come across arguments in strings where they're supposed to be. For example: "Hello %str%", where %str% would then get replaced with some common string they have saved (or even your current characters name). Sort of like printf.

[BlackDragon]

I think I posted this before so forgive me if I did, but I don't remember...Darn old age (

Anyway, what debuggers are you guys using? I use OllyDBG and it seems to have trouble with locking-up when GW threads something out and this is starting to irritate me.

Anyone have any other recommendations?

BD

[BlackDragon]

OK. Been doing more work on this and I'm actually beginning to figure out the ffna file format, although it is rather complicated.

Here's what I know:

Each ffna stores data in chunks. The header for the ffna goes like this:

4 bytes spelling out ffna.

One byte that tells the type (02 is a model file).

Then 4 bytes that contain the chunk type, then 4 bytes that contain the chunk size.

The first model file loaded in is hash 0x497cf (from GwDatBrowser). I'm assuming this has to do with the opening scene.

The mdlLoad.cpp (ModelLoad.cpp) section of the gw code starts looking at the ffna by chunk types, and breaks down the data into separate arrays.

It first looks for chunk type 0x0fa6. There is one in the file that is size of 0x0a, and contains the bytes "0x01049ccd".

Then it looks for type 0x0fA8 and 0x0fAe, neither of which exist.

Then it looks for 0x0fA1, which seems to be a major type because it goes into lots of processing as it seems this type has several subheaders in it. I'm not going into the pseudocode yet.

Anyway, you can read in all the chunks and start looking at the data this way. There is some text in there, about y.spec and perturb and such.

We are getting closer. Soon I'll have the types actually figured out (whether they are meshes or whatnot). I'd think there would be texture lookups in there too. I'll keep you posted.

BD

[mqstout]

I'm still wondering if bribery would help keep those gears grinding?

[BlackDragon]

I've been busy playing "Wrath of the Lich King" and "LOTRO:Mines of Moria" and "Warhammer Online"

When I get max level in those, I'll be back to this project

BD

[RavynousHunter]

Not sure if this is useful or not, but Guild Wars Wiki has an entry on the GW.dat file format.

[Dinoguy1000]

It seems to be largely a edited copy of our own wiki page, judging by the discussion on its talk page.

[Mr.Mouse]

Nice find, Dinoguy!!!!! I'm glad to see he now credits our work on the format. Thanks for sticking up for us, pal

[Dinoguy1000]

Yep, no problem.