This topic was archived here:

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

bxaimc, posted Mon Jun 04, 2018 5:04 pm (35585)

---

Hi there! Going through some old stuff and I realize I don't have an extractor for Ape Escape 3. The whole game is packed into a single archive named DATA.BIN (~2GB, USA Version). Would anyone mind taking a look please? Here's a small snippet from the archive:

https://drive.google.com/open?id=1Hodwl_Oa7-xJU0Tw5N_rgW0zXylft6m9

thanks!

aluigi, posted Mon Jun 04, 2018 6:44 pm (35588)

---

http://aluigi.org/bms/ape_escape_vfi.bms

Some of the extracted files have a PCK extension, you can reuse the script on them for extracting their files.
It wasn't possible to do everything automatically (as I like to do) because files are compressed too so if I opt for the "automatic way" you will not be able to reimport the files back in the archive (usually what people want).

bxaimc, posted Mon Jun 04, 2018 9:47 pm (35591)

---

As always, thanks a bunch!

AnonBaiter, posted Mon Jun 04, 2018 11:54 pm (35593)

---

i remember working on this format before, although i was never really successful with it no matter what

here is my (WIP) script for comparison, just in case aluigi's ape_escape_vfi.bms script missed something i didn't(such as the entire hash table)
it's very barebones though - i don't really deal too well with file structures like this and it shows

also, i just noticed that the first .irx files had filenames that were formed like this

Code:

irx/3.0/sifcmd.irx
irx/3.0/file.irx
irx/3.0/sio2man.irx
irx/3.0/dbcman.irx
irx/3.0/sio2d.irx
irx/3.0/ds1o.irx
irx/3.0/ds2o.irx
irx/3.0/libsd.irx
irx/3.0/sg2iopm1.irx
irx/3.0/mcman.irx
irx/3.0/mcserv.irx

i thought there was supposed to be a "bin" folder coming before the "irx" folder in there or something

sg3_data_bin.bms

aluigi, posted Tue Jun 05, 2018 9:23 am (35602)

---

Yes there is a "bin" folder but handling it breaks some logic.

In case you want to test it, this is the code for replacing the one at line 68:

Code:

    do
        math CURR_OFF = PARENT_OFF
        math PARENT_OFF   FOLDERS_OFF
        goto PARENT_OFF
        callfunction GET_FOLDER 1
        string NAME p "%s/%s" PATH NAME
    while CURR_OFF != 0

Having that "bin" folder doesn't change much and introduces a big problem: is it possible to have files outside the bin folder (like /file.txt)? or is it "bin" just a placeholder for the root / ?

A file can't be outside bin because PARENT_OFF 0 is bin and a possible empty folder entry at the end of the table would have the 3 fields 0 0 0, still a PARENT_OFF pointing to 0 (bin).

Anyway without samples covering these hypothesis (files outside bin) there is nothing else to do.
In my opinion bin is the root so bin or not bin is the same.

AnonBaiter, posted Tue Jun 05, 2018 2:00 pm (35611)

---

at best, you could be right
although i do think that the "DUMMY" var as written on line 103 is actually FILE_OFF, so whether or not the "bin" folder is there depends on how zero-ed the FILE_OFF value actually is...?

really though i just noticed this one off because i mostly use the executable of the game as a reference for building filenames like these

aluigi, posted Tue Jun 05, 2018 2:56 pm (35612)

---

Eh no, it's not a FILE_OFF because it goes in the middle of nowhere both if you consider a relative offset to the TOC or an index (bigger than the available files)

AnonBaiter, posted Tue Jun 05, 2018 2:59 pm (35613)

---

ehh, maybe i just reached through a different conclusion from yours

aluigi, posted Tue Jun 05, 2018 3:05 pm (35616)

---

Where is your conclusion and proofs?
For example the "startup" folder (almost the last entry) has: 0x10, 0x32 and 0x68cf.
Offset 0x68cf ( 0x3e88) points in the middle and the maximum files are 0xf9a.
So what's 0x68cf in your opinion?

AnonBaiter, posted Tue Jun 05, 2018 3:24 pm (35617)

---

waaaaaaaaaaaaaaaaaaait i got this

actually you can handle that "value" like this

Code:

(0x68cf * 4)   INFO_OFF

and you'll get this result

Code:

0x1e324

said result is an offset that points to the general file info

alternatively there's also this PARENT_OFF variable that stays in line 43 out of that same file info which can be calculated by putting in this calc

Code:

PARENT_OFF   DUMMY(line 37)

this one also points to an offset that points to the general folder info, as seen with this result

Code:

0x1ee80

i don't think i'm explaining this all too well, just tried to clear things up

aluigi, posted Tue Jun 05, 2018 3:38 pm (35620)

---

FILE_OFF * 4 has sense.
But we are still blocked on the concept of root path
"bin" has no PARENT_OFF and FILE_OFF set to zero which means it points to the first file and has no parents, but we know that there are no files in bin.
And what would be the situation of a file located outside bin, I mean just in / ?
An empty folder entry with 0,0,FILE_INFO?

And the most important question... who cares? the script works and bin is an useless root path apparently.

AnonBaiter, posted Tue Jun 05, 2018 3:40 pm (35621)

---

to be fair i've never seen a file located in the "/" folder out of the DATA.BIN archive so let's leave it at that

aluigi, posted Tue Jun 05, 2018 3:49 pm (35622)

---

I can see a possible usage (necessity) of "bin" in case we have multiple archives in the game where each one covers a different root folder, maybe one for "bin", another one for "data", one for "blah" and so on.
But I guess this is not the case considered that it's just one big archive.

In a similar situation would be easy to convert the full-path builder using the file (the current solution) into a nested recursive function that parses the whole folder tree (the usually "callfunction EXTRACT" I use in most of my scripts).

This is the first time I see this "VFI" archive and we are talking about a game released 13 years ago... I really doubt we will see this format again.