Operation Flashpoint 2: Dragon Rising .000, .001, .002, etc.

[jbeckman]

It's a bit cumbersome but the -f flag should be usable to get specific files in the archive even if extracting the entire thing isn't possible.

Of course knowing all file names and file types will be a bit tricky, tried -f "*.xml" as a test (It's the only file format that's easily editable from what the -l list command gave, FSB music files seems to work as well based on the post a bit up about ripping music and sound.) and that wouldn't work at all so I had to use -f *a*.xml" from a - z and 0 - 9 to get all XML files unpacked.

Unsure how to get the game to actually read the data though but perhaps the \data\ or \data_win\ folder works for uncompressed files, there's a packed \system\ folder which is very similar to the \data\system\ folder though my edits of files like weather effects haven't given any results so perhaps it's not so easy.
(Editing textures, models, scripts and other data would be even harder due to all other file formats used.)

EDIT: Oh right -f *t*.xml tried to unpack a specific xml file that ended up freezing the program, nearly had to turn of the computer as it was about to crash so skip that letter.
(Might be a problem due to the size of the 000.full archive with all those 510 or so archives in the EU multi-language version or the QuickBMS version, did try 3.2 as well released three days ago but had the same problem, rather minor though, probably the first issue with file size.)

[Simon]

And it's impossible create one big file from 001 to 250, unpack this and then create another big file from 250 to end?

[jbeckman]

Interesting idea, might work actually, I accidentally forgot to delete the previous merged file when I ran the utility and it just added all the data onto it so moving half the files away and then merging both of them to separate files and then extracting them individually might be doable.

[Simon]

How to do it??

First

for i = 0 < 250

and then i = 250


?? (First Merge Script)

Edit:

The File is only 1.95 GB but same error on same file ?!

asset_map\2dmap.asset.xml

[Maddog]

Hi everyone, my first post,
Just to confirm same .xml file hangs on my mashine too.
Around 210 mb of data extracted only, exactly 3895 files in 119 folders.
Is it somehow possible to extract whole thing? Mine win_000.full is 4.269 MB in total.


Regards.

[aluigi]

in my opinion it's useless to continue to use the script I posted moreover because I have found other problems with it, for example the file locale\languagedata.xml which is also one of the first files to be extracted is corrupted.
so I highly suggest you to wait for a real extractor by someone else because, as I said, this one was only a blind work-around I wrote to help pietastesgood with his request about the music.

[Maddog]

Anyway thanks for your script at least it gave us a good start for experimenting with extraction. This title will be probably downed by codemaster dev team, unfortunately, but has a lot of potential for modding. They released mission editor that does extraction of some game data but we need whole thing. I hope someone will come with idea how to do that.

[aluigi]

They released mission editor that does extraction of some game data

uhmmm interesting, why not modifying the executable of the mission editor to remove this limitation?
I don't have the game so I don't know if it's technically possible but if the editor has a real full access to all the of2 file system (the win_000 files) limited only by the developers (like a check on the filenames or extensions) then it could be an idea.

[Simon]

Could you help the exe?

[XRaptor]

don't ask me how I did and don't ask me if and how it will work because the script is really horrible and after all I couldn't do something better because the format is not clear.
so yes, I know that it's horrible but works.

One thing - part of code is wrong

Code: Select all

    get OFFSET long MEMORY_FILE
    get DUMMY1 long MEMORY_FILE

there is no DUMMY1 - OFFSET is 64bit value

[aluigi]

yes but the total archive is under 0xffffffff bytes so OFFSET can be considered a 32bit value without problems (also because quickbms doesn't support 64bits)

[XRaptor]

yes but the total archive is under 0xffffffff bytes so OFFSET can be considered a 32bit value without problems (also because quickbms doesn't support 64bits)

Not exactly Whole data file is 0x1 0490 8000 (4 371 546 112). Offsets are stored as 64b value, so your script is not working correctly.

Code: Select all

    ...
    get OFFSET long MEMORY_FILE  << WRONG
    get DUMMY1 long MEMORY_FILE
    savepos DATAOFF MEMORY_FILE
    ...
    math OFFSET -= OFFSET_SEEK   << WRONG because of wrong OFFSET value
    math ZSIZE = OFFSET   << WRONG because of wrong OFFSET value
    math ZSIZE -= PREV_OFFSET   << WRONG because of wrong OFFSET value
    ...

Offsets in index block are not stored as expected (offset1<offset2<offset3...) but there are some "strange" values inside. That is why script hangs up I think.

[aluigi]

uhmmm why there is this difference between the size of the packages?
in the first post the reference was to 375 files so: 375*8000*1024 = 0xb71b0000 bytes

then even considering the 64bit problem remains the fact that people reported problems with the files having an offset between 250 and 300 mb.

anyway please no longer consider the script I posted in any case, it was only a test

[XRaptor]

it was only a test

I know it was just test. In full game there are 000-521 files, so it is little huge then data in 1st post.

[pietastesgood]

Yeah, for some reason the early leaked Russian version wasn't complete -> only to .375.