[Tutorials] [Case Study][Innocent Grey] Kinbaku Ouji Translation

Entai2965

Moderator
Moderator
Elite Member
Dec 28, 2023
88
45
main.jpg


This is a case study in how to translate a visual novel so people understand what the process actually entails which can be used for educational and other purposes.

This goes through the actual steps required to develop a workflow that can be used to translate an arbitrary VN on an arbitrary game engine using traditional translation techniques. This does not cover translation via application hooking. For translators, the procedure for figuring out how to create patch is more useful than just having a translated patch or vague instructions since the concepts can extend to other languages besides English, translations for games, and game engines.

Warning: If there are no tools to work with a game engine, then developing them or asking/hiring a developer to develop them may be required. Luckily, this one did not happen to need any of that.

Since I received a request for help in translating Kinbaku Ouji, Lit: Bound Prince, I decided to document the steps here. That is what is meant by "case study". This is not a general procedure for how to translate VNs, or even other VNs for this game engine, but rather the specific tangible steps required to translate this specific VN. Some steps are generalizable, but others are not.

Kinbaku Ouji can be download here. According to VNDB, it looks to be a BL fanfic of Death Note, which is an Anime/Manga series.

The first thing to do is to extract the game and make sure it works. If it does not work normally untranslated, then there is no point in trying to translate it since it does not work anyway.
Launching "緊縛王子.exe" with a JPN locale emulator seems to make it work and it loads the first script.

Take a screenshot or otherwise note the first line of the game. It is the goal of a "proof of concept" to change that line to a different language. As long as the proof of concept is completed, then the only thing left is the actual work of translation since the proof of concept verifies the workflow required to translate the game's dialogue and/or images.

Since the VN works, it is time to close it and try to unpack the assets.

Games have different types of assets like audio files, video, images, program settings, save data, and, the most important one for our purposes, scripts for the untranslated dialogue. Developers normally pack their assets into archives, similar in concept to .zip files, and then rely on the game to unpack them dynamically at runtime. Unpacking assets means working with archives. Working with visual novel archives usually means using GARbro, Game Resource Browser.

For VNs, always try GARbro first before trying anything else. GARbro supports a lot of formats, some mainstream some very obscure. It can even write some, but not all, types of archives. It can read from more archives than it can write since developing a parser for reading files from archives is easier than developing a parser to pack those same files into archives. There is also a lot more demand for reading due to people wanting access to OSTs, and CG galleries so once a developer has written a parser, they often choose to let someone else handle the more difficult work on packing if they are not interested personally.

- Open GARbro.
- Copy/paste the game's location to the top navigation bar and press enter or navigiate to the game directory manually.

2.jpg

Next, try opening the script.dat file.

3.jpg

Okay, so GARbro can read the script.dat archive and see there are files inside. Let's try extracting everything. ctrl + A to select everything. Right-click somewhere in the file selection window and select Extract. Pick an extraction path that makes sense, like under a new folder called extracts in the main game directory or similar. Using the archive.dat name in the folder name also makes sense. So for this one it would be main_game\extracts\script\ or similar.

4.jpg

Just because GARbro can unpack files does not mean it is doing so correctly. Sometimes files or obfuscated or encrypted using information GARbro is not aware of. Is this one of those cases? Double click on the ".. <DIR>" line in GARbro to go up one folder level and then enter another .dat file. The other files should have images or sound. Let's try looking at an image or extracting an audio file and see if it plays normally.

5.jpg

It looks like bmp.dat has pictures and GARbro can display it natively. That means it can correctly display pictures from bmp.dat which dramatically increases the odds that it is extracting the script files correctly. Extracting an audio or image file would work to double-check that, but it seems to work, so let's just move on.

Okay, so unpacking using GARbro works. Let's open the script in Notepad++ and see what the script file looks like.

While in Notepad++, double check the line ending is either UTF-8 or Shift-JIS, as those are the two most common encodings for Japanese language VNs. Character encodings are different ways of representing characters like letters, numbers, control characters, and characters for complicated languages like Chinese and Japanese. Not all encodings can support all characters. Looking at the text file with the wrong encoding results in mojibake, so always make sure to look at them using the encoding they were created in. Only use UTF-8 if at all possible. For Japanese VNs, especially old ones, the encoding is usually Shift-JIS, so make sure that is selected at the bottom right in Notepad++. If it is not autodetected, select it manually: Encoding->Character sets->Japanese->Shift-JIS.

6.jpg

Hummm. That is not a normal text file. Still, there are large chunks which are readable in Japanese using the Shift-JIS encoding. From those two pieces of information, that means it is a binary encoded text file which is a text file that uses weird game engine specific formatting for the text. I will define game engine in a bit. Dealing with that will probably be a pain. Let's deal with it later.

The more immediate question is: does packing work?

As cool as it is to unpack stuff, it is not possible to translate anything purely by unpacking the assets. From a technical perspective, packing/displaying is the hard part. To verify the workflow of translating a game using traditional methods, unpacking->translating->packing must be done. Without that, there is no way to create the "proof of concept" that verifies that the translation can actually be done. That said, unpacking is a huge clue about how to pack it. So in the worst case, writing a packer based upon the unpacker should be theoretically possible.

With our goal clear, time to figure out if packing works or not.

- Go back to GARbro.
- Go to the script folder that has the extracted script files.
- ctrl + A to select all.
- F3 or File->Create archive.
- Click on the archive format box.

7.jpg

Which of those archive formats looks like it might work?

- Try all of the ones that look like they might have the same extension of ".dat".
- After creating the archive, move the created archive to the main game directory.
- Double checked that it is named exactly the same including cAsE.
- Be sure to backup the original script.dat file if that has not already been done.
- Launch the game using a Japanese locale emulator or with the locale set to Japanese, Japan.

The game just sort of loops at the home screen whenever it fails to load the archive.
- Return the original script.dat file to the game folder.
- Launch the game using a Japanese locale emulator or with the locale set to Japanese, Japan.
- It should work again.
- Replace it with the GARbro created .dat and it should break again.

In other words, the original script.dat works, but GARbro created script.dat does not work. Since packing using GARbro did not work, it is time to dig deeper!

Opening the *.dat files, like script.dat, in a text or hex editor reveals the string 'PACKDAT' as the first few characters. That is the header or identifier for that file type. Notepad++ is fine for just the first look. An actual hex editor like wxHexEditor that supports Shift-JIS character encoding is recommended if you are trying to reverse engineering anything, like the script format which is going to need to be done eventually.

Since Garbro can open them, it must have code related to that archive type. Here is the source tree for various Garbro archive formats.

https://github.com/crskycode/GARbro/tree/master/ArcFormats

Searching through the list for the string 'PACKDAT', 'PACK', and 'DAT' eventually reveals that the archive format is defined in this file.

https://github.com/crskycode/GARbro/blob/master/ArcFormats/ArcPACKDAT.cs

If you read the code, it obviously only supports unpacking, not packing. If you can't read code, then the last line in the following code block makes that obvious for non-coders as well.

Code:
        public override string         Tag { get { return "PACKDAT"; } }
        public override string Description { get { return "SYSTEM-ε resource archive"; } }
        public override uint     Signature { get { return 0x4B434150; } } // "PACK"
        public override bool  IsHierarchic { get { return false; } }
        public override bool      CanWrite { get { return false; } }

The "CanWrite" header for the archive format returns "false" which probably means that it cannot write that archive format which means none of the options in the UI could have possibly worked.

But before writing a custom packer for that PACKDAT archive format, maybe someone else has already written one?

I tried searching for "SYSTEM-ε resource archive", "System Epislon," and similar but did not find anything. Dead end, at least for me.

Going back to the Garbro source code file ArcPACKDAT.cs, at the top it has this.

Code:
//! \file       ArcInnGrey.cs
//! \date       Mon Jan 19 08:57:16 2015
//! \brief      Innocent Grey archives format.

The file is called ArcPACKDAT.cs, not ArcInnGrey.cs, but that header does not reflect that. It must be an old header. That modified date more or less says the same thing: it is an old file. Since the file used to be called ArcInnGrey.cs, but was renamed, then what exactly is "ArcInnGrey"? It is probably short for "Archive InnGrey" What is "InnGrey"? Looking at the next line, it says "Innocent Grey archive format," so "InnGrey" is probably "Innocent Grey". Still, what is Innocent Grey? Is it a game engine or a company or something? Never heard of it.

A game engine is the core part of a video game that actually does everything like loading images, audio, video, supporting save/load functionality, loading dialogue scripts, and everything else. It is possible to develop multiple games using the same game engine. The only thing the developer changes in that situation are the Audio/Visual assets, and dialogue scripts. Sometimes a developer might also might make slight changes to the game engine over time.

Dumping "Innocent Grey" into a search engine leads to, among other things, reddit.

"I am midway through Kara no Shojo 2 after completing KNS1," --reddit

What is "Kara no Shojo 2"? Going by the subreddit name, is that a VN? Searching for "Kara no Shojo 2 VNDB" leads to its VNDB page.

https://vndb.org/v5922

Code:
Developer    Innocent Grey

How interesting. In other words, "Innocent Grey" is a developer, not necessarily a game engine. That said, some developers use their own in-house game engines, so it might be both in this case. Other developers use more well known game engines like NScripter or kirikiri. What game engines is developer Innocent Grey known to use?

Looking down at the Releases>English section, it looks like it has a few official releases, and very interestingly, it has at least one unofficial release.

https://vndb.org/r75113

In other words, the group Oneline's Workshop found a way to translate the game and they have done a few other games. Are those other games that Oneline Workshop translated also Innocent Grey games? Is this particular Innocent Grey game using an in house engine, did they switch at some point, or what? Some developers do that. How did Innocent Grey develop their past games?

Here is the VNDB page for Innocent Grey as a developer. https://vndb.org/p277

Do any of Innocent Grey's past releases have fan translations using any engine including possibly an in-house "Innocent Grey game engine"? I could search through that list, but Oneline's Workshop already translated one of their games. Maybe they did more from the same developer and there is a record that confirms they were working with a particular game engine?

https://vndb.org/p11576 And clicking on every link gives this list.

https://vndb.org/r104371
https://vndb.org/r77942
https://vndb.org/r81764
https://vndb.org/r81028
https://vndb.org/r75113
https://vndb.org/r70062
https://vndb.org/r66338

How lucky. That first link for Kara no Shoujo - The Last Episode Prequel, https://vndb.org/r104371 , has an interesting link.

Code:
Engine    InnocentGrey

*click*

https://vndb.org/r?f=fwInnocentGrey-

That 'f=fw' syntax in VNDB links means the next part of the string is a type of game engine. In this case the "Innocent Grey" game engine is internally referred to by VNDB as "InnocentGrey". Intuitive, unlike Garbro's naming system. So, the "Innocent Grey game engine" does exist after all.

Anyway, it looks like most of the titles that VNDB is aware of that use the Innocent Grey game engine are titles that have Japanese language releases but not English ones except for 1, that Kara no Shoujo patch.

Going back to Oneline's Workshop, https://vndb.org/p11576 , how did they translate that game using the Innocent Grey game engine? Do they have any tools for it? They have a discord link, so social people can join their discord and ask them.

Alternatively, maybe they published their tools somewhere already? Where would someone publish tools to manipulate game engines for VNs? Maybe on Github? Maybe VNDB? Maybe fuwanovel?

Github is the largest repository for open source projects online. Let's search there first. So let's go over to Github and search for something. Search for what exactly? Well, if Kara no Shoujo has a patch, then maybe the patch itself was uploaded to Github. Alternatively, maybe the Kara no Shoujo Japanese characters would work, 虚ノ少女, or the game engine. Let's try the game engine.

https://github.com/search?q=Innocent grey&type=repositories

On the left it says Code, Repositories, Issues, Pull Requests. Maybe repositories is the correct one, but maybe not. If Repositories fails, there are other categories to look for clues.

Let's see. Time to read the descriptions.

Code:
lennylxx/IG_tools
Tools to process the game files by Innocent Grey & Noesis, for translation.

RikuKH3/igapack
Innocent Grey Archive Unpacker/Packer

Those both look interesting. *click*

https://github.com/lennylxx/IG_tools
https://github.com/RikuKH3/igapack

It looks like igapack is for .iga files. Are those image files or something? That might work but the lack of a detailed readme is disapointing. What does the other one say? IG_tools mentions *.s script files. Bingo!

Now for the moment of truth. What language did they program in? Languages: C++ 98.1% Miss! Damn. C++ needs to be compiled to work. If it was written in a language that uses an interpreter, it would be possible to get to work almost always, but with compiled languages, only the original developer is in a position to compile it without it being a massive headache because only the original developer knows what environment they developed it in. How is anyone besides the developer supposed to know how to compile it if they did not provide step-by-step instructions with excessive levels of detail and scripts to compile their software? The word 'compile' does not even appear in their readme. How typical. *sigh* My hopes are thoroughly dashed.

Well, maybe they were not spiteful to their potential users and took the time to compile their software so real people could actually use it instead of leaving it as source code that is only useful to developers? Many software developers never bother never both to compile their software because real word use, who cares about that right? Well anyway, what does the releases page say?

https://github.com/lennylxx/IG_tools/releases

Ooooh. There is a file called "igtools.zip" How interesting. How unexpected. Maybe it even contains binary files? Does it really? Did they take the time to compile their code and upload it? Really?

Let's try downloading it, scanning it with AV, and then looking inside of the archive. No hits on AV, but that does not mean much since AVs are a black-list style approach. The archive has some binary files though which is very promising. That means the developer really did compile their code. How thoughtful. It seems they want people to use their software after all despite coding in C++. How very unexpected.

Looking back at their readme it says how to use the tools.

Code:
1.use igtool.exe to extract script archive file.

igtool -x script.dat

2.enter the new script~ folder and use igscript.exe to parse the script file.

igscript -p 00_0000.s 00_0000.txt

3.after 00_0000.txt is edited, create the new script file.

igscript -c 00_0000.s 00_0000.txt new\00_0000.s

for CureGirl and フリフレ2, you need to add an extra option -x.

igscript -x -p 0000.s 0000.txt
igscript -x -c 0000.s 0000.txt new\0000.s
 
Last edited:
  • Love
Reactions: Eir
Applications can have Graphical User Interfaces (GUIs) or Command Line User Interfaces (CLIs). GUIs have fancy windows and buttons and an X at the top right to close it. In contrast, CLI applications must be run within the context of the Operating System's (OS's) command prompt or terminal. Even the simplest GUIs are very complicated to write and require a lot of code. In contrast, CLIs are extremely simple for developers to write in nearly every language and tend to require very few lines of code compared to GUIs. This makes CLIs very common when working with obscure or very simple software that is less than a few hundred lines of code. Software tools that can unpack arbitrary archives and scripts are almost exclusively CLIs.

Hummm. From the instructions, it looks like the tools are command line applications that work by using switches -p -c -x and file positioning. What do the tools themselves say for their help information?

- Extract the tools using 7-Zip.
- Open a command prompt.
- Drag the tool into the command prompt window.
- Press Enter.
That will run each tool without any arguments.
-- Sometimes using --help or /? is needed to get CLI applications to print out their help information. Some software developers also just do not include usage information at all.
- Anyway, the following gets printed out after following the above steps.

Code:
>igtool.exe
igtool by 7k

usage:  Extraction mode: igtool.exe -x input.dat
        Creation mode:   igtool.exe -c [folder] output.dat

>igscript.exe
igscript v2.3 by 7k

usage:  Parsing  Mode: igscript.exe -p input.s output.txt
        Creation Mode: igscript.exe -c input.s input.txt output.s

  Note: When dealing with "CureGirl" and "Furifure 2", add an
        opt tag '-x' like this: igscript.exe -x -p input.s output.txt

>igscriptD.exe
usage:  Parsing Mode: igscriptD.exe -p input.s output.txt

          Note: When dealing with "CureGirl", add an opt tag '-x' like this:
        igscriptD.exe -x -p input.s output.txt

        !Debug edition only support "Parsing Mode".

Okay, so the D in igscriptD.exe means 'Debug' and it 'only support "Parsing Mode".', whatever that means. Maybe it means the developer is/was ESL? Let's just ignore that file exists for now. The other two seem like they might be useful.

Let's try running igtool.exe on the script.dat.
According to the usage syntax, that is this.
Code:
igtool.exe -x script.dat
Code:
C:\Users\User>C:\Users\User\Desktop\OrangePekoe\igtools\igtool.exe -x "C:\Users
User\Desktop\OrangePekoe\緊縛王子(death note同人ゲーム)\backups\script.dat"
[+] 009_2.s                          offset[000004f0] size[00000f2f]
[+] 010_2.s                          offset[00001420] size[00001039]
[+] 011_3.s                          offset[0000245c] size[0000244e]
[+] 012a_3.s                         offset[000048ac] size[00001b4d]
[+] 012b_3.s                         offset[000063fc] size[00002730]
[+] 013_4.s                          offset[00008b2c] size[0000166a]
[+] 014_4.s                          offset[0000a198] size[000010d8]
[+] 015_4.s                          offset[0000b270] size[00002b0f]
[+] 016_4.s                          offset[0000dd80] size[00001bec]
[+] 017_5.s                          offset[0000f96c] size[00002746]
[+] 018_5.s                          offset[000120b4] size[00000b5e]
[+] 019_5.s                          offset[00012c14] size[00000f0b]
[+] 020_5.s                          offset[00013b20] size[00000d46]
[+] 021_5.s                          offset[00014868] size[000040b5]
[+] 022_5.s                          offset[00018920] size[00000ee0]
[+] 023_6.s                          offset[00019800] size[0000ac44]
[+] 024_7.s                          offset[00024444] size[00001f37]
[+] start.s                          offset[0002637c] size[0000000f]
[+] 001_1.s                          offset[0002638c] size[00003886]
[+] 002_1.s                          offset[00029c14] size[00001856]
[+] 003_1.s                          offset[0002b46c] size[0000137d]
[+] 004_1.s                          offset[0002c7ec] size[00003607]
[+] 005_2.s                          offset[0002fdf4] size[000016d4]
[+] 006_2.s                          offset[000314c8] size[00001929]
[+] 007_2.s                          offset[00032df4] size[000015f7]
[+] 008_2.s                          offset[000343ec] size[000031cb]

Total: 26

It did something. Cool. What did it do? Humm. Looking a the folder, it looks like there is now a new "script~" folder and lots of *.s files are inside of it. Let's just move that to a subfolder to keep everything nice and tidy and remove the ~.

So, do the hashes of the extracted files match the hashes of the files extracted by Garbro? Use 7-Zip's hash feature to check.

Hashes are mathmatical algorithims that output a predetermined number of bits irrespective of their input. Importantly, they will always have the same output based upon the same input but a single bit of the input changing will completely change the hash. This means that if the hashes match for two different inputs, then that proves the files are the same.

Code:
Garbro extracted:
Name: 001_1.s
Size: 14470 bytes (14 KiB)
CRC32: 744C6DD4
CRC64: 3AEE091B9F1BDA66
SHA1: c316c04503ddd96fc17228d99b9789276c0fcc59
SHA256: d4e0b258a93cde0e6a2d1d738ed3a82bb29cb9f74d3e5d11bbbbbd0e8b05c816

igtool.exe extracted:
Name: 001_1.s
Size: 14470 bytes (14 KiB)
CRC32: 744C6DD4
CRC64: 3AEE091B9F1BDA66
SHA1: c316c04503ddd96fc17228d99b9789276c0fcc59
SHA256: d4e0b258a93cde0e6a2d1d738ed3a82bb29cb9f74d3e5d11bbbbbd0e8b05c816

Okay, the hashes match. Awesome. That makes it slightly less likely that either tool is messing up the extraction process, or that both tools are messing up in exactly the same way. If it did not mess up extracting, maybe it can pack them too? Can it? Let's try packing it without making any changes to find out.

Code:
C:\Users\User>C:\Users\User\Desktop\OrangePekoe\igtools\igtool.exe -c "C:\Users\User\Desktop\OrangePekoe\緊縛王子(death note同人ゲーム)\extracts\extracts_from_tool\script" script.dat

The system cannot find the path specified.

Total: 0

Nope! Nothing. Did anything happen at all? Oh, there is a near empty 16-byte file created at C:\Users\User\script.dat. Opening it, it looks like only the header was written. So it wrote the header of the archive.dat, but nothing else. In other words, it could not find the source files to add to the archive. Is the syntax wrong? The instructions are this.

Code:
C:\Users\User>C:\Users\User\Desktop\OrangePekoe\igtools\igtool.exe
igtool by 7k

usage:  Extraction mode: C:\Users\User\Desktop\OrangePekoe\igtools\igtool.exe -x
 input.dat
        Creation mode:   C:\Users\User\Desktop\OrangePekoe\igtools\igtool.exe -c
 [folder] output.dat

That means the creation syntax is igtool.exe -c script_folder script.dat Is that the command that was run?

Code:
igtool.exe -c "C:\Users\User\Desktop\OrangePekoe\緊縛王子(death note同人ゲーム)\extracts\extracts_from_tool\script" script.dat

Well, the syntax is correct, so why does it not work even though the syntax is correct? Maybe it is just bad software? Well, if it is bad software, that means it was written poorly. Written poorly... maybe the packing logic just does not work? Did it ever work? Are there any conditions in which it could or should work? It tried to create the archive, but it could not find the files to add to the archive so it ended up creating an empty script.dat. Hummm. So, it could not find the files.

Maybe it is an issue with the paths. Handling paths correctly is actually oddly difficult for developers. The command prompt is also not in the same location as the tool or the script, so I am asking the tool to handle complicated paths correctly. There is even some unicode, spaces and brackets (), in the path which is a sure-fire way to mess up all software that was not written with great care. Was this software written with great care? Let's find out.

Let's get rid of all of those sources of potential problems.
1. copy igtool.exe to the subfolder that has the "script" folder
2. change the current folder of the command prompt to that folder too

That should make it easier for the igtool.exe software to find the paths. If that does not work, then perhaps copying it inside the script folder might be needed. Let's run the command again.

Code:
C:\Users\User>cd C:\Users\User\Desktop\OrangePekoe\緊縛王子(death note同人ゲーム)\extracts\extracts_from_tool

C:\Users\User\Desktop\OrangePekoe\緊縛王子(death note同人ゲーム)\extracts\extracts_from_tool>igtool.exe -c script script.dat

[-] 001_1.s                          offset[000004f0] size[00003886]
[-] 002_1.s                          offset[00003d76] size[00001856]
[-] 003_1.s                          offset[000055cc] size[0000137d]
[-] 004_1.s                          offset[00006949] size[00003607]
[-] 005_2.s                          offset[00009f50] size[000016d4]
[-] 006_2.s                          offset[0000b624] size[00001929]
[-] 007_2.s                          offset[0000cf4d] size[000015f7]
[-] 008_2.s                          offset[0000e544] size[000031cb]
[-] 009_2.s                          offset[0001170f] size[00000f2f]
[-] 010_2.s                          offset[0001263e] size[00001039]
[-] 011_3.s                          offset[00013677] size[0000244e]
[-] 012a_3.s                         offset[00015ac5] size[00001b4d]
[-] 012b_3.s                         offset[00017612] size[00002730]
[-] 013_4.s                          offset[00019d42] size[0000166a]
[-] 014_4.s                          offset[0001b3ac] size[000010d8]
[-] 015_4.s                          offset[0001c484] size[00002b0f]
[-] 016_4.s                          offset[0001ef93] size[00001bec]
[-] 017_5.s                          offset[00020b7f] size[00002746]
[-] 018_5.s                          offset[000232c5] size[00000b5e]
[-] 019_5.s                          offset[00023e23] size[00000f0b]
[-] 020_5.s                          offset[00024d2e] size[00000d46]
[-] 021_5.s                          offset[00025a74] size[000040b5]
[-] 022_5.s                          offset[00029b29] size[00000ee0]
[-] 023_6.s                          offset[0002aa09] size[0000ac44]
[-] 024_7.s                          offset[0003564d] size[00001f37]
[-] start.s                          offset[00037584] size[0000000f]

Total: 26

It did something! Again! Maybe it worked this time. Could one possibly hope? It is better not to. Hope will only lead to disapointment.

Either way, since it actually found the files and it did something, that means that earlier the program could not handle file paths correctly in complicated cases. The program is poorly written after all, just as expected of a C++ application. Since C++ expects developers to implement their own path handling, there is no expectation that such a thing work actually work correctly. This is in contrast to languages that have larger standard and and third party library repositories for developers to use so they do not have to reinvent the wheel as much as C++.

Regardless, let's try the created script.dat file anyway.

Create a backup of the original script.dat file in the likely case everything goes wrong by moving it to backups\script.dat
Copy the new script.dat to the game directory.
Then start the game using a JPN locale emulator or region set to locale.
After taking forever to load due to forced waiting timeouts, the finally loads the script and does not crash, unlike the .dat archives created by Garbro.

Okay, so that proves it is possible to unpack and pack the contents in such a way that the game can read them. Next is making adjustments to the *.s files.

Does igscript.exe need to be moved too? Well, let's not risk it by not moving the file. This developer already proved they cannot handle complicated paths, so just move it ahead of time to possibly save some time troubleshooting the same problem as before.

Code:
C:\Users\User\Desktop\OrangePekoe\緊縛王子(death note同人ゲーム)\extracts\extracts_from_tool>igscript.exe
igscript v2.3 by 7k

usage:  Parsing  Mode: igscript.exe -p input.s output.txt
        Creation Mode: igscript.exe -c input.s input.txt output.s
  Note: When dealing with "CureGirl" and "Furifure 2", add an
        opt tag '-x' like this: igscript.exe -x -p input.s output.txt
So the syntax is igscript.exe -p input.s output.txt .

Code:
>igscript.exe -p "script\001_1.s" 001_1.s.txt

Afte opening 001_1.s.txt in Notepad++, it looks like a proper shift-jis encoded script.

Code:
#月
「はあ……」
諦めにも近い吐息が洩れた。
竜崎の長い指。
骨ばった細い指が、まるで蜘蛛のように胸元を伝い下りていく。
表面をただ、なぞっているだけの軽い愛撫。
気まぐれに突起をかすめては、氷上を踊るかのような動きで僕を翻弄する。
自分が愉しみたいだけの愛撫。
─────イライラする。
#月
「……吐きそうだ…」
少しの間を置いてから竜崎は。
#L
「大丈夫ですか?」
掛ける言葉とは裏腹に、大して心配してそうもない声音で彼は言った。
僕のすぐ耳元をくすぐる、その声。
#L
「…少し、休みますか?」
#月
「……休んだ後……どうせまた続けるんだろう」
吐き捨てるように言ってやった。
#L
「はい。その通りです」

Hummmm. Maybe the '# 月' and '#L' are the name plates and the stuff they say comes after that? Considering this is a DeathNote fanfic game, 'L' is probably L, a character from Death Note. What is 月? Maybe Light or Yagami? japanese-names.org has some info but apparently it means Moon/Month/Monday, not Light/Hikari/Yagami. Well, whatever. Not my problem. Japanese names are weird anyway.

Moving on, is there any narration not linked to the speakers? How is the speaker box cleared? There does not seem to be any syntax for it in the script. Maybe the tool removed it and it would be necessary to play the game to figure it out? That would be annoying. Well, whatever. Let's just translate the text and see if packing works or not. Dumping the first few lines in my Sugoi repack outputs this.

Code:
「Haah...」
A sigh close to resignation escaped my lips.
Ryuzaki's long fingers.
Her bony, slender fingers ran down her chest like a spider's
It's just a light caress that's tracing the surface.
On a whim, she grazed the protrusions and toyed with me with her movements like she was dancing on ice.
I just caress her like I'm having fun.
<unk>I'm irritated.

That <unk> probably refers to all the dashes. The NMT model has no idea how to translate that so it just left it as <unk> which is short for "unknown." There are also a lot of references to female characters. "she" "her". This game is BL I think? So that is unlikely to be accurate. Translation accuracy is not the problem we are trying to solve right now. Moving on.

Next step is to dump the translated lines in the 001_1.s.txt file replacing the original untranslated lines. Remember to create a backup of the 001_1.s.txt file.
For my own OCD, I am also fixing fix the <unk> with dashes from the original text.
After fixing the dashes, save the file with ctrl+S.

That leaves repackaging the changes as the next step. Is this incredibly complicated procedure likely to work using software that cannot even handle paths correctly? Let's not think about it and just see what happens.

Code:
>igscript.exe -c script\001_1.s 001_1.s.txt 001_1.s

Opening the output 001_1.s file, it looks like there is some English text in it. Good. The tool did something.
Then it is time to move 001_1.s into the script folder replacing the existing script.
It is a good idea to create a backup of the script folder in case it needs to be reverted later. Goodbye original script! I will need you again shortly I assume. Temporary. Such is life.

Anyway, repackage the files using igtool.exe.

Code:
igtool.exe -c script script.dat

Next, it's time to move script.dat into the game directory overriding the one already there.
Start the game with a JPN locale emulator.
And this happens.

0.jpg

Okay, progress. That's something at least. It does load the thing, but it mess up all the spaces. Hummm. It messes up the spaces. Spaces... Does it mess up the spaces in the original Japanese sentences? Well, Japanese sentences do not have spaces, so that does not apply. Okay... well back to square zero.

Humm. It also seems to freeze a lot. If it tries to output a sentence with normal spaces, and focus for the program is lost, then it will just freeze the program and require a force-quit. The original game did not freeze when loosing focus, so this is a patch-related issue, not necessarily just a game developer is writing their software on a lousy game engine issue.

Maybe the engine just does not like spaces? That is clearly the issue since it is literally removing them all. Well, if it is removing them anyway, there is no point in having them. Might as well remove them all! That might fix the freezing issue.

But English is sort of hard to read without spaces. What is an alternative to a space that can be used in its place? How about a space? Not a normal space though. Those are all broken when used in dialogue. But what about a full-width Japanese space? The \u3000 character ' '. C

Open up Notepad++,
select a space,
ctrl + F,
Search and Replace,
Replace with ' '.
Selection only checkbox checked.
Select the parts with the translation only.
Replace all.

This is what it looks like after replacing all the half-width spaces with full-width spaces.

Code:
#月
"Haah..."
A sigh close to resignation escaped my lips.
Ryuzaki's long fingers.
Her bony, slender fingers ran down her chest like a spider's
It's just a light caress that's tracing the surface.
On a whim, she grazed the protrusions and toyed with me with her movements like she was dancing on ice.
I just caress her like I'm having fun.
─────I'm irritated.
#月
「……吐きそうだ…」
少しの間を置いてから竜崎は。
#L
「大丈夫ですか?」
掛ける言葉とは裏腹に、大して心配してそうもない声音で彼は言った。
僕のすぐ耳元をくすぐる、その声。
#L
「…少し、休みますか?」

- Replace the broken script with the original from the backup.
- Repack the changes into a new script.
- Replace the script with the new script.
- Repackage the changes into a .dat
- Copy back to the game directory.
- Run the game with a JPN locale emulator and this gets output.

1.jpg

Okay. That is enough for now. That is the proof of concept for the non-image workflow. Images should also work with the patch tool. It also does not cover translating the textual UI elements, but that is the core workflow for the main dialogue which is the bulk of the work when translating titles.

The next things to do are to:
- Extract all of the scripts.
- Translate all of the contents of all of the scripts.
- Reinsert the translated text back into the scripts using full-width spaces,' ',
- Generate new *.s files based upon the *.s.txt files.
- Repackage the updated *.s files into a script.dat file.
- Play the game from start to finish with the patch to confirm there are no bugs.
- Host the patch somewhere.
- Create a VNDB entry linking to only the patch.
- Make a thread on anime-sharing's releases or mini-releases to let people know there is a new translated game out. Since this is a BL game, please make sure it is tagged as such.
 
Last edited:
  • Love
Reactions: Eir and Vice
It will be a while before I can work on this

Thank you for everything Entai, even the obake no oujo vn, that I requested a code help for and doing all this even after you became mod

Congratz btw for making this section lively
 
  • Like
Reactions: Eir
Thank you so much for detailed (and very easy to understand) tutorial <3, are you planning on making more tutorials like this? Because I would be very interested (especially if they are related to extracting and repacking scripts from otome and BL games)
 
  • Love
Reactions: Vice
It will be a while before I can work on this

Thank you for everything Entai, even the obake no oujo vn, that I requested a code help for and doing all this even after you became mod

Congratz btw for making this section lively
Thank you so much for detailed (and very easy to understand) tutorial <3, are you planning on making more tutorials like this? Because I would be very interested (especially if they are related to extracting and repacking scripts from otome and BL games)
You are both welcome.

I am planning on creating a writeup for any VN I work on from now on in order to clear my backlog and document stuff. I am also planning a more general Translation FAQ that is half-finished right now.

Let me know if there are any other VNs that need this treatment. I cannot promise a full writeup, but I may be able to point you in the right direction. General requests of that nature should be posted in the Translation Discussions section with the [Request] prefix, but you can also PM me.
 
  • Love
Reactions: Eir and Vice
Thanks, now i understand more about how to unpack an repack dat file scripts.
 

Users who are viewing this thread

Latest profile posts

SUNWIN - Thế giới game tài xỉu đổi thưởng số 1 Asia ra đời năm 2016, đã nhanh chóng khẳng định vị thế là cổng game bài đổi thưởng hàng đầu tại Việt Nam.
Website: https://sunwin.net.im/
Glaymez wrote on Otokonoko's profile.
Hello, I made a request a month and half ago for reuploading the game: [160226] [Rave'N ] 牝贄狩 淫虐のアーケード街 (thank you for that!)

But during the extraction from the zip folders, extraction fails, stating that it needs ''GAME-879392.part4'', but I only have up to part3, and the re-upload did not include a part 4. Is there a way to fix that?
supstring wrote on Ryzen111's profile.
Could you re-upload this, please?
RJ01097242_v23.12.31
tolate wrote on Shine's profile.
これの最新バージョンを投稿していただけますか? v2.03-2.05
✨Shine✨[240209][May] 八星帝 (Ver24.09.21) [RJ01004084]