Alt-F4 #32 - Operation Wireshark
Welcome to the shark-filled issue #2⁵ of Alt-F4. In these treacherous waters, The-Kool guides us towards putting speakers to good use, maybe even as a shark-warning-system, in the latest episode of Complexity Corner! Then, Hornwitser gets to some actual shark hunting using Wireshark, telling the story of how he tracked down network issues he encountered with the game. Grab a harpoon and jump in!
Welcome back to Complexity Corner, where we look over the less used or more complex mechanics of the game to give an introduction to those unfamiliar with them. In this article, we’ll ask three questions: ‘What is it?’, ‘What results can it give?’, and ‘Where should it be used?’
The Programmable Speaker is a ‘building’ that takes up only one tile. When connected to a circuit, it can make sounds that you’ll hear in-game based on the signals on that circuit. You can adjust the volume, pick a specific sound for it to play, tell it to be audible no matter how far away you are, and even show a custom alert on the map. The speaker is unlocked with the Circuits technology, which is so early in the tech tree that it could be your first green tech.
It produces sounds! Okay, that one was kind of a gimme. While speakers are best known for the musical contraptions people build with them, they serve some practical uses as well. If you hook up a speaker to your factory and set global playback and an alert icon, you can design custom alerts for just about anything. You can (and should!) give it a custom icon and title because you’ll absolutely forget what the blaring klaxon is for. This is an easy way to broadcast an alarm over your entire factory and can help you catch warning signs of trouble before they become true problems.
Have you ever strained your power supply and accidentally caused your coal miners to slow down, sending you into a brownout spiral as your boilers gasp for fuel? Try placing a speaker next to the coal belt leading to your boilers and hooking it to the belt with a wire. A full belt holds 8 items, so if you set the speaker to trigger on less than 8 coal, you’ll get an alarm if any gaps show up in your coal belt. Set this alarm to global playback and give it a name like “Check on your coal mining!” and you’ll get the notice no matter where you are or what you’re distracted with.
A completely different type of alarm is a train crossing alarm. Hook a speaker up to a rail signal on your track where you like to cross, plus one more signal in each direction (make sure you get the signals on both sides of the track). Tell it to sound a local alarm if any of the signals are yellow (number of yellow signals > 0). Next time you head towards that rail and there’s a train coming, you’ll get a nice loud siren telling you to wait a moment before crossing!
Like many other things in Factorio, the uses for the speaker are boundless, both in practicality and creativity. Builds range from the super simple shown above, to the super complex midi players and beyond. I hope this inspires you to come up with some of your own and saves you a few headaches. Until next time, I’ll see you on the factory floor… and watch your step!
This is a project that started around the time of the Gridlock Cluster event. I was investigating some issues with clients randomly dropping from the game, which brought me into examining packet traces using Wireshark. These packet traces are basically binary logs of packets that are sent and received by the network card of the computer that captured it. To understand what this binary data means, Wireshark decodes it with protocol dissectors, something it has for protocols spanning all facets of networking. But it doesn’t come with a dissector for Factorio, so when I used Wireshark on Factorio traffic, all I could see was hexadecimal goobelygook being sent between the server and the client.
After looking at bytes going back and forth between the server and the client, I wondered: How difficult would it be to write a dissector for Wireshark to decode this data? I looked into it and found out that the easiest way to write it would be in Lua, which can then be loaded as a plugin by Wireshark, in a system not too dissimilar to Factorio’s mods. And so it was that I started staring at bytes in hexadecimal and figuring out the structure to it all. It became a bit of a personal challenge to figure out what each of the bytes meant and have them decoded into Wireshark. I think I worked on the dissector for around two weeks before I sort of gave up on it.
It wasn’t that I couldn’t do it. It just wasn’t worth all the effort I put in. You see, the output of my dissector wasn’t all that useful in telling what’s going on. It looked something like this:
Sure, it would decode the framing and reassemble fragmented packets, but unless you happen to know what weird, odd, strange or coloured data means, it just wouldn’t be of much use. This is also one of the reasons I haven’t released this dissector: It’s better than looking at hex data, but not by much. It doesn’t give you the sort of deep insights into the inner workings of the Factorio protocol that you’d expect from any of the other protocol dissectors Wireshark has. And so it became that this project was put on the shelf, not to be looked at again.
In the past, Factorio developer Twinsen has talked about making a dissector for Wireshark in FFF #196. The post contains quite a lot of internal information about the protocol which I could have used when I made my dissector, but I chose not to look at it as I wanted to make mine without relying on internal information from the game source code. An obvious question poses itself though: Why not use Twinsen’s dissector instead of writing my own? Well, for a start, it’s not publicly available, but more importantly, it can’t be made publicly available. The way Twinsen’s dissector worked was to build Factorio as a shared library, then build a custom version of Wireshark that linked to that shared library. Now, Wireshark is licensed under the GPL and you are not allowed to distribute GPL code that links with proprietary code, so to distribute the dissector Wube would have to release Factorio under the GPL which is obviously not going to happen.
A few weeks ago though, I realized something. The Windows version of Factorio ships with a
.pdb file that contains debug symbols. The developers use it to generate symbolized stack traces when the game crashes so that they can see where in the source code the crash happened. Luckily for me though, it’s stuffed with other kinds of debug data too, like the kind needed to attach a debugger to Factorio and inspect the values of variables stored in memory. That means it contains type information, which is the structure of the data as defined in the code along with the names of fields and enums. The name of fields are very useful as it’s the label developers put on a piece of data in order to reference it in the code. Likewise, the enums contain mappings of logical names to numeric values.
I was able to dump this type of information from the
.pdb file into something readable using the ‘cvdump.exe’ tool. Once I had that, it was pretty easy to find the names of the structures from the
.pdb file and rename all of the fields in my dissector to use them. I could also get the enum definitions to translate numeric values to logical names for the fields that use them. After some tidying up of my code and data presentation, I was able to make the dissector output look like this:
No longer does one have to guess what an “Odd Blue” value is: It’s clearly the
id of an
InputActionSegment. Now, the type is translated from the machine code looking
0xa2 into the much more friendly name
ServerCommand. The only issue with creating the dissector by using data that ships with the game is that it’s no longer clearly my original work, which puts the legality of distributing it in question. Rather than trying to figure out whether I had copyright law on my side, I asked the Factorio developers and they said they were fine with me releasing this to the public. So if you want to try it out yourself or add it to your toolbox, you can find it in my repository on GitHub.
Personally, I’ve used it to investigate networking issues with Factorio, from clients getting disconnected to NAT punching not working. I’ve also written up some bug reports based on my findings that have lead to bugfixes in the game. With the move to using names from the Factorio debug symbols, the data it shows has become really clear and informative, at least compared to what it used to show. It’s still more of a tool for people experienced with computer networking and Factorio internals though, so don’t expect to understand what all of this means if you’re not familiar with these things.
As always, we’re looking for people that want to contribute to Alt-F4, be it by submitting an article or by helping with translation. If you have something interesting in mind that you want to share with the community in a polished way, this is the place to do it. If you’re not too sure about it we’ll gladly help by discussing content ideas and structure questions. If that sounds like something that’s up your alley, join the Discord to get started!