Harvest Moon 3DS XBB and PAPA documentation

1. XBB Archive Format
   a. A block - Header Blocks
      in this block is used to update the number of files, magic header, and reserved
      for purposes other reply. but of all of the files in hm, 24 bytes after
      magic header and the file count is not used.

      The length of the block: 32 Byte.

      format:
      u32 {
         u4: Magic Header (58 42 42 01 - XBB)
         u4: FileCount
         U24: reserved / padding
      }

   b. block B - FileSystem Blocks
      On this block is used to determine the position of the offset of a file and the file name
      it. It was not immediately know the intent of this checksum u4 used ...

      to determine the length of the block, FileCount * 16 Byte.

      format:
      UFC * 16 {
         u4: FileOffset
         u4: FileSize
         u4: FileNameOffset
         u4: CheckSum (?)
      }

   c. block C - / Blocks
      On this block is still diketahu what does what to do.

      for long menenjukan on this block, FileCount * 8 Byte.

      format:
      UFC * 8 ​​{
         u4: CheckSum
         u4: FileIndex
      }

      If seen look at this block contains a table sequence based checksum.
      Weve for what? o.o

   d. block D / FIMG Blocks
      On this block contains files that are in the archive format xbb.

      to determine the length of this block,
         FileArchiveSize - (BlockASize + BlockBSize + BlockCSize).

2. PP Archive Format
   a. A block
      in this block contains a magic header PAPA (50 51 50 51), is quite strange why wear
      this name. On this block size of 20 bytes, there are some parts of the
      the constant value which is always the same, do not yet know its usefulness.

      format:
      U20 {
         u4: MagicHeader
         u4: Padding - unused
         u4: Constant Value - 0C
         u4: FileSizeArchive**
         u4: FileCount
      }

**NOTE: This part confused me a bit, but after checking it against a lot of PAPA files from both games, I can confirm that this number will ALWAYS be the value of the first offset in Block B, minus C. So if the offset to your first file/text string is 4C (4C000000), then this number will be 40 (40000000). I guess this is the size of the block containing the pointers? I'm not entirely sure. I also haven't yet checked to see if this is the case with .xbb files.

   b. block B
      in this block contains the starting position of each section, always-sized file 0 0
      byte. to determine the size of each file offset [i + 1] -offset [i].

      to determine the length of this block, FileCount * 4 Byte.

      format:
      u4 {
         u4: FileOffset
      }

   c. block C
      in this block also has a few small parts, such as archive
      in the archive, especially not compressed in compressed: 3.

      to determine the length of the block, FileArchiveSize - (sizeBlokA + sizeBlokB)

   d. block C.A***
      The continuation of the block C, mostly pp file is almost the same data structure
      in this block. However, the use and handling of data in this block different
      different. for example, US and JP version of the message, the same ANB SoS is no different.

      to determine the length of the block CA Header: 8 + (4 * PartCount)

      format:
      UCAS {
         u4: C.A Size (might be wrong, I'm 99% sure this value is equal to CA + C, but I'm leaving the original documentation as-is)
         u4: C.A Count
         u4 * [C.A Count]: Offset C.A
      }

      For parts made dialogue text, usually formatted UCS / UTF-8 for parts
      identifier usually use ASCII.

***NOTE: Block CA comes BEFORE block C. Block C is your data, like your text strings, and block CA is information about it. As you can see, it begins with the size of the ENTIRE block C (so C + CA), then the number of "files," then the offsets to those files. Generally, the first two offsets won't change unless the type changes. And this is easier to keep track of in Story of Seasons since the variable names come before the string itself. Also note that the offset/pointer values are RELATIVE TO wherever block CA starts for your file. So if my CA block starts at 0x18, and my first offset/pointer in CA is 0x14, then my first "file" starts at 0x14 + 0x18 = 0x2C. For Msg PAPA files, this is a 4-byte block containing the word "Msg." After that at 0x18+0x18=0x30 is my second file. In ANB, this will be where the string starts, and in SOS, this is the string's variable name referenced by the .nut scripts. It will look something like this: 'MES_TEST_TEXT_1_01..'

I hope I'm not being too confusing. It helps if you have a hex editor out and you are viewing the file in a format such that 8 numbers are grouped at once (so that your magic header looks like this: 50415041), that way you can see everything 4 bytes at a time, just like the documentation above