Fatal Frame: Maiden of Black Water(Wii U)

[zdsmdbh]

http://www.mediafire.com/download/t5350s9iks8oa7s/archive00.rar

There are 2 files in archive.
1. archive00.dat
Main game data file,original file size is 3.31GB,I cut header to get a 20MB sample
2. lfm_order.bin
Store filename string.

I do some research on these file,and I did find something,sadly I don't know how to write a unpack script.

archive00.dat:
File end at D4 4F A0 00

So I believe these are absolute offset


lfm_order.bin:

[aluigi]

http://aluigi.org/bms/fatal_frame.bms

[zdsmdbh]

Should I upload the whole 3.31GB file or cut a bigger sample(50MB,100MB,or bigger)?

[aluigi]

Sorry, I didn't notice the alignment.
Fixed in 0.1.1

[zdsmdbh]

Thanks a lot,script works fine now.
Quickbms crash in half through,maybe it's my personal problem.(I am using Win10)

[aluigi]

That's really strange.
What's the error you get?
quickbms should display various information if something similar happens (debugging stuff plus backtrace).

[zdsmdbh]

Yes,that's really strange.
I just re-unpack it three times,quickbms extract every file without a error.
So it's my personal problem,sorry.

[Elusivo]

Hi

This script is working perfectly for extracting the files from the archive, but i can't get it to repack with my modded files.
When i reimport it finishes without errors when i choose the experimental reimport method, but the archive remains unaltered, dunno if it's me doing something wrong, or this script cannot reimport files to the archive?

Since i only want to reimport a couple files can it be done manually? I don't know how to find the offset of the files in the archive and how they're compressed tho...
Update: ok, i think i figured out how to hex edit it manually, assuming the order of the files in the archive is in the same order as in the lfmo (will do some testing).

[aluigi]

The script is not valid for reimporting.

[Elusivo]

oh, ok :/

Any possibility of anybody making a script to reimport files?
I do know the zlibs in the archive are broken in chuncks and that's what i dunno how to do, i tried to manually add a file in as a single full block but it hangs the game, so i'm guessing it either needs to be in chuncks or i screwed up the mod, will try tomorrow with an original file compressed in a single block to see if that's the problem.

[HyeVltg3]

Registered just to ask the same thing as Elusivo, google brought me here.

Could anyone please be so kind to make a reimport script. I'm probably doing the exact same thing as Elu, I just want to replace the Japanese text and menus with the English dump.

Thank You.

[aluigi]

Can you check if the following script works in REIMPORT mode?

Code: Select all

endian big

open FDSE "lfm_order.bin" 1 EXISTS
if EXISTS != 0
    idstring "LFMO" 1
    get DUMMY long 1
    get FILES long 1
    get DUMMY_OFF long 1
    get INFO_OFF long 1
    get ARCHIVE_NAME_OFF long 1
    get NAMES_OFF long 1
    goto INFO_OFF 1
    for i = 0 < FILES
        get ID longlong 1
        get NAME_OFF long 1

        savepos TMP 1
        goto NAME_OFF 1
        get NAME string 1
        putarray 0 ID NAME
        goto TMP 1
    next i
endif

idstring "LNS5"
get ZERO longlong
get FILES long
get ARCHIVE_SIZE longlong
get ALIGN longlong
for i = 0 < FILES
    get OFFSET longlong
    get SIZE longlong
    get ZSIZE longlong
    get ZIP longlong
    if ZIP == 0
        log "" OFFSET SIZE
    else
        savepos BACK_OFF
        goto OFFSET
        if EXISTS != 0
            getarray NAME 0 i
        else
            set NAME string ""
        endif
        math TMP = 0
        append
        do
            get CHUNK_ZSIZE long
            savepos OFFSET
            if CHUNK_ZSIZE & 0x8000
                math CHUNK_ZSIZE & 0x7fff
                clog NAME OFFSET CHUNK_ZSIZE 0x10000
                math TMP + 0x10000
            else
                log NAME OFFSET CHUNK_ZSIZE
                math TMP + CHUNK_ZSIZE
            endif
            math OFFSET + CHUNK_ZSIZE
            goto OFFSET
            padding 0x10
        while TMP < SIZE
        append
        goto BACK_OFF
    endif
next i

It's just the original one except that it uses directly the output file instead of the memory file.
You do not need to re-extract the files.

[HyeVltg3]

cant tell if it works, every file I replaced (EUR > JP) is bigger than the "old size" some files are 1-2 digits bigger, could there be any problem with reading? going to try to force them all and test, will just take a while. I compared sizes before choosing which files to I would like import, most of the EUR files are either smaller or equal in filesize.

Edit: I believe its comparing the uncompressed size to the compressed size in archive00, somehow, yet still says "(uncompressed)" in bms.

Edit: Tried with force: only ended with this error, I believe its no big deal will test game.

Code: Select all

Error: incomplete input file 0: W:\QuickBMS\archive00.lnk
       Can't read 4 bytes from offset eead9380.
       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%   172256     3561988096

Last script line before the error or that produced the error:
  51  get CHUNK_ZSIZE long

reimported - MD5-9BF1B21079D5993A292BDA4695E93904 archive00.lnk
Original - MD5-5C3119940C5112070CE1174B42090459 archive00.lnk

Not sure if this would help understand what I meant, I realize now I should have grabbed the error from bms, but missed it, just transfer game to test. ~10MB/s transferring 11.1GB is takes a long time.
Image

Edit:Edit:
Crashes console after choosing new-game, cant really see any differences from original and what was changed(translated)

[Elusivo]

Can you check if the following script works in REIMPORT mode?

Code: Select all

endian big

open FDSE "lfm_order.bin" 1 EXISTS
if EXISTS != 0
    idstring "LFMO" 1
    get DUMMY long 1
    get FILES long 1
    get DUMMY_OFF long 1
    get INFO_OFF long 1
    get ARCHIVE_NAME_OFF long 1
    get NAMES_OFF long 1
    goto INFO_OFF 1
    for i = 0 < FILES
        get ID longlong 1
        get NAME_OFF long 1

        savepos TMP 1
        goto NAME_OFF 1
        get NAME string 1
        putarray 0 ID NAME
        goto TMP 1
    next i
endif

idstring "LNS5"
get ZERO longlong
get FILES long
get ARCHIVE_SIZE longlong
get ALIGN longlong
for i = 0 < FILES
    get OFFSET longlong
    get SIZE longlong
    get ZSIZE longlong
    get ZIP longlong
    if ZIP == 0
        log "" OFFSET SIZE
    else
        savepos BACK_OFF
        goto OFFSET
        if EXISTS != 0
            getarray NAME 0 i
        else
            set NAME string ""
        endif
        math TMP = 0
        append
        do
            get CHUNK_ZSIZE long
            savepos OFFSET
            if CHUNK_ZSIZE & 0x8000
                math CHUNK_ZSIZE & 0x7fff
                clog NAME OFFSET CHUNK_ZSIZE 0x10000
                math TMP + 0x10000
            else
                log NAME OFFSET CHUNK_ZSIZE
                math TMP + CHUNK_ZSIZE
            endif
            math OFFSET + CHUNK_ZSIZE
            goto OFFSET
            padding 0x10
        while TMP < SIZE
        append
        goto BACK_OFF
    endif
next i

It's just the original one except that it uses directly the output file instead of the memory file.
You do not need to re-extract the files.

Haven't had the chance to try it yet, but from what I understand of the format I think it splits the uncompressed file into 16KB chunks, compresses each of them separately and writes them consecutively with the compressed size of each chunck added by 0x8000 written on the preceding 4B and padded with zeros after the end till aligned to 16B before starting the next chunck.
Dunno if the sizes of the compressed and uncompressed sizes also need to edited at the 32B pointer address line.

Will try it tonight.

@HyeVltg3 if u use bigger files to reimport they will overwrite the next file, or u would need to recalculate all file pointers and change them.

[DarkKaine]

I've been doing some work on this, and hit a wall for now.
At 501BAD40 in the Japanese version of the archive, there is a block of data that is part of a file yet it's not compressed with zlib.

Code: Select all

501BAD40 00 00 00 28 46 4C 49 4D FE FF 00 14 04 00 00 00 00 05 40 28 00 01 05 ...(FLIM..........@(...
501BAD57 00 69 6D 61 67 00 00 00 10 02 BC 01 90 20 00 17 04 00 05 40 00       .imag.......É .....@.

I have no clue what it is.
The data is for the file: /LAYOUT/CHANGE_COSTUME/CHANGE_COSTUME.ARC. This is the 52th block.
In the Japanese version that's entry 606.

[Elusivo]

ye, looks like they do some mix there huh, the last zlib chunck ends at 501BAD35, then the uncompressed block starts with a 0x00000028 which (assuming the file was extracted correctly from the archive) is not written in the actual CHANGE_COSTUME.ARC file, so i guess that 0x28 is working like the preceding size of the zlib chunck but in this case it only means that what's ahead is not compressed data?

There's a bunch other files with the same method, and always at the end of the files.

[DarkKaine]

ye, looks like they do some mix there huh, the last zlib chunck ends at 501BAD35, then the uncompressed block starts with a 0x00000028 which (assuming the file was extracted correctly from the archive) is not written in the actual CHANGE_COSTUME.ARC file, so i guess that 0x28 is working like the preceding size of the zlib chunck but in this case it only means that what's ahead is not compressed data?

There's a bunch other files with the same method, and always at the end of the files.

Yup, it broke my extractor as i was doing math and subtracting 0x800 for the size. I guess I will add a check there to see if the data is smaller than 0x800 and treat those blocks differently. The question is why didn't they compress that block? Maybe the last block was too small for compression to be beneficial. I'll look more into this later.

[aluigi]

Try replace the two 0x10000 in the script with 0x8000.
If I used 0xx10000 without comments, it means it's necessary but who knows...

[HyeVltg3]

@HyeVltg3 if u use bigger files to reimport they will overwrite the next file, or u would need to recalculate all file pointers and change them.

I did, if you check the image I posted in that post, you can clearly see the EUR file is smaller than the JPN file it replaced. I know this is a bit late, and kind of moot now that the packing/reimport process is a bit tricky/incomplete. Just wanted to say I was getting the warning in quickbms for files I had already checked and made sure were smaller, I didnt slap things together, I compared every single filesize, of about 241 files (took a lot of time + stretching).
Initially just wanted to English-fy the Japanese story portions (in-game theres screens of text inbetween gameplay that explains whats going on)

Odd note, I find that the JPN ver. loads and works better (less stutter/lag) than the EUR dump. tried out the EUR dump and noticed inbetween cut-scenes and gameplay theres a slight pause, which isnt noticeable on the JPN dump, even went back and checked[JPN ver.]. I really feel like going up to latest fw (the "usual" way) and grabbing the NA/US version off the eShop and dumping it. but thats a lot of trouble/$ for "testing", but would be a better apples to jpn-apples comparison, the EUR version has a lot of extra data for the different languages.
Using a Kingston SDXC UHS-I U3 64GB SD card (microSD in SD adapter) so pretty much Fast! read and writes, definitely overkill for a WiiU.

(...I realize the second paragraph doesnt really belong here, just tell me if I should remove it, left it for context.)

[phay007]

This script is not working for extracting the files from the archive00.lnk.