Anonym271

I am glad to hear that, happy modding!

I fixed some bugs about two weeks ago but forgot to publish them as a new release. I just updated it, could you check out the new version and see if it works? The file size won't be the same as the original one since my compression algorithm is not as good as the developers'. I just tested the new version and repacked some CGs and it worked for me. If you still have issues, tell me and I will look deeper into the problem with your specific game.

I did some research about this ISM engine. I found this very interesting GitHub repository about all kinds of VN engines and it contains a link to this download page. There you can download all kinds of stuff needed to create a VN with the ISM engine (the .lzh archives can be opened with 7zip, WinRAR or other archivers). Especially interesting is the ISM development environment. Sadly, as far as I could see, none of the packages contains tools to decompose an existing game. But what I could find out so far is that the scripts are written in an own scripting language (.iss) and then compiled into .ism files. So you would probably need to write some kind of disassembler for these compiled scripts in order to edit them for translation. This seems like a hard but not impossible project, especially because we have access to the script compiler (it is contained in the dev environment). I already looked into the ISM scripts and found some stuff, in case it helps: Header 12 byte magic number ("ISM SCRIPT") 4 byte file size 4 byte offset, some offset in the file. Probably beginning of the code segment or something 4 byte uint, probably some kind of count (maybe local variables?) 4 byte count1 4 byte count2 --> count1 & count2 seem to be always the same Some list, directly after the header count is header.count1 (or count2) each entry is a struct { uint1, uint2, uint3 } uint1 is increasing with each entry, starting at 0 uint2, uint3 are relatively small numbers After that follow some readable strings (usually 2) like CHAP1_A and CountParagraph%0 each one prefixed by its length (1 byte) and followed by a 0 terminator Then more readable strings (same format), maybe function definitions or something Then follows the segment that header.offset (the third entry) points to By compiling one of the ISS examples from the mentioned download page I also found out that strings are stored with a simple XOR encryption. The key seems to change for each string though and I could not yet find where or how it is defined.

Can you provide some samples? I don't think there is an automated tool for this but if the file names already contain coordinates it should be relatively easy to create a simple script that does the job.

First, just to make sure that I correctly understood what you want to do: You want to copy the official translation of the game (English I guess) over to the PSVita version of the game to play it in English on the PSV, right? So, by just looking at the file you provided: every String in there is prefixed by its length in bytes. If you are lucky, it is enough to adjust this length to the new length after you did your edits. I tried this with the first sentence of the first scene (at least in the PC version) but I do neither own a PSV nor the PSV version of the game. I uploaded the modified file here so you can try it out. If this works, it is probably not that hard to write a simple program that does the length modification automatically. Edit: I uploaded the wrong version first, so in case you already downloaded it: I replaced it by the correct one now.

@Haoren So... did it work? If not, feel free to tell me the name of the game (or give me a sample package) and I will try to adjust the program to that version.

Hm, this really should only be thrown if you entered an invalid path. What command exactly did you run? And just in case: of course you have to leave out the brackets, so an example command would be: betterfpk.exe -p cg cg.fpk

Yes, I once wrote a tool that could repack SystemC FPK files and I also implemented a compression algorithm for it. Can you tell me what game you are working on? Because I believe there are at least two versions of the file format and my program only works with one of them. However, you could also just try it out: https://github.com/Anonym271/betterfpk. You can find an EXE in the releases section or of course clone the repository and modify it to your desires. It's a command line tool, use it like this: Extraction: betterfpk.exe -e <my-archive.fpk> [output-directory] Repacking: betterfpk.exe -p <my-folder> [output-file.fpk] It's not really fast and the compression results also aren't that great, but it should do the job I guess.

Okay, after Discord contact with @willow1sp we found out that they just used an old version of the extractor. So if anyone else wants to use the tools, here a summary on how to find the correct versions of the correct tools: To extract and repack the .bin files use "farc_win64" (or win32 in case you use a 32 bit system) To convert .tbg images use "tbg_win64" (or win32) To modify .tbx files use "TbxEditor" To edit .scn files (Dialogue Texts) use "SceneEditor" You can find them here in the different releases, always under "Assets". Just always use the most recent version that occurs.

I have fixed the japanese archives, it was just a very small stupid error. Tell me if you are still having problems with the latest version.

Hi, thank you for the feedback. I tried a little bit around and indeed the tool fails to open the Japanese (original) files. If you own the steam version you might just use the english archive files (found in dat/eng/...) for now as they should work; but I will nevertheless try to support the original archives, too. Edit: the sound archives do work for me - could it be that you are not using the steam version or something? @Cibermoon Do the sound archives work for you? And yes, there actually are more than 10,000 voice files in the voice.bin file

I am happy to hear this! Good luck and have fun translating

Hm... this is strange. It works for me. Is this the exact TGA file you have uploaded? And of course: make sure that the files are in the same directory as the tg5.exe file when you execute it. The workflow that works for me: place tg5.exe, the original CG001_A and your edited CG_001_A.tga in the same directory open a command prompt from here (navigate to the folder in your file explorer and type "cmd.exe" in the address field) execute the command: tr5.exe CG001_A CG001_A.tga CG001_B If this does not work for you I have no idea what could be the reason to be honest...

When you define how comand line tools should be used you usually put required arguments in <> and optional arguments in []. So what I wrote just meant: the first argument should be your original file, the second one the TGA file and as the last one you can offer an output. When you use the program you leave any kind of brackets away, so you just write: tr5.exe CG001_A CG001_A.tga CG001_B They are just here to tell you what you have to offer and what you are allowed to offer

Okay, this one will convert your image files back to the TeethingRing5 format: https://drive.google.com/file/d/1ZIyvDReCHd-bM3BA0xlLvZld65X1qrLo/view?usp=sharing Use it in the command line: tg5.exe <original_image_file> <new_file.tga> [output_file] It requires the original image file since it contains some metadata that is not stored in the TGA files (or whatever format you choose). If you omit the output_file argument the original_image_file will be overwritten. Also this does not apply any compression (in fact the file size will even be larger than the raw image data) so the file sizes might increase drastically. Tell me if the files get too big (e.g. if the maximum file size of the archives gets exceeded) or if anything else does not work, I will try to fix it then.

If you could provide some sample files I could take a look on them and maybe write you a conversion tool.

I guess the tool I sent you was actually for another version of the PACK files. But it looks like you found your solution in the data extraction thread already, right?

Hm, the BIN file does not really have any obvious structure and also I am not very common with MIPS architecture (the one the PS2 uses). Do you really need the PS2 version? Because the files of the PC version are already well known...

Good to hear that it works and also that it suits your needs

Thanks for the additions. I've also drafted a release in the GitHub repo that should work without dll errors

Of course, here you are: https://github.com/Anonym271/jkimouto-tools It is no problem, I can try to give you a little introduction into this if you want (although I am by far not an expert myself). But I would suggest to do this via Discord (Anonym271#6243) or another chat messenger rather than here in the forums.

Oops, sorry. Now you should have access. How much do you know about reverse engineering, IDA / Ghidra and x86 assembly? Because a basis of knowledge (and of course lots of time and patience ) is always needed for decrypting and stuff...

The PLT files of the game are encrypted for some reason and Arc Unpacker does not know this encryption. I found the decryption algorithm in the game and was able to rewrite it, but sadly I could not yet find out how the keys for the encryption are generated. I finally ended up just dumping the keys out of the game's memory and using it for my own program. You can download the program here. It should be able to decrypt at least most of the PLT files of this specific game but I can't say if it will work for all since I only have this specific encryption key. Let me know if something doesn't work. The ANM files are probably only there to tell the game how it should make an animation out of the individual frames, that's why they are so small.

Oh, okay. This makes more sense now. I am pretty sure that is it not allowed to share pirated software here, but I will find my own way to the ISO

Are the original files smaller than 4 GB and the new ones bigger? If so, I guess the archive format only supports files up to 4 GB (2 GB may also be a possible limit). The format probably contains support for a compression algorithm that was used to compress the original archives but your repacker didn't implement this compression. This is why your new files are so much bigger and probably also why they exceed the maximum supported size of the archive format while the original ones didn't.