Troubleshooting Steam Matchmaking Servers for Dummies

So I recently spent several hours troubleshooting my Space Engineers server, and learned a lot about how Steam does matchmaking while I was at it. I figured I’d make a blog post to share and hopefully save others some time.

First let’s take a look at some pretty pictures that describe how the Steam Matchmaking service works in terms of hosting and joining a game server:

[gszNOSF]
[BBXwNWF]

[u6HUPdZ]

[26L7HPY]

It’s not too complex of a process conceptually, but our computers are doing a lot of work in the background to make it happen. So how can we be sure that we’ve set them up properly so that they can do their job?

Reference: Steam server port information from Valve: https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711

Let’s start from the beginning with items 1 and 2 from the diagram above:

Can our server identify itself to Steam?

To be sure that this is working, start the Local/Console server and read what pops up in the console window. It should tell us near the bottom that it connected to Steam.

[G6r7YRf]

If this fails, then we need to ask ourselves the question: why can my dedicated server not send information out to the Steam servers?

We’ll need an internet connection on the machine hosting the server, and our firewall configured properly to allow outbound traffic on the Steam ports in the link above. If you think a firewall may be the problem, turn it off entirely and try to start the game server again.

If it can connect with no firewall running, then turn your firewall back on and do some Google searching to find out how to configure outbound traffic on your firewall software for the Steam ports in the link above.

Can Steam tell a player about any game server?

This will cover items 3 and 4 in the above diagram.

The player needs to be able to talk to Steam to ask about the server. This means they will need an internet connection and no pesky firewalls getting in their way. If you fire up your game and can see other people’s hosted games, then this part is working. If not, then your problem is that the game client can’t talk to the Steam matchmaking servers.

Check the internet connection

Can Steam tell a player about MY game server?

This is the part that burned me. This refers to items 5 and 6 in the diagram. To understand this, you need to know a little about networking. Routers and firewalls are very generous when allowing traffic from a computer to go elsewhere, AND when allowing responses back from the server you just contacted. They assume the connection is a response to a request you just made and allow it through.

However when another server tries to connect to your router/server without you having made a request from them first, by default your router and firewall will treat the unsolicited connection like an intruder: denied!

To check if this is the problem, use the Steam Server Browser built into the Steam client to see if you can connect to your server and find information about the game. If not, then Steam won’t be able to tell Space Engineers players about your game either. In the Steam client go to View > Servers, then select Favorites, “Add a Server” and enter your server’s IP/domain name and optionally port. Then click “Find games at this address…”

For people hosting their servers at home, go here (http://www.whatismyip.com/) to find your public IP. This will be different from your computer’s IP address if you use a router. Routers set up a local network for you and give out local IP addresses to the computers on them.

If your server is communicating with Steam correctly, you should see information about your games:

[Cdaoc6Y]

So if you want Steam to be able to make an unsolicited connection to your server to scan the 30 Steam matchmaking ports, and then tell players what it found, your router and firewall need to allow inbound traffic on ports 27000 – 27030 (or possibly just the one port you’re actually hosting the game on.)

How to do this will vary based on your setup, but routers will need port forwarding turned on, allowing unsolicited connections to your router on the game’s port to be forwarded to your computer instead of rejected. If you host your own web server, routers won’t be a concern, but both public web servers and home computers will need their firewall to allow inbound connections on the Steam ports for this to work. A Google search for your router/firewall should teach you how to do this.

Items 7-9 should work well if you’ve gotten this far. Your client can talk to Steam, your server can talk to Steam, and Steam can scan ports on your server. All that’s left is Steam Groups!

Is the player allowed to join based on their Steam Group ID?

To find out your Steam Group ID, use this link, but put your Steam group name in the URL. The ugly XML you see will include the group’s full ID near the top of the page.

http://steamcommunity.com/groups/%5Bgroupname here]/memberslistxml/?xml=1

Once you have your Steam group ID, you can add it to your server information:

[bxkhugz]

0 will allow all connections. If you change the group ID field to something other than 0, then only Steam players in the designated group will be allowed to join. To test this, the Space Engineers game client can show us a list that is not filtered to exclude games which won’t allow you to join based on your group. Simply unckeck the ‘Allowed Groups’ box to see the full list of all servers:

[XJYuKaG]

And that’s about all I know about Steam matchmaking and troubleshooting Space Engineers dedicated servers. I hope this helps some folks out there!

Legacy Code Explained for Non-Programmers

You do not truly understand something unless you can explain it to your grandmother.

– Albert Einstein

I often get asked by non-programmers what legacy code is. I’ve heard many programmers try to answer this question over the years, and have yet to hear a good explanation that a layperson could be easily expected to grasp (and haven’t yet delivered one myself, either.)

However I think Einstein was right when he said the quote above. In order to truly understand anything, regardless how complex it is, you need to be able to draw parallels between a complex system and something simpler and easier to picture in your mind.

In software development, we call this an abstraction. It’s essentially the way you understand what a car is. Cars are extremely complex, with thousands of parts and many makes and models. But because we have a simple and broad understanding of what a car is, anyone can quickly identify whether something is a car or not, all without needing to pop the hood and understand its inner workings.

So in order to further solidify my own understanding of how maintaining code, especially the dreaded legacy code works – I have set myself the task of explaining it in the simplest terms I can.

Legacy code is basically old code that is no longer well understood (and indeed, may never have been.) Yet such code often runs many of the oldest and most important software systems in the world. The more important code is, the less likely we are to change it, and the easier it is to let things stay in a bad state simply because they’re working. 

You probably don’t want your bank to change the code that keeps track of how much money you have unless there’s a dire need. If it ain’t broke – don’t fix it.

I think the best analogy I can give for being asked to maintain a code base is that it is like being asked to edit a novel series. (Choose your favorite here, Game of Thrones, Harry Potter, etc.)

There are enough books that you cannot easily read them all every time you have to make a change, so you’ll often rely on your memory of the last time you read it. Some changes may seem fairly straightforward: rename a character. Let’s say you want to change Eddard Stark’s name to William Stark. This sounds simple enough, simply use a text editor to find and replace Eddard with William.

This works great, but what if there were two characters named Eddard? Now we have a problem. We’ll need to find each place the name Eddard is used, then read the paragraph around it and understand it so we know which character’s name we’re changing. And if we make a mistake, calling one character by another’s name can be very confusing for the reader.

So we can see that even the simplest of changes may require us to have at least a basic understanding of the book near where we make changes. But that can’t be too error prone, so where do bugs come from?

Well let’s assume we want to make a change that’s more complex: let’s say we want to rewrite the series so that the winners of a battle are instead the losers. This can have serious implications for the characters and groups in the book, and we can’t just search for a character’s name to find all the places affected – this will require plot changes.

So we’ll need to understand what areas of each book are ones that would be affected by the outcome of that battle. Future battles may never have happened, different characters may have died or survived. This will have an impact on how we want the plot to go in many future chapters.

This is a pretty big task. If we are intimately familiar with the books, we can speed the process up, but if the book series is large or if we’re new at our job and haven’t read them all, this may necessitate a whole lot of reading simply so we know what changes to make. Many chapters may have to be read just so we know how to rewrite a single paragraph. In a large series, we may have so many changes to make that we have two people working on it – they may even accidentally contradict one another.

So this is all pretty standard practice for authors, they work slowly and deliberately, and have editors to help them, and manage to get books together without too many glaring errors (at least after all the grammatical and plot errors are found, and the editing and rewrites are done. In the software world those are called ‘bugs.’)

Why can’t software developers just do the same thing?

This is where Legacy Code comes in: let’s assume the plot weren’t so straightforward. Let’s say our book is about time travel, and the actions of one character in the past could have many implications for many characters in many places at any point in the future.

If a character overthrows an evil government 100 years in the past, we may be looking at a complete rewrite of the rest of the book series, or at least a complete read through of the whole series to be sure we haven’t missed anything.

There’s no longer any convenient ways for us to know what characters and events may be affected by this plot change we’ve made, so the list of things that may have to be checked and changed is essentially “everything.”

But let’s say our publisher wants our book series published by 5pm on Friday (or you and thousands of other users have told the company that publishes the software in question that you really want that bug fixed right away, in no uncertain terms.)

Then maybe we don’t take the time to reread the whole series. Maybe we talk to the guy who knows it best and ask him for a list of every place that may need to be rewritten. After a few hours he comes back to us with the most exhaustive list he can come up with on short notice and says “I think that’s everything.”

A few days later, we’ve rewritten our books, changed everything the guy who knows the series best told us to, and we make our 5pm on Friday deadline. We got everything.

We’re pretty sure we got everything.

We’re kinda sure….

And this, ladies and gentlemen non-programmers, is where bugs come from. This is how legacy code causes them. So how do we make it better? How can we have good code instead of icky legacy code?

Let’s say that instead of our book series, we instead had an anthology of short stories. The stories may share characters, take place in the same world, and occur at some of the same locations.

Because each story is meant to stand alone, there’s only a limited number of ways one story can affect another. Because each story has its own plotline and a small list of characters and locations, it’s easy for one of our editors to remember which are involved in each story.

We could even draw a diagram of which characters and locations are shared between which stories, allowing us to change one story and know immediately how our changes will affect others.

We may even give each story a handy name to help us remember what goes on in it, such as “Critical Bank Account Balance Code.”

So now we’re in a much better spot if we want to make changes. A quick read-through of a single short story will let us know what characters and locations are involved. The title will give us hints to tell us about a story we haven’t read or jog our memory about one that we read several months ago. We can even consult our not-too-complex diagram about the relationships between the stories to understand what impacts a change may have on our series as a whole.

So that’s it then. That’s what programmers are talking about when they use phrases like “legacy code”, “good code”, and where a lot of bugs come from. Basically programmers complaining about legacy code are complaining that the last writer left them a huge novel series with a convoluted plot to edit, and they’re wishing that instead they had a nice series of self-contained short stories to work with.

When they say they want to “refactor” code, they want to take a novel (or a big chunk of code) and turn it into a series of short stories that will be easier to work with and discover errors and plot holes in.

So bear this in mind from now on when you hear your programmer friends throwing around jargon and lamenting things like ‘NullReferenceExceptions’ – we’re just trying to make sure we can keep writing a story that ends with you using some software happily and then going to do something more important, rather than a bad ending where you’re screaming at your computer or a hacker gets your data.

The Dancer’s Code

The Dancer’s Code is a list of reminders I’ve made for myself on how to be a dancer who gives and gets the most out of dancing. All the dancers I know could do a little better with at least one of these things, myself included. But just like with dancing, perfection isn’t the goal. The goal is to strive to be your best.

 


The Dancer’s Code:

Dancing isn’t just something you do with your feet. It’s a community. When you see someone you don’t know, be an ambassador. Don’t just dance with them – befriend them.

Sharing a dance is generosity. It’s not something anyone is entitled to. When someone dances with you, appreciate it. Likewise, be generous to others with your own dancing.

Dancing is a talent, not a virtue. Being a good dancer doesn’t make someone a good person. That’s something you do off the dance floor.

Dance hates drama. Whenever someone comes up in a conversation, imagine that they’re listening. If that makes you uncomfortable, end the conversation. You have better things to talk about.

We don’t practice to learn how to dance “right.” We do it so that when the music comes on, your partner takes your hand, and you feel a desire to express yourself, your body doesn’t get in the way.

Above all, have fun. Stress has no place on the dance floor. Great music, great people, and the freedom to let your feelings move you. All that’s left is to smile and let it happen. That’s what dance is all about and it’s the thing we have in common that brings us all together.

Moving to Wordpress.com

I’ve had a self-hosted WordPress site for many years. But have decided that keeping it up to date and managing the Vm it ran on were not worth it. So I’m moving my blog content to a new home on wordpress.com to make things easier on myself.

Thoughts on GitKraken

So I recently saw the 1.0 release announcement of Axosoft’s GitKraken. Since I’ve recently been having lots of issues with Atlassian’s SourceTree for Windows, and have never particularly cared for the UI. I hear that SourceTree on mac is excellent, but I’ve not had the same experience with their Windows client. I’ve also found Github Desktop to be very nice, but a bit limited when it comes to repositories with lots of local branches (not a common use-case on Github repositories, but I encounter it a lot at work.)

I’ve been in the market for a Git client that was as useful and intuitive as HG Workbench for quite a while now. As a result, when I heard about GitKraken I was eager to give it a try. I’ve been actually quite pleased so far and wanted to share my thoughts on it!

GitKraken in action

Their advertising is really quite ridiculous.  It almost turned me off to the product at first. But most of it is about how excellent their UX is, and after a few weeks of using it, I actually have to agree.

 

DOWNRIGHT LUXURIOUS, AMIRITE GUYS!?

I haven’t used software which pleasantly surprised me by having completely unexpected features that “just worked” in quite a while. The last application I can remember that made me feel like this was Slack. When your product is being favorably compared to Slack, that’s usually a good sign.

There are lots of little nice features such as the convenient, and most importantly – short, first-time demo that takes you around the settings menu to set up Github integration etc. The ability to drag and drop a branch or tag onto another in the source graph to initiate a merge, or the brand-spanking-new-in-v1.1 Fuzzy Search which allows you to search for files, repositories, and branches by text and click a search result to change repos, git checkout the branch, or open a file’s git history.

Overall it’s been a really positive experience so far, with just a few bumps in the road. It wasn’t able to detect my global Git merge tool (Beyond Compare) for some reason, so for now I still have to run ‘git mergetool’ on the command line during merge conflicts. But their updates so far have been adding nice content and polish, so I’m optimistic that the few minor gripes I have will be remedied soon.

If you’re in the market for a new Git GUI client, I can safely say that GitKraken is by far the best experience I’ve had with one on Windows so far.