Request: Amuse Craft/Softpal Engine about vntranslationtools

[arcusmaximus]

I checked out the existing tools and the sample text.dat, and it looks like this file really contains just text, not code that could require jump offset changes. Did you try out the tools to verify that they really don't work?

The AyamiKaze tool should be capable of rebuilding, but looking at the source code, it uses inconsistent file names. The extraction tool (text_print.c) reads TEXT.DAT and produces TEXT_JP.txt, but the rebuilding tool (text_packet.cpp) reads sens.txt and produces ATField.DAT. So some renaming would be needed to get repacking to work (or you could just fix the file names in the source code).

To be clear, I can add support for this format to VNTextPatch even if the existing tools already work. It's just a matter of knowing whether it's enough to emulate what those existing tools do, or if more is required.

[arcusmaximus]

Support for text.dat added into VNTextPatch considering how simple the format is. Let me know if it works for your target game.

[Cosetto]

@arcusmaximus that tool by ayamikaze is outdated try his new one

[sviiseven]

So, I've tested the tool.
It extracts and appears to repack the script properly. However, after repacking the text.dat into the original data.pac using the UniPac tool developed by marcussacana, it boots properly, but once I hit "start" in the game menu, it freezes and then crashes. I've also tested the soft-patching method of just putting the text.dat into a folder in the game directory named "data", and it results in the same crash. So, I'm going to have to assume this has something to do with the repacking of the script.

I also attempted to use the python tool suggested by Cosetto in the message above, and I can't seem to get it running, but it keeps returning an error about "encoding" being an invalid keyword.

[arcusmaximus]

After getting the game and doing some analysis, it turns out that editing text.dat is indeed not enough. The file contains string IDs, so that you'd think the scenario (script.src) references messages by these IDs - but in reality, the IDs are unused, and (as you initially suspected) the scenario uses file offsets instead.

VNTextPatch now edits both script.src and text.dat to get a working translation patch. In addition, it now changes the first byte in text.dat from $ to _ to mark it as unencrypted. (If you put an unencrypted text.dat with a $ marker in the "data" folder, the game will "decrypt" it, or in other words, corrupt it.)

@Cosetto The tool you linked might also work, but relies on several assumptions/heuristics that could go wrong and produce a corrupt scenario. The new code in VNTextPatch knows about all the game's instructions and should thus be more reliable.

[sviiseven]

Sorry to revive this already closed issue. I'm unsure if it is necessary to make an entirely new issue on the matter since this still relates to the original problem. It's another problem I've encountered with the tool that has to do with the script output.

To get right to it, the current version of the tool outputs most of the lines as intended. Some lines are becoming lost in the output, which probably has something to do with the truncating implemented in v0.0.3 to remove the non-text (i.e.: the first 1044-1046 lines of a raw TEXT.DAT decoding)

Here's a brief comparison.

Personally, if this means having to do away with the truncating, I'm fine with all the non-text rows. Not that I can speak for all who will use the tool for translating a softpal VN.
Sorry again, and I hope you can make this fix!

[arcusmaximus]

The tool wasn't handling all message-related opcodes yet. Should be OK now.