As you may have noticed, the website looks much better than before :)
Great thanks to Jono Mingard for taking it upon himself to work on it!
I’ve also largely been away… not sure how much Gamocosm has been down.
I’ve updated the server to restart services during downtime so hopefully there won’t be as many outages.
Actually as of right now, Amazon S3 is down so creating new servers (which tries to download Minecraft, hosted on S3) doesn’t work.
As always, thanks for all your patience.
Nothing major; about the same as last post lacking new development.
However, it seems Gamocosm is in fact ever so slightly growing, and I hope to put in more effort now that it’s summer.
With some help hopefully we can revamp the UI and see what we can do from there.
Even though there’s not really any news, I’d like to reassure people I haven’t forgotten about this :)
I believe it has been almost 6 months since the last real update to Gamocosm.
This has been my pet project for 2 years now, and it’s regrettable to say I haven’t been working on it much lately.
I’d say severe circumstances arose in real life, which are only getting worse (I don’t want to talk about it here, but I don’t think anyone would disagree if I told them what’s been up).
Though it’s extremely late, I would like to give a proper update.
I have no intentions of closing Gamocosm, but until further notice is in low maintenance.
There’s no real reason I can’t properly respond to issues on GitHub… but I’ve been struggling.
Whoever is still using it, I really appreciate your patience.
Anyways, now you know!
Hopefully by the summer or something I can clean things up…
Not sure if anyone ever reads this xD but thought I’d at least mention it somewhere visible.
As you all may know, Gamocosm uses pretty much plain Twitter Bootstrap for it’s base CSS/“theme”.
And it looks pretty bad as a generic “web 2.0” “web app”.
I have almost zero graphical ability, and what currently exists is already the hour of many, many hours over the course of ~1.5 years.
A couple people have mentioned they might try working on a redesign though no work has been done yet, though currently there is a GitHub issue with some discussion.
I’ve written down some of the challenges and my thoughts on what can be done, so it may be a good reference for anyone interested.
It certainly won’t be a trivial task, and I won’t be accepting “just any” work done, but I’ll try to be as helpful and open as possible.
For any designers or anyone dedicated and does a good job, I’m definitely open to paying for the final work, but I would not do it for the money, because it probably won’t be worth it for you.
But, if you’d like to discuss it with me, I’d be happy to.
Again, here’s the link to issue 41.
First big update in over 5 months :P
Though you may have noticed many minor changes since then; I still very much keep an eye on Gamocosm even when I’m not actively developing new features (apparently, once every half year now :P ).
I believe it was requested before early on, but now feeling comfortable with the status of Gamocosm (it’s been mostly stable for the past many months, as far as I know xD ), I decided to pick this feature up, as requested almost 2 months ago on GitHub (link).
I had school and persistent real life issues which kept delaying progress, but finally I sat down and cranked the rest of it out.
There’s now a “Schedule” tab where you can set different times of the week to start/stop your server.
Also, you can choose the autoshutdown duration now.
The schedule is still in beta!
I actually did quite some manual testing of specific parts, and wrote unit tests for as much as I good, but it hasn’t been tested live yet!
I’ll be doing some myself the next few days, but if you try it out please be patient if it breaks, and it’d be greatly appreciated if you would report any issues on GitHub.
I believe there are better instructions under the “Schedule” tab for a server (where you actually set it up), but here I’ll try to explain what it is.
The schedule is based on a week - so you can have it start/stop every Monday/Tuesday/Wednesday/etc.
It’s also limited to 30 minute intervals currently - though it should be a quick change to change that in the future, though there are some technical limitations - which I’ll explain below.
You specify “rules” on each line, where a rule is
[day of week] [hour]:[minute] [am or pm] [start or stop].
You can have a server start at a certain time, then let autoshutdown stop it.
I posted some thoughts in the GitHub issue, but basically I went with a single, periodic background worker + limitted intervals.
Here’s the diff.
Based on the day of week, hour, and minute (currently limitted to 0 or 30), an integer “partition” is calculated.
When the periodic background worker runs, it figures out the current partition.
This way, it can look up all the tasks it should be running for the current chunk of time.
The benefit of this approach is that there isn’t any intermediate state.
If each server had background workers for all their scheduled tasks, and at arbitrary times, it would get particularly messy trying to figure out what to do when the user updates the schedule.
It’s not hard to change the partition interval to, say 15 minutes.
I think Sidekiq (what Gamocosm uses for background tasks) is pretty accurate, and I know it’s very efficient, but I gave partitions a 5 minute buffer currently (if it’s 5:55 it’ll get all the jobs for 6:00).
Shortening the time interval below 10 minutes may cause some issues, but I doubt that’s neccessary.
Maybe 30 minutes is too big; maybe people would like to start their servers at 5:55 so it’s up by 6 instead of starting at 6.
I don’t know how people are using it (my play time is erratic so I just start my servers when I’m ready), so let me know if you have any feedback!
PS: maybe the writing in this post sucks, I’m sorry :S
Tired, but really wanted to get this out since I’m happy about it.
Maybe in the future I’ll tidy it up/someone will ask for clarification on something
I wanted to give a shoutout to the TrueCraft project lead by SirCmpwn.
It is a clean-room implementation of Minecraft beta 1.7.3 (~2011 September) - including the server and client (and it’s compatible with Mojang’s server and client).
It’s been and being developed from scratch without looking at Mojang’s original code, so it’s certainly an impressive feat of engineering!
It’s also another completely FOSS project (like Gamocosm), largely motivated by the developer’s own enjoyment of the game.
TrueCraft aims to bring back the original spirit of the game: a simple sandbox where you can explore, fight, and build with your friends.
You can create a TrueCraft server on Gamocosm - just select it in the drop down menu when creating a server (of course, you can also grab it from their website and set it up yourself however you like).
Thanks to Jadorel for helping me find this one.
So the Minecraft Server Wrapper monitors the Minecraft server on a droplet and also provides an HTTP API for doing stuff like starting, stopping, and running commands on a server.
It is written in Python and uses the subprocess module to spawn and track the Minecraft process.
“Exec”ing a command obviously writes the command to Minecraft’s standard input, and stopping a server also involves writing “stop” to the Minecraft process for a graceful shutdown.
Today, Jadorel reported to me that sending commands to the server (exec) wasn’t working.
I soon found that stopping the server wasn’t working properly either (would time out waiting for graceful shutdown then kill process), and with a little testing it was clear that data wasn’t being sent through to the standard input properly.
I was initially baffled as I hadn’t changed anything recently, but was fortunately able to identify the issue quickly.
stdin buffer wasn’t being flushed.
I’ve never had this issue before; my best guess is it used to automatically flush on newlines, but now it doesn’t.
I’m not sure if it has to do with a Python version bump or something internal in the OS, but anyways I thought this was mildly interesting.
I hadn’t encountered it on my own earlier as I had already op-ed myself on my servers and hadn’t needed the “send command to server” recently.
Anyways, the problem has been fixed, and the Minecraft server wrapper should be updated the next time you start your servers.
Thanks again to Jadorel for helping me find this!
PS: several other users have helped a lot throughout the course of development, but I think this is the first time I talked about a bug and fix and credits like this.
Be sure to check them out at the project readme!
I’ll quickly re-iterate their names here - as of 2015 June 2 - geetfun, SuperMarioBro, bearbin, chiisana, and KayoticSully.
Cheers, and thanks again to everyone!
Nothing really major, got a few updates/improvements/fixes since last time and I try to be completely transparent.
Mildly interesting for users
The cache gets invalidated when deleting droplets, snapshots, or SSH keys.
Not sure why this wasn’t done earlier.
This fixes some display/information issues for users.
Forge 1.8 has also been added to the list of Minecraft flavours - version 1.8-18.104.22.1682 which is the recommended build as of the update.
With refactored error code (which makes it not-messy to implement this), you won’t get stupid errors from Gamocosm stopping a server that is already off.
Some bugs have been fixed in the background workers.
Most notably, the droplet shutdown action is literally just the attempt; the droplet may still be in the process of “gracefully shutting down”.
So as a race condition, sometimes the action would be “completed” but the droplet not off yet.
Mildly interesting for developers
Instead of returning error strings, functions return error objects with error messages (which are displayed through
to_s) and error data.
This way, the message can be shown to the user, or a calling function can further inspect and handle the error.
Considering what to do with the
error? methods in
ServerRemote though; before
error! could be used to mark any object as an error (without distinction between error messages and error objects).
Sysadmin scripts have been updated - no changes for users, but if anyone ever wants to set up their own Gamocosm server it does :P
They were actually faulty at first; I was using RVM, but not sourcing
"$HOME/.rvm/scripts/rvm" so that RVM would be loaded as a function in bash, instead of as an executable on the path.
Gamocosm runs on Ruby 2.2.
RVM needs to be a function in the shell so it can actually modify the shell process’
$PATH and other environment variables as needed.
Because it was the only Ruby installed on the server, it didn’t really matter even though I always got complaints that RVM wasn’t loaded properly.
Also, starting Sidekiq in production sleeps for a second after starting the daemon so that the pidfile gets created before systemd complains about it.
Still can’t get rid of the pidfile complaints for Nginx though.
Just some mildly interesting stuff for server admins.
Finally, I’ve set up and enabled Disqus comments for this blog.
PS: Be sure to check out GitHub’s Student Developer Pack!
You get $100 of credit on Digital Ocean just for being a student in a diploma/degree granting program.
Even though it has been three weeks since I posted “development continues!” I haven’t actually worked on Gamocosm until today :P :/
I’m doing research on distributed systems and multilayer performance with a professor and graduate student, so I’ve sorta been distracted the first few weeks of work.
But here is the first real update in many months - Gamocosm now creates new servers with Fedora 21 (the lastest release as of writing).
Some sysadmin things had to be updated and improved in the SSH setup server worker.
For months I’d sometimes get emails about failures in the SSH worker: “WARNING: Your password has expired.”
I could never reproduce it, and
chage -l said the password was never set to expire.
Today I found this thread though, which says it’s related to connection sharing.
I don’t know what’s the best way to deal with this, as I do need connection sharing (for speed anyways), but I suspect it has to do with users creating/destroying servers in a short ammount of time.
I did inspect and refactor so that timeout blocks happen inside
on host do ... blocks instead of the other way around, which I think might help, or at least possibly fix a race condition which hasn’t shown up yet with timeout (which is unsafe).
I’ve wanted to and been considering adding support for generic servers (so Gamocosm just starts, stops, backs up, and destroys servers - no Minecraft or MCSW stuff), but have held off because I’ll need to add a lot of special case checks.
It’s not that bad, but for example, I got to make sure it never tries to do ping MCSW, and only only part of the action panel is needed.
Finally, I’m considering (~75% likely) renaming Gamocosm :P since 2 of the 2 people who commented say it’s a bad/not-memorable name xD
Sigh, it’s annoying to rebrand, but I’m quite happy with the progress and stability so far, and will likely do a bigger public push soon.
I see people joining IRC and I always miss them by a few hours or a day.
The best way to reach me is via GitHub!
I feel like I should enable comments… it seems like the best way to facilitate communication is to provide many options.
So the last time I said I would probably be busy until the end of school around May, and now I am done and it’s the end of April.
I’ve had some irreproducible bugs show up I need to take a look into, and after some general improvements hopefully after a week or two I will post again about future plans.
119 users total with 21 active in the last month, like ~5 extra stars on GitHub when I haven’t been promoting Gamocosm… not bad xD
Thanks again for your patience!