Fix incorrect .cin extraction

[0HMyC]

Currently, the script will attempt to automatically detect when files are not aligned to their correct offsets in .CPK's, and seek and save the data seperately as needed to ensure the file can be extracted correctly. This mainly occurs with .cin files.

However, this is not necessarily correct behavior; certain .cin files end up being extracted with one of the .CPK's packed .tmx files being packed in; these are likely not meant to be in a .cin, given that they are still stored with the formatting of a CPK (Header, File data).

The script should be updated so that these files are correctly extracted and not unintentionally packed into the .cin files.

[Pioziomgames]

I don't belive that this is an issue with the tool. Atlus very often leaves random data(sometimes program memory, sometimes other files) in their files(the save file even). My assumption is that when creating new versions of cpk files with different textures they for some reason instead of just taking the cin data by itself, took the entire file but skipped the 0x100 bytes at the start. This doesn't cause any issues with reading cin files that have this unused data in them, because the amount of data interpreted from the cin file seems to fully depend on the value at 0x8 in the cin header.

Another thing that I should probably mention as this tool seems to be built around the idea that cpk is more than it actually is. Cpk files are essentially just ordinary pac files(the same as any battle or field archive) but exported with an awful exporter. (if you take any pac file, edit it to have a cin and tmx files in it with amicitia and rename it to .cpk it will work just fine) Any data between the end of the null terminated string in each cpk chunk and the size of the file is just random padding data.

Essentially I belive that it's something like this:

typedef struct {
    char FileName[252]; //The actual longest string that the game will accept without breaking is probably somewhere around 90
    int Size;
    ubyte File[Size];
    FAlign(64); //Align the current position to 64
} CPKChunk;

while (FTell() < FileSize()-256)
{
    CPKChunk File;
}

[0HMyC]

Cpk files are essentially just ordinary pac files(the same as any battle or field archive) but exported with an awful exporter. (if you take any pac file, edit it to have a cin and tmx files in it with amicitia and rename it to .cpk it will work just fine)

To be honest, I think the main reason I assumed they were a different format is that Amicitia doesn't support them at all (which if it really is just the same PAC format it probably should haha) and because of that I never even considered looking at a PAC file in any hex editor to compare or even realize that CPK isn't a different file format, it's just PAC in a different extension... which is an extremely ATLUS thing to do considering PAC files already have a lot of known extensions while using the same underlying format (.pac, .bin, .abin, etc. etc.)

Regardless, from taking a look at a couple of the CPK files I had left open in 010 and checking them with your snippet of template code there it does seem like what you're suggesting is about right and also more or less the same thing this script does, albeit MUCH much shorter and cleaner haha, so I'll go ahead and close this issue since it's more or less a non-issue in reality I suppose.