RPGMaker Trans v5 Status

Macros

RPGMaker Trans v5 will support macros. For those who know Latex, I'm taking a lot of inspiration from Latex's style, although RPGMaker Trans's macros will be a lot more limited. The basic idea is that the macros will let you set bits of RPGMaker Trans's state directly (e.g. \newpage to start a new dialogue page) or avoid typing tricky code (e.g. \red{This text is red} instead of setting the colour codes manually, or even much more basic stuff like \star mapped to the unicode character for star).

Speed

As has been mentioned before, RPGMaker Trans will be much speedier. The cause of problems on Windows before was socket based IPC being slow, and RPGMaker Trans doing a lot of socket based IPC. To fix this I've moved to a pure Python Ruby marshal format implementation to handle reading/writing/patching files, and sqllite databases for storing translation data. I've also parallelised the reading/writing of patch files, so big projects will load quicker.

Obviously the proof will be once I do end-to-end tests on Windows, but I've seen big speedups of each component on my Linux dev machine. I'm quietly confident on this one.

More Strings

RPGMaker Trans v5 has the capability to customise what it translates. By default it will translate the normal fields you'd expect, but it is trivial to add tell it to add other things to the patch. Currently these are controlled by regular expressions which match against the context of the string, but I will be adding support for glob-like selection. Hence if you want to translate, for example, comment fields, adding the rule "*/comment" would suffice. If you wanted to only translate comments on items, then "Items/*/comment" would be the correct way of doing it.

Reliability

RPGMaker Trans has always had some issues with reliability, especially when dealing with malformed files. v5 should address this; it's much harder to crash, and handles many more error cases. Further, the script parser has been rewritten to use the Pygments library, and so should be much more reliable than the buggy mess I created. There's also...

Patch Formats

RPGMaker Trans v5 will support 3 patch formats; a new variant of the textual format that's already familiar to everyone, sqllite databases which should be useful for people seeking to make tools that interface with RPGMaker Trans, and a single file "distribution" patch. As the name implies, the single file patch is designed for people to use when distributing their patches; it will be automatically compressed and should be somewhat faster to use than the textual format patches. It will also provide a degree of obfuscation for people who are intensely protective of their translation patches, but it wouldn't be too hard to convert a distribution patch back to the original format.

There's also a new v4 of the textural patch format. This is to enable support for macros, but also to correct what I feel is one major oversight of the original patch format. In the original patch format, strings extracted from scripts kept their quotation marks in the patch; this led to an easy way of breaking things (if a translator messed up Ruby escape codes like newline) and violated the Do not repeat yourself principle of RPGMaker Trans patching (a script string was always different from a dialogue string). There was a reason I did it this way; the original script parser was designed to allow modification of variables interpolated into a string, although in practice it very rarely detected this. The new script parser doesn't support this, and so there is no reason to keep it in place. Hence RPGMaker Trans will now now include the dialogue quotes, and just handle any necessary conversion to Ruby strings as needed.

In-place Patching

Since version 1, RPGMaker Trans has worked on the principle of having three inputs/outputs: a source game, a patch folder and a target directory. RPGMaker Trans v5 will still work in this way, if you want that. However, it will be promoting an in-place version as the default. Here the patch is located inside the source games folder (either created by RPGMaker Trans or placed there by a user), allowing RPGMaker Trans to automatically find the patch. Then RPGMaker Trans will patch the game in-place rather instead of creating a translated copy - backing up any files which are changed so that the game can be reverted/repatched as necessary. It will also have the capability to read/write RGSS archives, meaning that people don't have to unpack them if they don't want to. There's a few arguments as to why you shouldn't unpack them (spoilers/normally better to have one big file than hundreds of small ones), but supporting this is, at the least, a neat feature.

Note: When RPGMaker MV support rolls out, I will support unpacking EnigmaVirtualBox (EVB) files, but not repacking them. Unlike the RGSS archives, there's a lot of good reasons to always unpack EVB MV games - mainly due to EVB causing massively inflated memory requirements.

Patch Metadata Wizard

RPGMaker Trans has supported patch metadata for some time, although it's not a widely used feature. RPGMaker Trans v5 will update the metadata to be more formally specified and also have a metadata wizard, that will produce some metadata files on demand. This will be basic stuff; being able to set the games name, games author, logo for the project, translator, any Copyright dates, and the license of the translation. The last of these is a sort-of political/belief thing; fan-translator in particular should start specifying the licenses of their work, because this way fan-translators will have at least some legal defences in the case their work is misused (e.g. to promote piracy). Of course, all of this will be optional, so people who don't want to use it don't have to.

And now something which will annoy some people:

Ending of Windows XP Support/Vista GUI Support

I am currently planning to drop support for Windows XP completely. This is out of my hands; Python no longer supports Windows XP, and so RPGMaker Trans has to move on from XP as well - or at least if I want to be able to use features like asyncio/pathlib, which are part of my push to make this program faster and more reliable. Incidentally, given Windows XP has a tiny file cache, I'd also think that performance with the new sqllite database would be rather poor.

Windows Vista is a more complex case. I'm using Qt 5.9 for the user interface at present, which does not support Windows Vista. This means that unless there is a massive outpouring of grievances from the Windows Vista RPGMaker Trans community (which I'm not sure is a thing that exists), I will likely drop support for the GUI version on Windows Vista, but the CLI version will still work. Given the in-place patching above, it should be straightforward to use even for non-technical users; dropping the game folder on-top of the CLI executable would suffice.

Anyhow, a big post, but hopefully that brings everyone up to speed of what I'm doing, and why it's taking so long. There's a lot to do.