Using Rant in my Python program because I’m a glutton for punishment

Over the past few months, I have been researching and developing a little procedurally generated game which will eventually be created in the Godot engine. This game will have a story that’s procedurally generated for the players. A part of this game is the dialogue, which will also be procedurally generated. To accomplish this, I set out to find a library of some kind which can create procedurally generated dialogue (or at least the dialogue that I want) and is written in my programming language of choice, Python. From the looks of it, there isn’t one, and so I had to look elsewhere. That’s when I stumbled upon something called Rant. This is billed as a library which can procedurally generate dialogue. At first I thought I had found what I was searching for. Sadly, though, it is written in  the least open source-friendly language I have ever seen: C#. This can be used on Linux (with the Mono runtime). But I’m looking for a solution where I don’t have to use a bunch of programming languages to achieve what I want.

At first, I tried making some kind of dialogue scheme that would suit my needs. I threw in some sentences of what may define the NPC, and mashed it all together. From the looks of it, though, the scheme is getting out of hand. I have several lines of dialogue, and I’m not even finished. I don’t entirely know how I’ll fit it all together, considering this is just for a simple demo of the full game. It looks like I’m going to have to get creative.

I went digging and searching around I came upon several possible ways of integrating C# code into Python code. There’s IronPython, a fully implemented version of Python in C#. The big problem with this was that it didn’t look very portable to me, as I would have to bundle the .NET libraries with the game for each platform, and that’s a royal pain the ass. Then I looked at Python.NET, which looked very promising: you can call some C# code from Python, and you can call some Python code from C#. It looked like the best of both worlds. Now, actually making it work is a bigger problem.

When I tried to use the Rant.dll assembly in my Python program, I found that I can’t do that because, well, it’s C# code, and the regular old CPython (which comes with many Linux distributions) can only import C or C++ code. Then I looked into using the clr module from Python.NET, but I couldn’t find a version built for Linux. Through a lot of hand wringing, brow beating, and code cracking, I found that I had to use the latest version of Mono (version 5.0.1) along with an unstable version of Python.NET. This one built with the suggested command: python setup.py build_ext --inplace. The built shared object library file, “clr.so”, and the “clr” module load in Python.  Heck, I was even able to load the pre-built “Rant.dll”. But this is nothing compared what I must do now: actually making some procedurally generated dialogue with Rant. And I don’t know where to begin with that.

Trying My Hand at Making a System for Procedurally Generating Stories

Last year, I got the idea of making a game where a group of friends could get together, have a game scenario generated for them, and they could start playing.  This is something called procedural generation, wherein game settings, mechanics, assets, and other components are created from an alogorthim, and a bit of randomness.  I thought I would just research this, since creating any sort of video game takes a lot of time and skill.  In this case, I was looking into a system for creating stories.

I’ve read a few things about procedurally generating stories (for instance, Tail-Spin and Minstrel) and I stumbled upon one that may be in my reach.  From a paper titled “Random Word Retrieval for Automatic Story Generation” I found out about something called ConceptNet.  This is a commonsense knowledge database for finding the relations between concepts via semantics.  So you can find one concept (like “dog”) and find corresponding concepts for it (such as “animal”).  The paper talks about the intent of making a system for using ConceptNet to find the relations between words (in a process called “Concept Correlation”) and make a story out of it.  Sadly, they haven’t yet implemented the system.  So what I’m trying to do is make something that will, uh, sort of make a story.

In the paper, they talk about how the system requires a Knowledge-Based System.  Unfortunately, this system is quite tedious and difficult to create (or so the paper says).  So I’m just trying to find the connections between words and concepts.  All that I’ve been able to do, though, is mess with the Python interface to the ConceptNet website, and maybe find some related terms.  Finding the connection between two dis-similar terms is difficult, because the concepts have many branching nodes which connect to other nodes.  Finding the right nodes which connect the two concepts would take a while, because the system would have to iterate over the nodes until they find a match.

The examples I’ve been using have been “dog” and “snow”.  So the system would have to go through each node in the “dog” concept until it found a node which connects to “snow”.  It could be any connection from “dog” -> hasA-> “nose”  -> RelatedTo-> “wet” -> PropertyOf -> “snow”.  Please note that these aren’t actual connections in ConceptNet, but something like this can be found in the database.

So I don’t know how I’m going to tackle this monster, let alone make a story out of it.

Migrating My Nextcloud Server to Another Server

When I saw that my version of Ubuntu could not be upgraded any more (due to Digital Ocean’s system), I had to migrate my Nextcloud installation (version 11.0.2) to a newer version of Ubuntu (16.04). In the documentation for Nextcloud, it details how to exactly migrate your Nextcloud installation to another Linux server, so I tried using that. Sadly, though, they left a couple of things out. So here’s my version of how I migrated my Nextcloud installation to another server.

First of all, they say to back up your data, which is what I did (to some extent). Next, I spun up a droplet which had similar specifications to my previous installation (it uses 512MB and has 20GB of storage, for instance). I made sure to put in my usual ssh key for this new droplet, as well as securing it in other ways. At first, I thought I knew how to easily do this: copy over the /var/www/nextcloud directory to the new server (which was also set up for Nextcloud), change some directory names, and it would be done. However, this was not what I found.

When I tried this method, I couldn’t access the web interface. What was worse was that I had forgotten to change the firewall configuration on the new droplet and accidently “locked” myself out. So, through some more research, I tried it again with another droplet.

This time, I copied the files using rsync, and made sure that I used the proper switches (I used the “-a” and “-t” switches, in order to archive the files, as well as save the timestamps). I saved the files to a new directory on the server, and made sure to back up the old files. I thought that this time I had fixed the issue. But Fate can be cruel.

Even though I had copied over the files in the “correct” fashion, the server still wasn’t accessible from the web. Looking at the /var/log/apache2/error.log file, I found that the webserver couldn’t start due to Nextcloud not be able to read the database. After researching the problem more, I learned that the data can’t be just “copied” over; rather the data has to be copied, and the database has to be imported. So, after scrapping that droplet (I had changed it too much already), I spun up a new droplet, and tried this whole thing all over again.

First, I put the server into “maintenance mode” and stopped the Apache server. Then I extracted the data from the database (via the command mysql -u ownCloud -p password ownCloud > /tmp/dump.sql), copied that over to the new server, and imported it into the new database. For importing the new database, I “dropped” the old database, created a new one, and finally imported the data with the command mysql -u nextcloud -p password nextcloud < /tmp/dump/sql. Then I copied the old Nextcloud as I did before (using the official documentation’s recommendation of the command rsync -Aax) and carefully moved the files into the new /var/www/Nextcloud directory. Even through all of this, it still wasn’t enough.

Looking again at the /var/log/apache2/error.log file, I found that the new Nextcloud install couldn’t read the database due to the new server using the old Nextcloud config.php file (are you still with me?). So, I changed a few values in the config.php file so as to use the new database. What I did was change the dbname to the name of the new database, as well as input the new database login information. Also, I added the new IP address to the “trusted hosts” array in the config.php file. This seems to have fixed most of my problems.

Just in case, I also ran a script that I found in the official Nextcloud documentation for fixing the permissions on the new server. Then I changed some of the security configurations for the Apache server. I copied over previous configurations for SSL into the /etc/apache2/sites-available directory, and enabled them through the a2enmode command. With all that finished, I started up the Apache server again, and took the Nextcloud installation out of “maintenance mode”. Finally, I was able to use the server. Except, it wasn’t exactly to my liking.

You see, I had copied over the “data”, “config”, and “themes” directories. I did not copy over all of my previous apps. When I saw that I had only half of my previous apps, I thought, “I need to fix this,” and copied the contents of my previous Nextcloud’s “apps” directory to the new server. With those out of the way, I saw to using some of Nextcloud’s recommendations, and bumped up the memory (as well as putting in a timeout feature). These were harder to fix, partially because I had these problems with my previous Nextcloud installation. Nevertheless, I sought to fix them.

One of my problems was with the /var/www/nextcloud/.htaccess file, specifically that it wasn’t working. To fix this, I edited the /etc/apache2/apache.conf file and changed the AllowOverride directive for the /var/www section to “All”. This allowed the /var/www/nextcloud/.htaccess to work (at least, it would work since I’m accessing the site over a secure connection). Next, I added a memcache so as to speed up performance. I added in php-apcu and edited the /var/www/nextcloud/config/config.php file to reflect this by assigning memcache.local the value \\OC\Memcache\\APCu. My server was made much faster with this tweak. For added polish, I followed the directions on this tutorial and added Redis support.

This was a tough migration that I thought would have been easy. I figured that it would have taken a couple hours. However, it was stretched out to a numbers of hours (not to mention one night). While it’s great that I have migrated to a more manageable configuration, I should have done more research.