XeNTaX

anyone know what compression this game is using? these aren't the zarc files that noesis opens.
thanks!

sample:
http://www.mediafire.com/?vr0p2gakbvx5tl6

EDIT: oops, posted in wrong forum

Just use this command on the file.
offzip.exe -1 -a -z -15 c:\file.zarc c:\output
model format looks pretty easy.
This file actually contains 2 zarc files. also it looks to be just a slightly modified psarc file.

Really? Now that's what I like to hear . I didn't see the 0x79 zlib signature used with the file list table so that confused me. I used
my own zlib code since offzip puts the file table in different files.

I'll check it out in a few days. Thanks!

Awesome.... figured it out thanks.

if someone needs to extract the big file you can use this.

and then, after you're run that script, put the following exe and zlib dll in the data directory and run the exe. it will extract all 20,000+ JPEG files in the data/book directory and convert all zarc files to their uncompressed forms (it will delete zarc files when done so back them up if you still want them). now somebody needs to write a model extractor. the character models aren't so great in this game but the environments are really nice...

http://www.mediafire.com/?2wx1rw8ikncnbea

it will delete zarc files

No option to not delete them?
Unfriendly program

ha ha ha well the problem is this:

the zarc files are named f_c01_i01.hpk.zarc
and the saved names are f_c01_i01.hpk

if i get to doing the models, leaving both files in the directory, when i do a batch search for *.hpk it will also try processing the .hpk.zarc files as well. WIN32_FIND_FILE sucks. i did it to make my life a little simpler. it's just 4 lines of code to leave them back in, but i would have to include a string check to not process any file ending in .zarc.

ok, this one won't delete the zarc files or the dat file that contains the jazillion jpegs.

EDIT: See next post.

Continuing on, this version of the data extractor operates in 6 phases and fixes a bug in the zlib code that made some of the hpk archives a little too big. Process takes 10 minutes or so.

phase #1: finds gvd.dat and extracts JPEG files.
phase #2: finds all zarc files and decompresses them.
phase #3: finds all hpk files, which are non-compressed archives, and extracts all files from them.
phase #4: finds all pkchr files, which have same format as hpk and are also archives, and extracts all files from them.
phase #5: finds all imgpak files, which are also archives (that typically only contain two files), and extracts all files from them.
phase #6: finds all img files, which contain DDS images, and extracts all DDS images within them.

http://www.sticklove.com/content/semory/ni_no_kuni.7z

notes:
character model data appears to be stored in the p3mmg files?
p3mmg has a funky vertex format, what I got out of it looked like a uv map more than a model.
bones data appears to be stored int the p3msk files?
animations appear to be stored in the ask files?
map model data is stored in mpk files. i got some geometry out of these.
do imgpak files contain images?

lol this is the same f-ed up format as white knight chronicles isn't it?

howfie Please update your links

.zarc use deflate compression.
data split on blocks.1 block after unpacking must have size no more 65536byte.

first row 16byte
offset 0-5 unchangeable head.
offset 6-7 quantity of block with data
offset 8-9 quantity of block with data that have size 65536bits after unpacking.
offset A-B unpacking size last block with data. if last block after unpacking have size 65536byte, this write null.
offset C-F size zarc file with head.

second row and etc description of the data blocks.
description of one block is 8byte.
first 2 byte -> size block
2byte size unpacked block, if block after unpacking have size 65536byte, this write null.
4byte start offset block + 1
if one row have descriptoin only one block, then following 8 byte write null.

start data block always start with new row.

if after end data block, row not full, it write null


sorry for my english

the zarc format is the easy part... the code is here. problem is the model format is time consuming.

also updated link above to the exe. maybe... maybe... one day in the future i'll come back and look at this lol.

I have very little experience and independent analysis of the file, even such a easy, a big achievement.
Thanks for your program.