binaryfail

You don't need to convert the images back into the .gr format. Just convert the images as .bmp and put them in the CG folder.

If you're feeling comfortable running stuff from a terminal, you should definitely try playing around with Wine 3.0 stable. Out of the games on your list, I have the second and third game and managed to get them running on High Sierra. Yoake op movie and Yoake in-game Yuuki Yuuna Some general comments I'll mention: The latest alpharomdie has some trouble on wine 3.0 (or mac ... I'm not sure), so try the 2012 version of it which works here. Yoake needs this file to avoid the reg.exe error. If you have the translation patch installed, overwrite their existing one with this file. Make sure you install the DirectX (June 2010) runtimes for newer games Make sure you have the msgothic.ttc copied to your wine's c:\windows\Fonts folder For video playback, you need the quartz+devenum+amstream DLL files from the DirectX (Feb 2010) redist package, registered in wine's system32 folder. Additional codecs using wmp9 and ffdshow is often helpful.

Try using this ITH build here. It should resolve the attach error on recent versions of Win 8/10.

I tried making a workaround for this issue. Can you test this module and see if that fixes it?

For the first part... the answer is a bit of yes and no, depending on how you interpret the question. In one sense, a patch does work in the way you describe it: the engine focuses on the translation inside a patch file instead, and the originally-installed files remain untouched. But on the other hand, the translation is made by modifying a copy of the script -- replacing the Japanese text and putting English text in its place. The resulting script is packaged into the patch file. Side-note: if the scripts are 100% text based, the translation team might choose to comment out the original text instead of removing it from modified script. This makes it convenient for TLC at the expense of larger file sizes if the comments remain in the final product. For the second part... From what I understand, NScripter scripts are written as a bunch of individual files just like any sane project would do. During the packaging process, NScripter will combine all the script files into one big encrypted text file. Everything from the source scripts should still be there, it's just one big blob now. The exe you mentioned is just an installer, and yes, user-friendliness is often the main motivator for providing an installer instead of a zip file. Looking professional is just a bonus, in my opinion. Installers are beneficial to users who, for example, lack file management skills and want to have an easy way to install or uninstall a patch. There are TL projects that have shipped their patches as installers, but most projects I've seen tend not to... especially if it only takes 2 seconds to drop a file into the game folder.

Usually, a "mod" has the connotation of being unofficial. And depending on the context, the terms "mod" and "patch" can be used interchangeably. In either case, the end result is a change in the game data. Indeed, the delivery mechanisms for a patch/mod/update/add-on is dependent on the engine and the nature of the patch itself. Typical methods usually boil down to one of these: -Install a patch archive -Install updated raw files (script/image/audio) -Overwrite an existing game archive -Delta patch Many engines can detect and use new packages which deliver patched content. They might have obvious filenames like patch.xxx and updateXX.yyy, or something like dataXXXX.zzz to look consistent with existing files. During gameplay, the engine will give precedence to files in the patch archive -- it accesses them first if they exist, otherwise it will default to reading the originally shipped data. Some games do patches just by adding or replacing raw files in the game folder. I think engines allow for this as a development feature (avoids needing to rebuild archives to test new changes) which also doubles as a patching mechanism. Games that do this might not even use archives at all. And then there are engines that don't have a built-in way to load patches, meaning the original archives must be overwritten in order to serve patched content. Updates for VNs usually focus on the scripts, so a new script package will be small enough for the user to download and replace outright. But for games where large archives need to be updated/overwritten, downloading the whole thing again would be very inconvenient. An alternative method is called delta patching, where an patched file is constructed from an existing older version using a delta (before/after difference) file. After the new file is created, the old one can be deleted -- effectively overwriting the original copy. Aside from VNs, delta patching can be seen in areas like fan-tl'd console games, hotfixes for fansubbed anime, and of course, game updates on Steam. I feel like my response answered the "what" but not the "why" part of the question, so there's probably more stuff to talk about.

You shouldn't add or remove lines in the JP script, otherwise the lines will fall out of sync with the rest of the script; voices and images would no longer match up with the text. Instead, you'll need to merge or adapt the translated text to fit within the confines of the original JP line.

The first line is there for reference. The second line is what you'll want to translate/edit, and that line will be filtered for insertion.

@Infernoplex The codepage conversion warning probably means ahdprc is using cp936. You'll need to change it to 932 by editing the tool's source code and compile it again. The number shows up twice in the tool code. Character's names in this game are prefixed with %LF instead of %LC, so ahdprc wasn't picking them up. Again, that'll require editing the tool and recompiling. wpscrpt.cpp, line 50: change 'C' to 'F' wpscrpt.cpp, line 82: change "%LC" to "%LF" When the text is extracted, the character name will appear next to the line number within the script.

After the initial extraction from the ws2, the tool gives you a text file and a bin file. In most cases, you can leave the bin file alone. Here's a how-to if you want it.

The first one you describe might be this one. The second one, I'm guessing, is this one.

Indeed. Regardless of how you manage your text file, the final output must be encoded with SJIS for the engine to read it correctly.

Using ahdprc does work with Cyrillic in SJIS. There were 2 instances of "936" in wpscrpt.cpp that I saw. Did you change both of those to 932?

Here is a .bat file to run the compile. Should've had a makefile instead... Save this .bat and run it in the "src" folder. Their readme says to use MinGW with gcc 4.7.1 which I will agree with. The tool won't run correctly if it's compiled with newer gcc versions. set path=C:\MinGW\bin mkdir obj del obj\*.o for %%f in (*.cpp) do g++ -std=c++11 -O2 -fstack-check -fbounds-check -fstack-protector-all -Ilib -c %%f -o obj\%%~nf.o g++ -s -o ahdprc.exe obj\*.o -static -Llib -lprincess -lssp pause

My compiler isn't set up for this at the moment, so no builds today. But on that line you linked, change 936 to 932. That's the codepage for SJIS.

This tool looks like a decompiler. I know opcode 0x06 is an unconditional jmp, whereas 0x02 looks like conditional jmp. Much of my comment is true with regards to the current Will engine, except for part about monospaced text. The current Will engine does have support proportional fonts. I made a small dll file to do a few things like overriding the font at runtime. In the Russian KoiRizo patch, I used the Tahoma font instead of MS UI Gothic.

Here is a small follow-up. The steps are a bit shorter due to time constraints.

I like to look for GetGlyphOutline or CreateFont since those are usually where the interesting stuff is found. On this engine, following the width arg in CreateFontIndirect was helpful in finding where the text's properties originated. Right now, the example code only works on text when it's fading into view. I will need to keep looking for the parts which handle the instantly-displayed text. That will take me a while to figure out. If you want to test a slightly wider value for spacing, try 20 40 instead of 1C 40.

In this case, patching the engine means you would need to dig through the engine's code with a debugger and edit pieces of code that handle the text output. The example I showed is just a proof-of-concept. More work is needed in other areas like the backlog, and trying to fix it is more troublesome than I expected right now. I don't have too much free time to look at this. Since you asked for some steps to get the result, I'll write them below.

Cyrillic symbols should work if you are using their Shift-JIS variants. Let's assume that was already done. This engine seems to only support monospaced text, so you need to use a font with fixed-width characters. Since the Cyrillic glyphs are considered full-width under Shift-JIS, the engine uses double-width spacing which brings in extra (unwanted) spacing between each letter. The engine will need a bit of patching to get the spacing to an acceptable amount. After that is all done, this is what it would look like with the default font (MS Gothic) for Cyrillic text.

The OP movie happens at the end of day 4/11.

The logo movie is the very first thing you see when game is opened. If the logo is not showing up, it's possible the game had trouble initializing the video renderer and silently skips the movie. I've only seen this happen on some systems running Windows 8 and 10. Here's a workaround you could try: Go into the game's "savedata" folder (might be located under "Documents\tone work's" if you installed the game) Open the file called "system.ini" Look for the line that says #MOVIE_TYPE = 1 and change the value to 0.

Tried it on my computer which uses a 1080p screen. It looks okay in this screenshot. I also tested a laptop that has a native screen resolution of 1366x768, no issues there either. This may be an obvious one, but is your graphics driver updated?

Have you tried picking 1280x720 as your fullscreen resolution?

You haven't installed everything from the patch... Your screenshot shows the Scene.pck file is 16MB, but the translated file should be 23MB. Be sure to extract everything from the "PATCH ONLY" part of the translation package into the game's folder, and overwrite any file that gets prompted.