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.

So, there's a lot of buzz going around about RPGMaker MV, the new thing from Enterbrain. I've got to preface this with saying that there's a lot of unknowns about RPGMaker MV, so I can't really say at the moment if it will be supported. I'd certainly like too, so here's a breakdown of the things I need to find out before I can say if it's possible.

• How are games packed? Due to the requirement of running on multiple disparate systems (Windows/Mac/iOS/Android) and the fact that JavaScript is the scripting language, I'm actually guessing that RPGMaker MV is some kind of HTML5 export engine. In this case, I don't think the game would be packed, or at least not in a complex manner. However, that's entirely speculation.
• How are events serialised? In Ruby based engines, events were serialised as Marshalled Ruby objects, which is not a particularly great way of doing things (Marshall formats are universally not recommended for this kind of use, for a number of reasons). I'm hopeful that RPGMaker MV will use JSON, and not some obscure binary format, but we shall see.
• Scripts? Javascript is probably much easier for me to handle than Ruby ever was; there's a handful of Python Javascript tokenisers around, so I'll be looking at those to see if I can use one of them. Alternatively, there are a lot of C Javascript tokenisers, and I should be able to interface to one of those with CFFI. Still, something that needs work.
• Quality of Scripts? This is a big one. Javascript is normally handled in a very forgiving way with regard to syntax errors etc. Given that I've seen some absolute travesties in Ruby based games (e.g. unnamed scripts), I'm a little concerned with the quality of scripts that will be produced by the amateur coders who typically use RPGMaker; if the scripts aren't fully correct, it will cause issues for parsing them. And that would be highly annoying.

Before promising anything as to supporting RPGMaker MV or when, I'd like to get some info on these factors. So I wouldn't be too hopeful that RPGMaker MV support will be a quick fix. At the very least, it's adapting RPGMaker Trans for a completely different engine, and so is much more like the jump from 2k to VX. And that took years. While I've got a little more time now, I'm not that hopeful because I'm still only a one-man team on this.

Anyone up for helping when it comes out?

So it turns out that RPGMaker Trans v4.2 had a pretty big bug, which managed to squeak through testing because I was mainly focussing on XP compatibility. For those interested, the bug turned out to be an offset being off by one, causing 101 commands (which initialise a dialogue window) not to be copied correctly, resulting in no dialogue in translated games. This has now been fixed.

Apologies for any inconvenience anyone!

I've had a report that there's a rather large bug in v4.2. I've not personally seen this bug in my testing, so I'm a little confused by it.

In any case, until I can get to the bottom of this, I've put v4.1 back up. Sorry for any inconvenience.

As stated, it's been released. This fixes the following:

• a bug due to the fact that Ruby defines some global variables which do not conform to the normal rules for variable naming, thus causing Ruby parser to enter a slightly less than infinite loop.
• a bug due to not testing patching XP games properly where for each dialogue, the first line of the dialogue was missing

This is a beta due to me making some quite invasive changes for the 2nd fix, and me not having enough time to properly test this version.

So, RPGMaker Trans v4.1 is released. The main thing here is that support for XP and VX Ace games is finally available in a non-beta release. Also, it turns out that version 3's VX support was pretty wonky, and this should be much improved now.

There's also a new site. This site unifies the old blog and the project website, which is handy for me (less stuff to update) and handy for anyone using it (more ability to ignore irrelevant things). The new site also brings documentation up-to-date, final adds proper documentation for the GUI, and comments are now powered by Disqus (which is a better solution than Blogger comments). What next for the old blog? Not sure. It might get updated with some stuff, but that seems unlikely. In any case, anyone subscribing to RSS etc should update their bookmarks.

What's next for RPGMaker Trans? Well, I still need to get DocStrings working in the Ruby Parser. I had thought that these were fairly obscure and people didn't use them much. However, when investigating a different bug, a handful of games did use docstrings... and so I should probably try to support them.

In addition, I'm looking at some pretty big changes to the backend of RPGMaker Trans. In defence of the current backend, it works pretty well on Linux, which is where I do my testing, and given that it reuses a core infrastructure in a lot of places, it was quick for me to implement. However, it doesn't work so well on Windows - this can be seen by the amount of lagginess in the interface.

It also turns out that due to the backend being slow, my prototype C-based unpacker can't go at full speed. So I'm looking to move some of the backend stuff to a threading solution rather than the current multiprocessing-based one. This should improve how the Windows builds feel to use, as well as addressing other issues (like the number of processes RPGMaker Trans spawns).

Finally, there's a very good case to allow bits of Ruby to be stored in a patch and then executed. This would allow customisation of the matchers/patchers that RPGMaker Trans is using. This is somewhat necessary due to the wide variety of custom scripts available - even in my demo game, there are problems because the standard method of selecting a portrait has been overridden. Allowing some code for customising the matchers/patchers would be able to fix this. While I'm on the subject of Ruby code, it may also be nice to be able to wholesale replace parts of the code. The main reason for this would be to do things like add a command to change the font used, but I'm unsure as to how I'd go about this.