Saturday 9 May 2015

Beta v4.0c Released

So, the v4.0c beta was released. Major highlights from v4.0b:
  1. New Unmarshall script - hopefully the end of all compatibility issues, ever.
  2. GUI/CLI modes are now separate packages. In addition, the CLI mode now works. 
  3. Release channels - before, beta versions had no update notifications. Now they do.
  4. Some hidden functionality that will be exposed in the near future.
  5. Major tidying up of the source code. Not much of a highlight for most, sure, but handy for me. 
On websites and stuff: I'm seriously considering moving all RPGMaker related stuff off of this blog, and onto the main RPGMaker website, once its redesign is finished. The Nikola engine supports all kinds of neat stuff for this, so there won't be a loss of functionality, and it should result in a nicer blog with a nicer comment system. Not sure if I'll keep this one up or use it for other purposes or something, but unless there's a massive outpouring of support for a Blogspot blog, then that's probably what's going to happen.

EDIT: I've had reports that Ruby 2.1 fails to work on 32-bit Windows XP. As Ruby 2.1 is more-or-less required for this version of RPGMaker Trans, that means I have to declare Windows XP unsupported. Anyone on WinXP? Please upgrade Windows. There's a lot of good reasons to do so.

Saturday 2 May 2015

Hopefully final progress report on v4.0c, playing around with new site

So, hopefully this is the final progress report for v4.0c.

What's changed? A handful of things:
  1. GUI and CLI executables will be in separate packages. cx_freeze doesn't have any real way of having the two modes in the same package (or indeed, the same executable), so it's going to be 2 packages available for download. On the plus side, having to do this force me to sort out some long-standing source code organisational issues, and then implement hacks around Python bugs to get it to work on Windows...
  2. Changing the way data files are loaded - again: My previous solution was to load a shim RPGMaker compatibility layer and then load the scripts of the game into Ruby so that Ruby could unmarshal all the classes. This turned out to be a bad move because many games do processing on script load (rather than on game start), and so many games would crash the Ruby interpreter during this stage. The new approach is something I implemented nicknamed "unmarshall", and basically uses the errors generated when failing to unmarshal something to generate a shim to enable unmarshalling... if that makes any sense.
  3. Move from Ruby 1.9 to Ruby 2.1: because one thing I found out during implementing unmarshall is that under certain circumstances Ruby version < 2.1 will quite happily unmarshal a data structure to completely the wrong class, without even a hint on an error message.
  4. Hidden support for translating script labels: My test case game requires this. However, to stop labels polluting the majority of patches which don't require it, it's disabled by default. And has no option to enable it - although there will be one, probably in the next semi-major version.
Things that need to happen before v4.0 final:
  1. More testing
  2. UI bug when unpacking a game (progress bar stuck at 100% during patching) 
  3. Release channels
And the final thing in this post... It turns out that I hate HTML. Unfortunately, that's what my website is written in. I'm currently experimenting on a replacement website, which will be powered either by Nikola or Urubu. I'm not sure what I'll end up with, but whatever it is there will be pretty big changes on the website in the near future.