The programmable speaker There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life. So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things: Show configurable GUI alerts and play audio alerts based on circuit conditions. Play audio samples as controlled by the circuit network in a way that simple songs can be created. The entity graphics are placeholder programmer graphics. Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals. And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network. Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated. Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low". I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit. There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF. The map download struggle (Technical) For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in "Pending" or "Duplicates" or "1/0 Magic", but after a few months some other person would report it again. I seem to have a habit of obsessing over these rare "unfixable" bugs (audio mixer crashing, vsync performance issues, non-pixel-perfect sprite drawing), so I started looking into this map downloader issue. First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio. But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic. The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :) This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen. Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue. In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections. As usual, let us know what you think at the forums.

Combat Balance Twinsen here. As you might have read in Friday Facts #166, we wanted to do some combat balancing. First, to not bring the hopes of everyone up too much, this did not mean a combat overhaul. It means mostly tweaking numbers to make the game more fun and make some of the the weapons more viable. No new entities or new mechanics. As I was doing the combat balance, it was clear the everyone has their own different opinion of how combat is, how it should be and how to make it "better". It's hard to please everyone, especially when you are just tweaking numbers. To try to objectively evaluate combat I used the following methodology. As the game progresses, the player's power increases through research, but so do the biters(mainly due to evolution factor). So I split the game in 7 sections based on research progress. Each section also has the evolution factor I tested biters will approximately have in an average game. Initial - 0 evolution Red - 0.1 evolution Red+Green - 0.3 evolution Red+Green+Military - 0.4 evolution Red+Green+Blue+Military - 0.7 evolution Red+Green+Blue+Military+High Tech - 0.9 evolution Red+Green+Blue+Military+High Tech+Production - 0.99 evolution Then for each section I tested both offensive combat and defensive combat using the available guns and turrets and tweaked the numbers accordingly. While tweaking the numbers, I keep this in mind (this is not a complete list): Fun always wins: I prefer changes that are more fun and less annoying even if it means it could be slightly unbalanced. New weapons should be slightly more powerful than old weapons, to incentivize you to experiment. So near the end game, a rocket launcher will be better than the machine gun. Destroying biter bases is hard in the beginning and significantly easier toward the end game, to give the sense of combat power progression. Defending is not too hard in the beginning. I try not to put a new player in the situation of "you didn't prepare properly, you have to start a new game, because no matter what you do you will get killed". Then throughout the game you have to upgrade your defenses as the biters evolve. So far, the changelog looks like this. There are many numbers that were tweaked and are not included in this list. Player regains health at a much higher rate, but only after being out of combat for 10 seconds. Discharge defense equipment pushes back, stuns and damages nearby enemies when activated by the remote. Decreased the size of Discharge defense equipment from 3x3 to 2x2. Greatly increased the damage of Personal Laser Defense Equipment. Flamthrower gun has a minimum range of 3. The flames created on ground from the flamethrower significantly increase in duration and damage when more fuel is added to them by firing at the same spot. Increased fire resistance of biter bases. Increased the health of player non-combat buildings. Increased player health from 100 to 250. Increased collected amount and effectiveness of Raw Fish. Increased the damage, range and health of biters worms. Decreased health and resistance of Behemoth biters. Doubled the stack size of all ammos. Tweaked the cost and crafting time of some ammos. Increased the damage of most player ammos. Greatly increased the damage and fire rate of Rockets and Cannon Shells. Increased the collision box of Cannon Shells. Increased Tank health and resistances. Added research for Tank Cannon Shells damage and shooting speed. Tweaked research bonuses and added more end-game research for military upgrades. Greatly increased the damage of Mines. They also stun nearby enemies when they explode. Biters stop following player after 10 sec of not giving or receiving damage if the player is more than 50 tiles away. Other minor changes. As usual, these changes are not final and will probably change to some degree as we playtest more. There are still many things to be done. We are always talking about more end-game weapons, so don't worry, the combat in the late-game will be even more worry-free. There is also one thing that we always talked about trying to remove: turret-creep (destroying biters base building turrets closer and closer). This method is very powerful and usually doesn't cost anything. So far I believe that we did not find a simple, fun and fair solution. Ideas include: large power-up times(annoying and also weakens base defense); simply not allowing turrets to be build near biter bases (makes the player feel cheated); underground anti-turret worms (sugar-coated version of the previous idea). With the combat changes that were done I believe there is almost always an option to destroy bases without being forced to use turret-creep.In the end maybe your ingenuity and effort of building all those electric poles should be rewarded; If the player wants to do it that way, why not let him? Let us know what you think.