Doctacosa

Backups. Always important, and always neglected, right? Minecraft tends to be stable... most of the time, but it also runs into its problems: chunk corruption, unexpected crashes, large-scale griefing, or even the server disk filling out. As such, it's important to keep backups on a regular basis – they've been useful before, so not doing them isn't even an option.

For a while now, my main backup procedure consisted to having a copy of each separate world compressed and stored away, waiting to be used. If the file hasn't been fetched within a few days, it'd automatically get deleted. I'd make sure, once in a while, to download a copy of everything to my own computer as well. I used to keep several days worth of backups on the server at once, but as the worlds started using more disk space, I've had to scale this down quite a bit.

In the meantime, I've learned that my host has a free backup location available for each account. To prevent people from using this to simply extend their disk space, this backup spot is only available through FTP, so you need to connect to it explicitly to upload and download files. I decided to make use of this, and wrote a new Python script to automatically run on a regular basis.

The new process is simple:

1. For each world: a) Get a copy of the world and compress it. b) Upload the compressed copy to the backup space. c) Delete the local archive.
2. Backup the database the same way.

Should I ever need to fetch a file from storage, this simple command downloads it back into place:

python3 backup.py -d FILENAME

Moving the files to a different storage location has the big advantage of mitigating risks: if the main dedi's drive fails for some reason, I won't lose both the live games and their backups at the same time.

Another motivation for this improvement is the simple fact that the dedi's disk is starting to fill out. I've got 100 GB to work with, and between the Minecraft worlds, the Starbound universe and various web sections like the images gallery, it's starting to fill out nicely. Ideally, I'd have two servers or drives: one powered by a SSD to run the games, and one on mechanical drives to have a lot more storage. We're not quite there yet, though, and I need to work with what's available. Keeping the backups off location will help to save on disk space as well as make things better organized.

Got ideas on what I should write about in these game dev entries? Please comment with your suggestions!

#gamedev #projects #minecraft

– Doctacosa

Once in a blue moon, I'll go out on vacations, with limited to no Internet access. Of course, during that time, I want things to keep running smoothly for everyone. The websites and forums do fine, as they're stable and need little maintenance. The game servers are another story! I make it a point to keep things running even if I'm not available, but at the same time, you can only plan so much for the unexpected. To keep the odds in my favor, I avoid making any major changes right before leaving. Sometimes, this will go as far as delaying version upgrades. I don't like doing this as waiting too long to update versions can cause us to lose some players, but at the same time, I feel that overall stability is more important.

If something breaks

That's when things get interesting. I keep an eye on things, of course, but not as often when I'm busy visiting somewhere. The moment I either notice that something is not right, or get a notification from another of the staff members, I jump in however I can to set things right. This can be through any available wi-fi hotspot, data access through my website, or even sometimes through someone else's computer.

I've installed the required tools to connect remotely through my computers, my tablet or my phone, so I can login to the dedi and run any commands necessary. If it's something more minor, any web browser will allow me to check on each server through the consoles.

The northern Canada example

A fun example of this happened back in 2013, when I took a long train trip to the western coast. A mere day or so after leaving, Laurasia went down without warning. Nowadays, if that happens, people can easily move on to other servers through the lobby. At the time, though, Laurasia was the entirety of the Creeper's Lab, so losing it was pretty critical. There was one big problem for me: I was in the middle of nowhere. I barely received a text message notification that the server was down, then I promptly lost all network connection to my phone, even for calls. Cell coverage in Northern Canada can be quite spotty...

I had to wait about two full days for a longer stop in that trip, where I was able to find a public wi-fi hotspot. From there, I logged in to the server's web interface and restarted it. Thankfully, it went back online without a hitch and remained that way for the rest of my vacations!

– Doctacosa

As you've seen by now, the custom ranks feature has been put online thanks to the latest wave of improvements to the chat server. To allow this to take place, the messages are now generated by the chat server itself and sent pre-formatted to all Minecraft instances; these only need to display it through a /tellraw command. A side effect is that all public chat now needs to be relayed through said chat server: if it fails for any reason, including bugs and crashes, players in-game will no longer be able to view messages at all. Thankfully, the system has proven to be solid and reliable since it first came online, so I'm comfortable with this change.

Now, how does this works? That chat server maintains a direct connection to the MySQL database, so it's able to read the access level of each player (admin, op, helper, ...) along with their status (contributor, Patreon backer) and any custom titles set. It takes that information, the received message, and puts it all together for display.

There are still a few aspects that I want to add now that the foundation work is solid:

• At this time, the chat sent from Discord and IRC only displays the [Discord] and [IRC] tags respectively. Why not go the extra step and have them display the actual rank of the chatter? We already have matching groups on Discord for all staff positions, so that could be reflected in-game. Likewise, authenticated IRC users could be identified based on their user status (aop, hop, etc.).

• One thing I want to investigate is to allow people to /msg others cross-servers. I already overrode the standard chat and /me actions, so I believe that /msg is doable as well. This would make it more convenient to stay in touch with others while hopping around worlds and servers.

• As a longer term target, possibly have death messages carried over to Discord and IRC. That would provide more context to the chatters; how many times has someone said something like “Why are you yelling? Oh, creeper got you. Nevermind!”? Carrying the cause of kicks could also help the staff identify people who might be using flight mods. And hey, if I can read and propagate death messages, why not replace them with some custom ones at the same time...? Maybe even get some community input on new messages to make things interesting! How does that sound?

#gamedev #projects #minecraft

– Doctacosa

As a new dev entry, here's why and how I introduced the recent chat server.

From day one, when I introduced multiple Minecraft servers (first Rodinia, then Gondwana, and so on), I relied on IRC to carry the messages from location to location. Each server would spawn an IRC bot that'd be used to join #interordi-mc to send messages, read them and show them in game. Rather simple, and it works. The first version of this setup used a Minecraft plugin, which eventually I replaced with my own server wrapper when said plugin seemed like it would no longer be updated. This also allowed me to make a universal chat solution that worked for Bukkit/Spigot instances, Forge setups, and even vanilla Minecraft itself.

Some of you might have seen me running some tests with Discord earlier this year. This used a IRC <–> Discord bridge, where another IRC bot would be used to relay messages to and from Discord. This created the following structure (only showing three Minecraft servers for the example's sake):

This meant that messages travelling from Laurasia to Discord would absolutely need to go through IRC. The end effect is that messages as seen on Discord would look like this:

CreeperDiscord <CreeperLaurasia> (Doctacosa) Hello there!

That's a bit wordy, isn't it? Additionally, I had no control whatsoever over the formatting. What I wanted to get is closer to this:

CreeperDiscord (Doctacosa) Hello there!

Much better, isn't it? It's more readable, too. To do this, though, I needed to get IRC out of its position as the messages middleman. I eventually got the idea to write my own relay station of sorts. All of the various chat locations (which I've named internally “channels”) would send their messages there, and the server would accept and transmit them to all other channels. The new setup took this form:

Eventually, I settled on this text format:

Creep [Laurasia] (Doctacosa) Hello there!

I shortened the original “CreeperDiscord” to the more compact “Creep”, and decided to include the location name so people would know if a chatter was on Discord, IRC, or directly in-game. People seem to like having that information available, so that will be here to stay.

---

Of course, as I mentioned before, having that new chat core in place opens more options. I've reintroduced today the .players command, which now works from in-game, IRC and Discord. As an extra bonus, it's able to relay the list of persons connected on IRC and Discord as well. Those custom ranks I talked about in my previous post? They'll be read and attached to messages by the chat server directly, making sure that the information is always up-to-date everywhere. Other additions could happen at a later time, too!

Got an idea on what topics I should write about in future Game Dev entries? Send in your suggestions in the comments!

#gamedev #projects

– Doctacosa

The problem with being a systems administrator is that, if you do your job properly, no one is likely to notice. I spent some efforts in the past week to improve how I manage things with the Minecraft servers, and figured I'd explain here how the process went! The problem

Running a single Minecraft server was easy. Updating? Take server down, swap files, bring back online, done. Then I introduced Raw (now Rodinia). I had to do it twice over. Simple enough. Then Gondwana got split off. Then Avalonia. Then the Lobby. And so on.

As it stands right now, with the additions of minigames, I'm running 11 Minecraft server instances in parallel. Updating to new versions means taking down all 11 servers, replacing the appropriate files, then bringing them online. The same goes for security and performance fixes, and this is a significant work load at this point. It's also easy to make mistakes: if I keep an older version of, say, one of my plugins on a random server, it may still work yet contain a bug that I assume has been fixed for weeks. This happened more than once, and I wanted to streamline the entire update process.

The solution

What I did is create a server launcher. Instead of simply starting each Minecraft server directly (or really, my server wrapper that takes care of launching the server instance), I call that script instead. Written in Python, every time it is run, it copies some files from a central location, places them in the server's directory, then runs the server. The end result is that, every time a server is launched or restarted, it automatically grabs the latest files I've made available to it, ensuring that everything is up to date. This currently includes the Spigot build (the game proper), my wrapper (used for IRC link-ups and remote control), along with my custom-made plugins. New files can be added to that as I need to.

Of course, this raises the issue of updating the launcher itself whenever I want to automatically copy new files, and I don't want to do that either. Thanks to Python's modular structure, I've got a single copy of the core launcher in the shared directory. Each server has a mini-launcher, not likely to required any changes, which is used to call the main one. If I want to keep a new file updated, I only need to edit the one central location.

The result

Keeping a server up to date is super simple now. I place the updated files in the centralized location as soon as they're available, then restart individual servers whenever it's convenient. A simple command is used for each instance: python3 launch.py. And it's done!

I hope you found this insight interesting. Again, feel free to let me know if there's a topic that you'd like me to expand on in a future post! :–)

#gamedev #projects

– Doctacosa

You know those people that seem oblivious to their surroundings when walking around? The ones that tend to be most often messing with their phones, or sometimes lost in a book? The ones who will usually walk in the middle of a sidewalk or corridor, sometimes swaying from side to side, usually walking too slowly for the crowd?

I propose a new word to call these people: ZOMOBI. A contraction of “zombie” and “mobile”, zomobi describes how they're most often brainlessly moving ahead, often with a mobile device in their hands. As a bonus point, it works in both the languages I use the most: English and French.

So, when you're out and about, don't be a zomobi: pay attention to what's going on around you!

#vocabulary #mobile #musings

– Doctacosa

I’ve been dealing with people and websites from several countries recently, and there’s something that many groups handle differently: date formats. Depending of who or what I’m communicating with, today’s date might be 7/9/2015, 9-7-2015, 2015-07-09, July 9, 2015, or even 7/9/15. It’s complicated and error-prone, especially if you don’t realize how a given person has chosen to write down said date.

As such, can I propose that everyone should use 2015-07-09? It’s simple, obvious, and placing the year first avoids the issue where you don’t know if 07/09/2015 was written in the American format (9th of July) or in the European format (7th of September). Additionally, it keeps a logical progression if you place a time next to it: 2015-07-09 12:34:56 goes from the largest unit (the unit) to the smallest one (seconds). There’s also no excuse at this point not to always write the year using four digits.

As an added bonus, if you name several computer files in this format, they’ll automatically be sorted from oldest to latest, and you can even flip the display order with a click or two. It’s convenient and simpler for everyone!

#date #musings #standards #iso8601

– Doctacosa

For a while now, with the rise of smart watches, I’ve seen several people claiming that those who “still” wear a watch are too lazy to simply get their phones out of their pockets. That’s simply not the case.

I wear a watch on my wrist. I enjoy my watch. The right models on the right people can be quite stylish, and I like how they look. It’s also more convenient when I actually want to know the time.

The funny thing is, wristwatches became popular in the early 20th century as people were tired of having to fish in their coats to find their pocket watch. The transition from one to the other was quick, and so very few people still use pocket watches nowadays.

If you call me weird for wearing a watch, then I totally feel justified in calling you archaic for needing to pull a device from your pocket only to tell the time.

#musings

– Doctacosa

I think I figured out part of my frustration with online gaming as a whole: I love the concept, it usually works great, and you can lose yourself in an alternate universe for hours… and yet, it often just doesn’t work for me. Either the game is broken in some way, or lags too much; either my friends and I can never get online at the same time, leading to unfulfilled promises; or the game grows stale too quickly and others lose interest while I still want to keep going.

I wish I could enjoy multiplayer game so much more. The potential is there, but the problems or availability of the players quickly add up to something that makes it unfun.

#musings #gaming #thoughts

– Doctacosa

How an evening at home goes when I realize I don’t have an Internet connection:

I’ll go check my forums…

… no connection, huh? Weird. Oh well, it’ll probably be back soon. I’ll go read my e-mails in the meanti…

I’m stupid, that won’t work either. Guess I’ll go check the news on their webs…

Argh, of course that won’t work. Well, I’ve been meaning to watch that TV show on Netflix, so I ca…

No, won’t work either. Hey, did I have any e-mails…

… screw this, I’m going to eat.

^ That was me last night.

#musings #interordi

– Doctacosa