This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=2970

AnonBaiter, posted Tue Aug 23, 2016 5:14 am (16774)

---

Here are the samples from the PS2 and PSP version.

This thread will probably get edited when I find the other versions.

aluigi, posted Tue Aug 23, 2016 11:02 am (16784)

---

http://aluigi.org/bms/tomb_raider_legend.bms

If you are going to ask what are these "!WAR" files, I don't know. Probably containers of some data or textures or I don't know

AnonBaiter, posted Tue Aug 23, 2016 2:01 pm (16793)

---

They seem to be containers to me.
Besides, I've found these file containers around somewhere:

Code:

.mus
.sam
.mul
.drm
.bak

Maybe these will be of any use in organizing the extracted directories...

aluigi, posted Tue Aug 23, 2016 4:37 pm (16803)

---

I confirm that !WAR is just a graphic file format of this game with the raw graphics data starting at offset 0x80.

AnonBaiter, posted Tue Aug 23, 2016 9:07 pm (16811)

---

Anyhow...
Here are the samples from the XBOX version of the game.

If you wish, I can send you more files to analyze. And considering that one of these files include a multiplexed audio file...

aluigi, posted Wed Aug 24, 2016 11:34 am (16822)

---

merge them in one big file and give it to the script.

AnonBaiter, posted Wed Aug 24, 2016 1:56 pm (16830)

---

...and done.

EDIT: Well...

Code:

  0000000096d2c000 8257172    000000000000000b.dat

Error: incomplete input file 0: E:\TRL\XBOX\layer1.dat
       Can't read 64 bytes from offset 0000000096d2c000.
       Anyway don't worry, it's possible that the BMS script has been written
       to exit in this way if it's reached the end of the archive so check it
       or contact its author or verify that all the files have been extracted.
       Please check the following coverage information to know if it's ok.

  coverage file 0     0%   1353748    2513629184

Last script line before the error or that produced the error:
  17  log "" OFFSET SIZE

How about you make the script load the following extensions(000, 001 and so forth) or heck, even make it compartible with the deus_ex_human_revolution.bms script or...

aluigi, posted Wed Aug 24, 2016 4:28 pm (16836)

---

The format of deus_ex_human_revolution.bms had fields specifying the number of archives while this is not the case here.
The reported maximum size of the data is 0x9857a432 bytes (which the sum of all the archives is 0x95d2f000) with the first file at offset 0x30800 which is correct.
The script is correct and it does exactly what's reported in the TOC.

AnonBaiter, posted Wed Aug 24, 2016 8:37 pm (16851)

---

Which means that the error I'm getting is... okay?
Or maybe I'm wrong?

aluigi, posted Wed Aug 24, 2016 8:39 pm (16852)

---

Yes, you are right. The information say that there are files located outside the available data.
What I can do is putting an "if" statement in the script that automatically skips these wrong files if they are not available in the archive.
Does that sound good?

AnonBaiter, posted Wed Aug 24, 2016 8:40 pm (16853)

---

Give it a shot, then.

aluigi, posted Wed Aug 24, 2016 8:47 pm (16855)

---

ok 0.1.1

AnonBaiter, posted Wed Aug 24, 2016 8:49 pm (16856)

---

Okay, it works now.

AnonBaiter, posted Thu Aug 25, 2016 5:51 pm (16879)

---

I also tested the script with the PC version, and although it did manage to extract all the files, there are times in which the file starts right in the middle of another file. See here:

Code:

000017B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000017C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000017D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000017E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000017F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00001800  E6 7D 00 00 FF FF FF FF 00 3C 00 00 01 00 00 00  ?}..yyyy.<......
00001810  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00001820  00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
00001830  00 00 00 00 00 00 60 41 00 00 80 3F 00 00 00 00  ......`A..??....
00001840  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00001850  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00001860  00 00 00 00 00 00 00 00 00 00 80 3F 00 00 00 00  ..........??....

Anyway, here's the sample from the concatenated bigfile.dat file.

Ekey, posted Fri Aug 26, 2016 11:53 pm (16920)

---

http://svn.gib.me/builds/crystaldynamic ... aider7a8d/

AnonBaiter, posted Sat Aug 27, 2016 12:02 am (16921)

---

Ooh, thanks.

AnonBaiter, posted Sat Aug 27, 2016 2:26 pm (16930)

---

Here's a sample from the Gamecube version of the same game. The header is different on this one.

aluigi, posted Sat Aug 27, 2016 5:05 pm (16934)

---

Just different endianess, script 0.1.2

AnonBaiter, posted Sat Aug 27, 2016 7:17 pm (16937)

---

...and done. Thanks mate.

aluigi, posted Sat Aug 27, 2016 9:44 pm (16941)

---

Are you 100% sure that your samples from the xbox version are correct?
Because their size is without doubts wrong:
*edit* fixed in the next post.

AnonBaiter, posted Sat Aug 27, 2016 9:47 pm (16942)

---

Perhaps I shouldn't have sticked with the option of having to concatenate the files into one the first place...

aluigi, posted Sat Aug 27, 2016 10:49 pm (16943)

---

My mistake on the previous calculation, the correct offset size was 0x09433000 1147008 which is 0x954b080 which is the exact size of layer1.000, BUT the next offset (used by layer1.001) is 0x09000000 and not 0x954b080.
I think I can instruct the script to work on this mess, stay update.

aluigi, posted Sat Aug 27, 2016 11:12 pm (16944)

---

Script 0.2
Use it on layer1.000 and it will do everything by itself.

AnonBaiter, posted Sun Aug 28, 2016 2:39 am (16949)

---

The script is a lot better now! Thanks mate.