URR Finale Update XIV

This week has been less full than last week so I’ve been able to devote a lot of time to getting URR ready. I am now pursuing two paths, and I’ve made progress on both. Whichever one works out first will be the one I use to release URR 0.8.

OPTION ONE: Get it working in Python 2.7.

I’ve sent along the files and appropriate information to friends who really know what they’re doing, and we’ll see whether they are able to figure it out. The problem is that Python 2.7 is so out of date, the old libtcod version I was using is so out of date, and py2exe is so out of date… that it’s tricky. The executable does work on my system, though, but that’s only because I have Python installed. Others have reported that it works for them if they have Python installed, and one or two have reported it works with some other Win 10 packages installed – but basically I haven’t been able to get it working on most Win 10 systems. This is what the team are currently trying to help me out on, and I’m also trying some more things in this direction too.

OPTION TWO: Get it working in Python 3.7.

This has been the main thing I’ve been doing this week – and this has been a big, big task. Although I used “2to3” to convert the code to Python 3, it didn’t really fully convert everything, and actually introduced some new errors that hadn’t been there in the first place. To my horror I discovered a number of functions I used in Python 2.7 – such as iteritems(), and the standard division operator /, have been changed, but changed just enough that I couldn’t do a simple Ctrl+F to find and replace them all, but instead they all – especially the iteritems() function, which cycle through everything in a dictionary – had to be altered by hand. This led to a period of almost unimaginable agony deeply rewarding programming as I went through URR’s code replacing older instructions with newer ones. Some of these weren’t so bad, but some had entirely new parameters in the middle of them, and so I had to throw together some quick code to convert my old code to new code where required (this was far faster than replacing thousands of functions manually). I then discovered I also had to update libtcod – the main roguelike library – but a lot has changed since the version I’d been using (which I now discover is, ahem, several years out of date) and I’m still working through the changes. (This is not criticism of the guys maintaining libtcod, just an observation about what happens when you don’t update something for years). Sadly the very old version of libtcod simply doesn’t work with Python 3, hence why I’m now updating everything. But yes: this is a big task, but I’ve worked on it every day, and most of URR is now working fine in Python 3 + libtcod 11, rather than Python 2.7 + libtcod… 1.5. Nevertheless, after a week of work URR in Python 3.7 has gone from “doesn’t even load” to “basically everything works but there are some remaining crashes that need to be resolved”. I’m getting there.

(And irrespective of this release, if we’re being honest: it is about time I updated to Python 3. It’s a painful process but I’m sure it’ll be for the best in the long run, regardless of whether it’s the P2 or P3 version that gets released now).

So my basic plan is this: I will continue converting URR to Python 3 and the most recent version of libtcod (which is a sadly huge task) while others (and I) try to get the executable working in Python 2.7. Whichever concludes first will be the one we go with. But I just want to reassure everyone: I am working flat out to get this done. It pains me so much that this final hurdle has unexpectedly presented itself (especially when 0.8 is done and works!), but I’m trying every possible path to resolve the problem. Again: updates will continue until release, so I’ll be back next weekend with more progress on one, or both, of these paths to release. Thank you all – see you all soon!