On the trend of binary only patches

Something I'm noticing much more often now is a trend towards binary only patches (i.e. a games Data folder) for games translated using RPGMaker Trans. While I can kind of understand this, given that binary only patches were the norm for a while before RPGMaker Trans, it does irk me somewhat. The main reason is that these patches subvert one of the primary benefits of RPGMaker Trans - specifically, that the patch is applicable to multiple versions of a target game. It also makes it much harder for a translation to continue, should a translator go AWOL or dump a project.

Hence I've been conducting some experiments on 'exfiltrating' the RPGMaker Trans patch within a binary only patch. This is technically very straightforward; it turns out that arbitrary data can be embedded into a Scripts file with minimal effort. Of course, modifying the translated game with RPGMaker would remove the exfiltrated patch, but I'm not trying to be completely perfect in the exfiltration process. This is doubly true given a) this news post and b) the fact that RPGMaker Trans is open source, and so even if I tried to keep this hidden, people could still see it in the source code. (Although I did think about how it could be made more resilient, as a thought exercise. My idea for that would be interspersing b64 encoded comments throughout all event pages; this would presumably be too much effort to remove.)

In any case, the point of these 'exfiltrated' patches is that RPGMaker Trans will, in future, be able to recover a patch from a translated game. Hence even if someone distributes a game as a binary only patch, it will be possible to recover the RPGMaker Trans patch for use on a newer version, or for corrections, additional translations, whatever. It could also be handy in cases where the RPGMaker Trans patch gets lost somehow (e.g. computer failure).

To finish this rambling post on a future feature, a quick imaginary Q&A session:

When will this feature be ready?

It's still in early development, so no idea. At the moment, most of the code to generate and insert the minpatch is there, but no code is present for actually doing the patch recovery.

Couldn't this be done already?

Not exactly. RPGMaker Trans can change the structure of a game quite significantly, and so simply matching contexts between two patches won't be sufficient to recover a patch. If this approach were tried, I'd imagine it would only be possible to reliably recover non-dialogue portions of a translation, as the contexts on dialogues are sensitive to the number of newlines in the text. There may be some interesting heureustics that could recover more, but frankly I think this is more effort than it's worth.

Doesn't this increase the translated games size?

A little bit. The minpatch which is embedded is pretty small - it's a very minimal JSON file, compressed with LZMA. In the patches I've done (which are fairly extensive), it adds a little over 300kB to the games size. For partial/incomplete translations, this will be much lower. It should be noted that other approaches I've considered would add more to the size of the game, due to not being able to take full advantage of LZMA compression and/or have the undesirable requirement of needing the untranslated game to recover a patch (which may be difficult to obtain in the case of a version bump).

Are you sure that this is compatible with everything?

Pretty certain. The Script loader is one of the things that Scripts can't modify, and it only cares about the first three entries of each item in the Scripts list. So this should be fully compatible with everything.

I don't like this idea! I want to keep my patches private!

Well, tough. RPGMaker Trans is a tool specifically designed so that end-users can apply a patch onto multiple versions of game - that's how I designed it, and that's the principles that I'll stick to when developing it. If Translators use it to develop patches in a way which goes against this principle, then I feel that's an abuse of RPGMaker Trans. Hence I'll try to develop a countermeasure for this behaviour.

Anyone who really strongly disagrees is advised to fork the project, or hack the source to disable the feature when it lands, or whatever they feel is appropriate. This is open source software, predominantly written in an easy to learn language, so I really can't force this feature on the unwilling. But personally, I don't see any drawback to translators. If anything, empowering users to be able to fix issues after you've moved on from a project should be seen as a benefit.