• Added interface option to adjust the number of shortcut bar rows that are visible on the screen.
  
• Added ability to shift click a research in the technology screen to start that research.
  
• Allowed setting filters with the ghost cursor.
  

• Biters and Spitters will no longer collide with other biters/spitters. more
  

• Added new remnants for several entities. They are still work-in-progress and subject to further change.
  

• Excluding runtime fluid mixing check from assembler migration that caused some crashes when loading a save with mixing in it.
  
• Fixed landfill map color on old saves. more
  
• Added migration to recalculate tile transitions when tile layer definition changes in tile prototype. more
  
• Fixed that artillery remote failure sounds could be duplicated in some cases. more
  
• Fixed that the game would still process mod dependencies for disabled mods. more
  
• Fixed that underground pipes with different length could sometimes connect one tile further.
  
• Fixed that the cursor would appear in the wrong position after textbox alignment was changed by scripting. more
  
• Fixed placement of scrollbars around textboxes. more
  
• Fixed a crash related to teleporting biters during the ai-completed events. more
  
• Fixed that non-square crafting machines without fluid boxes didn't rotate correctly. more
  
• Fixed that the game would freeze when trying to find automatic artillery targets with very high levels of artillery range. more
  
• Fixed tile ghosts sometimes overlapped on edges which created visible lines. more
  
• Fixed that the on_gui_switch_state_changed event would fire twice in some cases. more
  
• Fixed wrong damage bonus values in tooltips of combat robots and units in a different force. more
  
• Fixed that the research screen would show a technology as "available" when it was queued. more
  
• Fixed that LuaEntity::last_user didn't support writing `nil`. more
  
• Fixed that mod GUIs could show on top of the technology screen after loading a save. more
  
• Fixed a crash when using the /screenshot command. more
  
• Fixed that the --disable-migration-window command line option didn't always work. more
  
• Fixed that pumps had a drain when using a non-electric energy source. more
  
• Fixed a bug in fluid system splitting.
  
• Changed order of pipe connections to avoid previous cases of fluid mixing. A.k.a Boskid's deferred pipes.
  
• Offshore pumps now set fluid filter automatically based on produced fluid. more
  
• Fixed crash when closing shortcut selection list while dragging. more
  
• Fixed that biters could get overloaded by artillery and stop moving. more
  
• Fixed that biters could get stuck during attacks. more
  
• Fixed that biter pathfinding could cause unreasonably large save files. more
  
• Fixed that biters would attack in a single file due to their colliding with each other. more
  
• Fixed that personal roboports would function with literally no power.
  
• Fixed migrating pre-0.17 maps with detached characters that had a grid armor in quick bar would corrupt game state. more
  

• Added optional flying robot prototype property "max_speed".
  
• Added light_renderer_search_distance_limit to utility constants.
  

• Changed LuaEntity::color to also work for cars.
  
• Changed LuaStyle::padding, margin to also accept arrays of padding values.
  
• Added optional "unit_number" to on_post_entity_died event.
  
• Added support to teleport car entity types between surfaces.
  
• Added LuaEntityPrototype::call_for_help_radius, max_count_of_owned_units, max_friends_around_to_spawn, spawning_radius and spawning_spacing read.
  
• Added LuaForce::research_enabled read.
  

Read this post on our website.


In the last few weeks, we've really accelerated our work on the campaign. We've been pushing ahead a lot with both the scripting and blocking out the physical level design.One of the problems we've come up against a lot, is that we often need to perform custom edits to the map, which are quite tedious, but not common enough to add a new tool to the map editor for them. For example, something like "disable all the spawners in this region".

This kind of problem is easily solved with a little bit of custom Lua code, but getting the specification of the area we want to edit into Lua is a painful process of noting down and typing out location coordinates. It is also easy to lose track of these Lua snippets, as there is no good place to save them.

To solve this problem, we decided to add a Lua snippet tool to the map editor. This tool will let you drag your cursor over an area, and it will then run your custom Lua code on that area. The snippets are named, and saved in your player-data.json, so you can keep them around for later.

https://cdn.factorio.com/assets/img/blog/fff-316-snippet.mp4
For example, this simple snippet replaces trees with biters.

Currently, there doesn't seem to be a very big scene for community made custom maps/scenarios with custom maps, and we're hoping that the example from the campaign once released, as well as the much improved editor we have in 0.17 will encourage more people to give this a go.

As some of you may have heard, Apple is introducing a new system called notarizing to their MacOS apps. This is a system where you sign you packages and upload them to apple so they can run something akin to a virus scan, and mark it as approved. As of the new MacOS Catalina version, this will be mandatory. Our friends at Valve were nice enough to send us a warning with some info about the process. Up until now, our MacOS binaries haven't even been signed at all, so this seemed like a good time to get on that. To be clear, you could, and can play unsigned factorio binaries on MacOS, but you need to change your security settings to do so (or so I thought).

To test, I grabbed the .app of 0.17.69, signed it, uploaded it to apples notarization server, and got the notarization process to succeed (eventually). I then copied it onto a completely fresh, default settings install of macOS Catalina, double clicked it, and it ran, with no security prompt. Problem solved, right? Well, after that I decided to do a sanity check, and copied over the completely unsigned binary of 0.17.68, and it ran just fine as well, also with no security prompt.

So, at this point, it seems like we don't really have a way to test this process, so all we can do is set things up correctly to the best of our abilities, and see if it works for people. The next Factorio release should include signed and notarised macOS binaries, so if anyone has problems with 0.17.70 security warning on macOS, please let us know.This whole process has been rather slow and painful (just getting the notarizing tool working was a bit of a saga in itself), and doesn't inspire much confidence in Apple's developer ecosystem, so if anyone at Apple is reading this, please, please, make this process better.

Also to make it known again, we are still looking for a macOS developer to join our team, so if you are interested or know someone who is, please checkout the job listing.

For a long time we have been improving the biter pathing, with many iterative changes and tweaks. However we have long had a problem in the moment where a group of biters encounters the players base. I am sure the scene below is familiar to all Factorio players:

https://cdn.factorio.com/assets/img/blog/fff-316-biters-collide.mp4

This mating dance or whatever it is, has long been a thorn in our side. The reason behind it is quite logical. When moving, the biters are in a group, and everything goes smoothly. However when they see an enemy, they are 'distracted' by it, and individually try to attack it. Since the biters are now moving and pathing as individuals, things start to get messy. The biters find a path, but then there is another biter in the way, so he tries to move and turn around, but there are biters in the way there too, and each of those biters are trying the same thing, so it all goes gets clogged up for a while.

The solution we have decided, which some might consider a 'hack' is that we simply don't make biters collide with other biters. In the engine this was a rather simple change, and was already possible just using normal mods. The result speaks for itself:

https://cdn.factorio.com/assets/img/blog/fff-316-biters-no-collide.mp4

There is already some 'separation' logic in the engine to keep biters from getting too close to each other, so in the end we get away with a lot of the benefit of no collisions, without the immediate/obvious problem of biters infinitely stacking. There might be some smaller issues to pop-up with this change, and maybe some balancing tweaks to be made, but we are happy with the outcome so far.

Next week I'll be in Poland for 3 events:

• I'll be visiting the consumer expo and indie areas of Poznan Game Arena (18-20th Oct).
• I'll be going to the talks and parties of Game Industry Conference (17-20th Oct).
• I'll be attending some workshops during Game Design Summit (16-18th Oct).

If you are in the area and see a guy with a Factorio hoodie, it will most probably be me. I am looking forward to meet any fellow developers or fans attending.

Over the weekend, two of us (wheybags + Abregado) entered the Ludum Dare game jam. A game jam is an event where people make a game as completely as can be in a fixed time-frame (in this case 48 hours). We ended up making a rather Factorio-appropriate gear puzzle game. Check it out if you're interested.



As always, let us know what you think on our forum.

Read this post on our website.

We recently bought and assembled some high-end PCs, with the hope to gauge the performance, speed up running tests, and potentially consolidate the number of servers we are maintaining internally. The two lucky CPUs were a i9-9980XE 18-core and a Ryzen 3900X 12-core.



We are using the time to complete our test suite in 'heavy mode' as a benchmark. Heavy mode basically saves and reloads the game each tick, and compares a CRC of the map from before and after. It is super slow to run, but the heavy test is critical to help find any possible determinism issues. There is some more info on 'heavy mode' in FFF-63.

As a baseline, the 'standard' CPU in the office for developers is the i9-7900x 10-core, which runs heavy tests in about 530 seconds. In real time this is 8 minutes and 50 seconds, a long time for a team member to sit around for results before they can push. We can do better!

As you would expect, the new 18-core was blazing fast, with a test time of about 400 seconds, shaving off over 2 minutes. However the Ryzen was a different story, with a test time of about 600 seconds. This goes against what we predicted, where more cores and higher frequency mean lower test times. The initial results from the 12-core Ryzen were worse than from the 10-core Intel; not a good start.

So I did some digging and some research, and the answer I arrived at was RAM. When we ordered the parts, not much thought was given to the selection of RAM, just some standard 16GB 2666MHz sticks to fill all the slots. Luckily, I looked on a local Czech website, and they had some stock of the brand new G.SKILL 3600MHz Trident RGB Neo, a high performance RAM stick made exactly to suit our new Ryzen CPU. After installing the new RAM, we had a test result that better matched our expectations: 450 seconds. We knew beforehand that Ryzen liked fast RAM, but we didn't realize how significant of a difference it could make.

So now we have set up both these new machines to run tests automatically after each commit, and we are very happy with the result. The new i9-9980XE can compile and run heavy tests faster than our old i7-4790K can compile and run just normal tests. Having it run automatically also frees up individual developers from the responsibility of running heavy tests locally, so they can just push as normal and continue working.

Alongside building the new servers, we also had some new storage shelves installed in the server room. So this week I spent some time moving the servers from their old home (of the floor) onto the new racks, and moving a lot of the 'PC junk' (cables, mice, fans, spidertron, keyboards, SSDs, headphones etc.) that had accumulated around the office into the server room.



We now have 10 servers, some run tests, some do the deployments, etc. We are hoping to reduce this number in the future, as we can have 1 beefy PC do the work that is currently handled by multiple older/slower ones.

This week I spotted a Reddit post by /u/Bladjomir. It is a video of this modded base after he had respawned all the biter bases. I was really in awe at just how different the game can 'feel' once you started adding and combining mods (especially when it is coupled with the classic Red Alert 2 soundtrack). So I messaged Bladjomir asking if I could include his video in this Friday facts, and he took the time to create a brand new video for us to showcase:

https://youtu.be/Qekvxw9t7zo

As someone who grew up playing the old school RTS games, these videos really hit on some nostalgia for me. What I am really proud of, on behalf of the team here, is just how well the game supports mods. It really is just so amazing to me that we have a engine now that can be extended and overhauled by mods and just works.

There will be a time when Factorio base game is finished, when we have made the game we set out to make. Yet even though our vision is complete, anybody can come along and implement their own ideas, rework what we have done, and even (theoretically) turn off the base mod and make essentially their own new game in the engine. So in the (super) long run, I believe that mod support will be critical to keep the game and community alive, and continuing to improve the modding capabilities of the game is a strong possibility for post 1.0 support/updates.

As always, let us know what you think on our forum.

Read this post on our website.

Hello,
technically this post is the Pi Friday Facts, but unfortunately we can't think of anything special to do... maybe someone can make a combinator cake... that can calculate Pi?

We released 0.17.69 as stable this Tuesday. It seems it all went very smoothly, no avalanche of crashes, and only a handful of technical support emails about updating video drivers.



Apart from stable, essentially no development work has happened this week; nearly everyone is on vacation (I am even writing this as I sit in the airport waiting to fly to London for a wedding). We're hoping that at the start of next week, with all the relaxation over, and the pressure of stable off our shoulders, we will get cracking on the next updates with renewed energy.

In fact I might be a little optimistic in saying this, but I think we are in for some exciting times here in the team. Before now, we have always done a cycle of having the whole team on development for a few months, then the whole team bug fixing for a few months. This binary approach is what gives us the traditional 'stable' and 'experimental' labels. This is not to say that all bug-fixing would stop once stable it out, quite the contrary, but this has been the general strategy.

What we are planning, if the logistics of it turn out okay, is to have significantly smaller feature releases, containing only a handful of new features. This is to have a sort of mixed cycle, and a mixed cycle in two similar ways:

• Some developers will be on bug-fixing while others are on development.
• The individual weekly/monthly work of a developer will have a more balanced mix of development and bug-fixing.

For example, while one developer works on a feature for the next feature release, another will be bug-fixing the features in the current release. This is only practically possible if the feature release frequency is relatively high.

This new structure has been a long time brewing in our minds, and we think now is the right time to try it out. With the GUIs we really need to do quick iterations and receive fast feedback to the changes. The traditional release flow meant that we could add a new feature to the game, and players wouldn't get their hands on it for months. Then once it is released and we start getting feedback on it, extra time is spent just re-orienting ourselves to the code and how it was written. If the feedback is given expediently, the rework and improvement is much more efficient.

Furthermore, I think it is more psychologically effective to work on a mix of bug-fixing and development. This is just theory now, but grounded in some observations I have made over time.

Development work, a new feature, new GUI, etc. is generally a long-form creative process. New systems have to be created out of pure thought-matter, ideas for implementation have to be evaluated and determined, and it also involves a lot of 'background processing'. Feature development always has more room for extension, and it is very hard to say 'It is finished'. It is also quite a subjective result, so sometimes it is hard to know if you 'did a good job'.

Bug-fixing on the other hand is very short form and challenge oriented. It is like investigating a murder mystery, and really feels like a complete story. Tracking down a problem inside the game engine engages a logical part of your brain, trying to piece together and backtrace where the fault is occurring. Generally the bug has a very clear 'win-condition', and you can close the game and let your mind rest peacefully. The result of a bug-fix is grounded strictly in objective measurements, so you can be reasonably sure if you 'did a good job'.

So these two parts of the job are in a way, quite distinct and separate: Development is a long-form creative process; Bug-fixing is a short-term logical process. From all this, my reasoning is that focusing on only one for a long period of time leads to quicker mental fatigue, and that a balanced workload will keep us happier and more productive.
In essence, doing development lets our bug-fix circuits rest, and doing bugs lets our development battery recharge.

There are also some pragmatic reasons I think the smaller/quicker releases will make things move along more smoothly:

• Bug-fixes after stable will be released within a short time-frame.
• The flow of bugs coming in will be less extreme, no more massive waves with each major release.
• There will be less 'blocking', where unfinished features delay a release. They will just be scheduled for a different release.
• Feedback will be more focused, so it is easier for us to evaluate.

At the start of the year, I read a book called "Rolling Rocks Downhill" by Clarke Ching. It is a book about software project management, it was quite an enjoyable read, and gave me a lot of inspiration to try and optimize our development effort. At that time we were just wrapping up 0.17, so there wasn't a whole lot of room to make changes to the way we do things. Now that we have stabilized 0.17, and with it, completed the 'traditional' cycle, there is opportunity for a fresh approach. I guess I will give the book another read next week...

As you might know, I've spent quite a considerable amount of time playing World of Warcraft classic the past few weeks. I find it very interesting that many people (me included) find this version of the game way better than the modern version, there are many reasons for it that I see (and some that I don't), yet it deserves some small analysis as it is always better to learn from mistakes of others. By that I mean, that I wouldn't want to spend next 10 years working on better versions of Factorio just to find out, that the old ones were better for some reason.

The topic that connects it all is "Making things more convenient isn't always making things better". There are a lot of activities in life and games that we would like to remove or make more convenient, but we don't really see the hidden benefits of it. Something like making an elevator to save time and effort, and feeling bad for moving less in the long run.

One of the things in wow is nicely illustrated by in this video. When people had to gather group for a dungeon back in the days (and now in classic), they had to do it manually. They had to spam LFG (*Looking for group) channels, ask in guilds or find long-time buddies to play with. In modern wow, they made a dungeon finder that allows you to just select a role and automatically teleport you to a dungeon with the appropriate people. It seems like a great convenience. But in fact, it removes so much that it is considered to be one of the most hated feature by many people.

• When it is harder to find a group, it has also more value when the group is already assembled. This means, that people are more likely to try to overcome problems while fighting rather then just quitting and re-rolling with someone else. This make it much more interesting as it created a lot of challenges where non-optimal setup or a noob in a group forced people to learn from each other more, or just to try to overcome the problems in a creative ways.
• When you are not teleported to the dungeon and have to actually travel there, it keeps the immersion of the game, the world is there to be explored, not just an arcade where you push and play. And same as with previous point, getting there requires more effort, so the value of doing the dungeon is higher.
• And generally, having more dungeon runs in the same time doesn't make it feel like you accomplished more in the game, as it generally just lowers the value of one run. And all this for the cost of it all being way more mechanical.

Another big example is level scaling. The idea is again nice, to make it more convenient. With level scaling, monsters conveniently scale to your level in the zone where you are, so you can quest at any place without having to avoid too high or low levels areas relative to your level.. But I consider this to be actually plague of any game where it appears. Instead of zones, their levels and your level meaning something, and the progress being clearly visible every level, suddenly it all disappears. The world isn't a place to explore, but rather arcade-like place that all resolves around you. Your level doesn't mean much, as it being too low isn't a problem anymore. The moments of having to run from areas where you are too weak to get back later are one of the most important in RPGs, and suddenly they are gone. The progress you see in games is like looking from a window of a train, if the train moved and the landscape moved the same way, you wouldn't feel like you are moving at all.

There are much more lessons learned while playing the game. Not only the mistakes made in modern version, but also lessens of good game design obviously. How could these be related to Factorio? I believe that on the deeper level, there could be a lot of parallels.

• Getting first mount at level 40 for 100 gold? You have to walk a lot before you get it and it might feel annoying at times. But when you actually get it, it means A LOT. Similar as how it is a game-changer to get construction robots/logistic robots/power armor. Getting there isn't easy, and there are certainly a lot of moments where you/we feel like having these sooner might be more convenient. But it would just decrease how great and valuable upgrade it is.
• We were thinking about a belt building tool, similar to the rail building tool. It would just connects ends, and even find underground connections etc to get to the point of destination. It would be super convenient. But suddenly, solving the belt puzzle wouldn't mean much, and having the belt factory would feel like much smaller accomplishment.

Anyway, thanks to all of you for such a great year so far, thanks to all our friends on the forum and throughout the community who have helped us in the great bug war of 0.17, and as always, let us know what you think on our forum.

Read this post on our website.


It has been 6 months and nearly 70 releases since we first launched 0.17 to the world. Now is the time to let is be enjoyed by all the players of the game. We are going to be continuing our work on 0.17 over the next few months, with small experimental releases of new features, and finishing all the GUI reworks.

The new map editor can be accessed directly in-game with the <tt>/editor</tt> command. Packed with new features and improvements, such as cloning tools, multiple surface support, and time control. The new editor also allows collaborative map editing in multiplayer. More details: FFF-252.

The enemies in the game, the native inhabitants of the planet, have received a major facelift in this update. As well as a graphical overhaul, the attacks and balancing of the spitters and worms has been revised, incorporating skill-based elements and some tactical decision making. More details: FFF-268, FFF-279.

Now when trying to join your favorite server, you can directly sync your mods with the server from in-game, and automatically join once they are all installed. This massively reduces the friction for joining modded servers. The in-game mod browser has also been redone to help find new mods and manage your installations.

We have massively optimised (and parallelized) the fluid update in 0.17. In effect each section of pipe can be updated independently of other pipe sections. This comes as welcome news for any megabase planners out there. Furthermore we have limited each pipe section to only a single fluid, and will actively block any placement that could mix fluids, to prevent the catastrophe of mixing water into your oil system and bricking the whole system. More details: FFF-271.

This release has a completely new rendering backend, written almost from scratch to our exact requirements. The new engine takes advantage of more modern GPU features and is highly optimized. What this means is that the game can now work with much less VRAM and allow players with older videos cards to still enjoy the game in high resolution at 60 FPS. More details: FFF-251, FFF-264, FFF-281.

Due to the more modern architecture, some issues may be present with certain hardware configurations, please see this forum thread if you experience any graphical problems.

We have added a completely new introduction scenario on a hand crafted map. It gives new players some simple goals and provides a place for them to experiment with a smaller toolset than Freeplay allows. The scenario is open ended, so that players may experiment with larger bases. A separate techtree is provided for this purpose which includes some infinite research. Our companion robot, Compilatron, is also present to help guide the player. More details: FFF-262, FFF-306.

We have added some powerful shortcut keys, which use the intuitive layout we are all used to. Now you can undo your last action by pressing CTRL + Z, quick equip a cut tool with CTRL + X, do quick copy/paste actions with CTRL + C/CTRL + V, and assign robots to upgrade your factory with the new Upgrade planner. More details: FFF-255.

We added a new GUI skin, along with the first batch of GUI reworks. The new GUI aims to unify the look and feel of the game, and provide a consistent visual basis for the players interactions with the world. More details: FFF-243.

As always there are a ton of smaller features and changes to discover in this latest major update. You can read the changelog in game for a full rundown, or checkout the release notes here.

We have our plan moving forward for the next version of the game, which you can check out here.

Read this post on our website.

Hello,
We have had quite a peaceful week here in the office.

Last night we went out for a burger and a beer as a last meal with Ernestas before he flys back home for another few months. It was also quite nostalgic, as we went to a place that we used to go to frequently near our old office, and the staff still remembered us.

It seems our 'news' of some programmers taking a break made headlines this last week: Work slows on Factorio while a dev “levels his priest” in WoW Classic.
Even though he is still not level 60, Kovarex found some time to fix a few more bugs, which seemed to go very smoothly, as he is feeling super recharged.

We also had Boskid come to visit the office, and he helped us do some intensive testing and test writing. Working together with Dominik, the two managed to find and fix a lot of bugs related to the fluid mixing system. It was certainly more efficient having someone doing QA inside of the office, so it seems our team might be getting a bit bigger.

With the last 'blocking bugs' resolved, the bug war is almost at a close. The count on the forum is down to only 16, and the automatic crash reports are looking okay:



We have released version 0.17.69, we are optimistic that this version may be able to be called stable. While this is almost over 1 month after our first 'stable candidate', we are confident now that this version is more stable than 0.16.

In last week's FFF we presented the new landfill terrain. We felt relieved by having another task done in GFX.
One of the first reactions in our forums was the idea by eradicator of rotating the grid to 45°. It followed a fast mockup made by ThreePounds. The idea was good, and apart from us, some people on the forums agreed.

The modification of our sources to get this rotation done was very affordable to us, so we decided to make it official and here we are now presenting it:



This solution is nicer than the 90°'s one because basically it doesn't interfere with the tile grid of the game, and provides a nice loose space feeling in the general composition. I just felt a bit guilty for not coming with the best approach from the beginning, but luckily our community is very keen to give us feedback on any aspect of the game.

Thanks guys for the feedback.

As always, let us know what you think on our forum.

Read this post on our website.

Hello Factorians,

Today I would like to talk to you about my favourite subject - fluid mixing and its prevention. It is a new mechanic introduced in 0.17 that seemed quite simple at first, but has been giving me nightmares ever since.

A while ago I took on the task of updating the fluid system (FFF-260). The way it works in 0.16 is that the fluid boxes (the thing that holds the fluid and is contained in entities like pipes or refineries) had no organisation whatsoever except their connections. They would sit there and do nothing and then once per update send fluid somewhere. It had it's issues especially with symmetry, and when you happened to put some fluid where it did not belong, you could end up requiring major demolition works.

My task was to develop a better algorithm to move the fluids, and a very very optional side task I had in mind was to do something about the fluids getting to wrong places and mixing. We started by organizing the fluid boxes into systems (connected FBs make a system) managed by a special fluid manager, and optimizing the heck out of it (FFF-271).

Soon after, I started working on the new algorithm and anti fluid-mixing. Until then nobody really considered preventing the fluid mixing seriously as it did not seem possible. But when I thought about it, it did not seem that hard. The idea is to simply not allow any action that would lead to fluids getting where they are not supposed to go. When you build a steam pipeline, you should not need nor want it to touch another fluid.

In principle, it would only require a few quite realistic mechanisms:

• A connected block of fluid boxes would either be fluid-free, or it would be locked to one fluid.
• Two such blocks can connect only if they are compatible - either one has no fluid lock, or they have the same fluid.
• An assembler can only set a recipe if it is compatible with the fluid locks on its fluid boxes.
• Have a migration from old saves that can contain mixing.

By creating the fluid systems right before, number 1 was almost finished and we only needed to assign the lock. It would be set either by a fluid, or by a 'filter', which is a fluidbox that is set to use a fluid - such as a water pump using water, or assembler having some inputs/outputs given by a recipe.

After a while I had both the fluid algorithm and the mixing done (FFF-274). The mixing was not that easy (like 5x more complicated) but it worked pretty well. As for the fluid algorithm, V453000 and Twinsen found some issues with waves on a macro scale, and because it was right before releasing the 0.17 experimental, we decided to hold it off on it for the time being (we have a new version now that seems okay, but has to wait for 0.17 becoming stable first). The mixing made it through though and seemed quite finished.

It turned out that the work on it was at most one tenth complete.



Some difficulties appeared already before the initial release, but that was only a hint of what would come later. One by one, then ten by ten, bugs started coming. The problem is that as often as not, they were not just little issues with simple fixes. Instead, over and over, they turned the current solution on its head and the code had to be completely rewritten in order to account for the new case. As of now, almost exactly half a year and many rewrites later, it is still not fully bug free.

The number one issue was with Assembling machines. It turned out that their code was pretty messy and does not simply allow the checks I needed, so it had to be refactored. The next problem was that the check was not only required when setting a recipe on an existing assembler - as I naively thought - but in about one million different situations I would not dream existed. Building a fixed recipe assembler. Reviving an assembler. Rotating. Blueprint of an assembler. Blueprint with a recipe and a rotation placed over a ghost with a non-default rotation during a full moon. Teleport. Script building. Copy-paste settings. Any combination of these.

Pretty much every case would go through different paths in the code and behave entirely differently. Fixing one would break another and so tons of tests had to be written. When these cases finally worked, it turned out that doing these operations when they fail (e.g. can’t rotate because it would cause mixing) brings another wave of issues. And then mods come and the complexity multiplies. All this, although in a more simple form, had to be done for all other entities that can use fluid too, such as inserters (mods...).

Another number one issue are underground connections. When playing, you would not think twice about them but on a closer look they are all but simple. They have this (cough) uncomfortable feature (want to shoot myself) that you can build another underground pipe between them (or take it out) and a complex reconnection logic jumps in. It means that based on building order, connections are established and reestablished differently. This is a big thing when building a blueprint with many pipes, or loading a save game.

But the largest issue is one tiny corner case with huge implications. Have two underground pipes that have different fluids, but are split by a third, and it gets removed. Until now mixing was theoretically completely avoidable, but here it was and there was nothing to stop it.



As a result, a new concept is introduced - a blocked connection. An underground connection that would normally connect but can’t. Establishing it is the easier part. But when does it get fixed? An entity miles away gets rotated, that splits a fluid system, disconnecting the blocked connection from a fluid filter on the other side, and the connection should unblock. But even something as simple as a rotation contains fluid fixes and re-establishing of fluid boxes and if it fails, it still fixes the blocked connection in the process and it can’t be undone... You get the picture. And we are still talking about underground pipes, while anything can have underground connections, including said assemblers, which the previous code did not consider at all. The complexity just goes deeper and deeper, and Rseding is probably right that we should have never gone this way at all.

So the bug fixing has been basically running in circles - clearing one batch of bugs, thinking that those were the last ones and the ordeal is finally over, only to find another batch (ideally from some bizzare modder idea) a few days later. Many times I wished that mods never existed. Nor multiplayer, or any players at all for that matter. About two months ago all seemed really fine, with basically no reports and just a few crashes in the automated crash reports.

At that moment another nightmare materialized in the form of a talented volunteer bug tester named boskid, who took on a personal crusade to break the fluids to dust (I actually imagine him sitting in his dark room with evil laughter, dreaming about making my next day worse than the previous). In all seriousness, he has done a great deal of work with his bug testing, creating bizzare modded cases and testing scripts, and deserves a big thanks. He is actually coming to our offices next week, so follow the news for reports of developers falling out of windows.


An example of a nice configuration he found (and I can’t fix).

The whole time we were taking the offensive approach to mixing - crash the game when it happens - so that we know about bugs to fix them. Recently we have decided to put a stop to it and have the mixing automatically fix itself once it is detected, eyeing the end of this episode. Right now I have 3 mixing bugs on the list and I am sure those are the last, and mixing will be done (lying to myself is a way to cope with it) and the new fluid algorithm can come soon after :).


(And of course, boskid found a way to use the automatic mixing fixing as an evil PVP tactic.)

This week Ernestas came physically to the Wube office to spend some time with us (he is normally working remotely), so we are taking the chance to finish things that we had in the drawer that needed closer communication. One of those things is a specific terrain for landfill. As you know we were using grass for it. Not anymore.



In Factorio we have a clash of two worlds:

• The natural and organic planet. Off-grid with multiple terrain types, trees and doodads.
• The world of the factory, which is mathematical, regular, modular, and totally attached to the grid.

This new terrain represents a boundary in between those two worlds. The grid on its surface tries to express the artificiality of it, like mechanically pressed with some sort of industrial stamp. The imperfections of the grid and its irregularities are holding this man made terrain into the realm of the natural environment.

For now the sound of the landfill action is not solved, 'soon' we’ll take care of it.

As always, let us know what you think on our forum.

Read this post on our website.

Hello,
Another week has elapsed, which brings us another week deeper into the declining weather of autumn.

In FFF-288 we proposed that we are considering multiple approaches to remnants, and in FFF-293, we described that we are choosing the balanced solution which does not obstruct the movement of a player if an entity is destroyed. We have recently finished quite a few which we would like to show you.



Compared to some of the early versions of remnants, you can now really recognize which entity got destroyed.

If you have been following the progress of remnants in 0.17 experimental versions, you have probably noticed that a lot of them have been changed quite drastically. In general we are trying to hit the balance between having the remnant look destroyed enough, yet still very well recognizable which entity it was.

This is especially difficult for tall entities as the player has to be able to walk over their remnant, the extreme case being train stop for which we are also implementing a special solution...

Train stops are recognizable because of the top coloured part, and the tall scaffold that holds it. Giving the station a colour mask was trivial graphically, but our dear posila needed to add a bit of code to support remnants to have colour masks. Keeping the tall tower is a bigger problem as if the tower is a part of the remnant sprite, the player would be able to just walk over it, and trains would always show on top of it as well. We chose to split the train stop remnant into two layers so the illusion of height is kept.



We also used the colour masks for basically everything the player has the ability to change the primary colours of. It includes the Locomotive, Turrets, Car and the Tank. Once the entity dies, the colour of the given entity stays with the remnant.

We have updated the wall sprites as well, as we wanted to make the walls more like broken walls instead of random rubble, to break their line less. The walls are by far the most destroyed entities besides turrets so they can look repetitive quickly. To improve this, wall remnants have several sprite variations.

Compared to 0.16, whenever any entity gets destroyed, the player can tell which entity it was. We believe this makes rebuilding your factory much more fun, and seeing your things get eaten less frustrating. On top of that, we plan to utilize the remnants to a large degree in the campaign for 1.0 for half-destroyed factories to be found and explored.

We will be adding more remnants and improving some further to make this effect even greater than it is currently in 0.17.

In the past month I had the opportunity to balance test an overhaul mod called Industrial Revolution. Now, after around 1,000 hours of development, Deadlock has finally released the mod to the public today. In the around 65 hours I have spent playing the mod, I fell in love with it and I want to present it to you here.


Click to see full resolution
My current base, machines from all ages forming one big factory.

The mod gives more depth and length to the vanilla experience by changing the progression throughout the entire game. You work through ages of technology, always chasing the milestone of the next material. Just like in vanilla, you start out with the stone age and classic burner machinery. Automation is key, even in the stone age; the mod adds new intermediate products to all crafting steps. To allow automation at this stage, the mod provides burner assembling machines and labs.



However, instead of getting to power as soon as possible, the next goal is bronze, an alloy made from the two starting resources, tin and copper. After improving the factory with bronze machines and automating logistics science packs, the iron age is not far away. With it come steam power, oil processing and trains, allowing rapid expansion of the factory. The steel age unlocks better ore refining techniques and powerful machinery, paving the way to the rocket. Beyond the ages, the mod introduces new types of turrets, each with their advantages and disadvantages. On top of all these gameplay differences, the mod boasts incredible graphics and good sounds.



When I started testing the mod, I was expecting a long-ish casual playthrough with some different recipes. What I got instead was an addiction and a huge appreciation for the concepts the mod adds and changes: Different challenges, more logistic puzzles and completely new recipes refreshing the whole experience. The extended burner phase in the mod introduced an unconventional problem to me: Fueling burner inserters and assemblers. Combined with my spaghetti approach and limited space due to the enemies lurking in the desert around me, fueling inserters became a challenge that I spent hours on.

My proudest creation is an electric motor assembler, it needs four inputs, all supplied by burner inserters that need to be fueled by other inserters. The assembler stands to this day:



Another great change by the mod is how it deals with ore processing. Ore processing allows the player to improve how many ingots can be produced from ore, up to producing twice as many ingots. This happens in steps, every age introduces a new technology to refine ore. So, getting more iron means building an extra ore processing step and simply connecting it between the last processing step and smelting. Each refining setup has its own challenges such as multiple outputs or needing a catalyst, so it becomes an interesting puzzle to get more ingots. The new ore processing flows well with the rest of the game; often times I found that I needed an ore refining byproduct and more ore refining at the same time. This is a big improvement compared to the vanilla way of getting more plates: Mine yet another ore patch and smelt it in the same old boring way.


Click to see full resolution
Gold being mined, crushed and purified to increase its yield before smelting it, all in the same area.

Of course, adding more intermediates also means that you run the risk of only ever needing a product for one other recipe. The mod manages to avoid this pitfall, I find myself routing belts and pipes through half the factory because an item is needed in multiple different places. Another possible problem is the long burner phase, it could delay automatic construction. This is prevented by the addition of very early personal construction robots. The clockwork punkbots can be used with an automatically refuelling burner generator that fits into heavy armor, all available in the bronze age.

Vanilla’s boring defenses become more varied with the new turret types. The first turret you unlock is a bronze scattergun turret, it works similarly to a shotgun. These turrets are great at taking out groups and still make up a large part of my defenses. However, their range is lower than that of medium spitters, therefore minigun turrets and laser turrets guard my more commonly attacked areas.



All in all, the mod overhauls vanilla to provide fresh challenges, is well balanced and on top of that nice to look at. I hope you will have as much fun playing the mod as I did, so try it out now that it is released (Mod portal page).

As always, let us know what you think on our forum.

• Pressing ESC while catching up to a multiplayer game will open the menu with most options disabled. more

• Fixed migration bug that doubles up to one sample worth of statistics when a save is loaded from before 0.17.44.
  
• Fixed production statistics not calculating the totals correctly. more
  
• Fixed that on_built_entity wouldn't be fired for built blueprint entities. more
  
• Fixed a crash when right clicking with the map editor tile area tool. more
  
• Fluid mixing does not crash the game anymore and is fixed the same way as on migration.
  
• Fixed some Lua tables would be incorrectly interpreted as Lua arrays. more

• Changed pipe_covers to be drawn with secondary sprite draw order 64 resp. -64 to prevent "z-fighting" issues. more

You can get experimental releases by selecting the '0.17.x' beta branch under Factorio's properties in Steam.

• New chemical plant graphics.
  
• Heat pipes (also in reactors and heat exchangers) glow with high temperatures.

• Pressing ESC while catching up to a multiplayer game will disconnect instead of opening the menu. more
  
• An entity can't be teleported into a position where pipe connections would overlap. more
  
• The camera will zoom to center instead of zooming to cursor in God controller, Ghost controller and Spectator controller.

• Added an area tool to the map editor tile editor.
  
• Added highlighting of the source entities when selecting areas to clone in the map editor.
  
• Added a setting in the map editor to hide entity health bars.
  
• Added a setting in the map editor surface editor to generate new chunks using lab tiles.
  
• Added support to manipulate items on the stored character while in the map editor.
  
• Added infinity settings for automatically controlling items in the map editor.
  
• Changed the infinity chest so it can also spawn hidden items.

• Rearranged key-bindings in Control Settings to different categories. Improved and added more descriptions of key-bindings.

• Fixed cloning ghost entities with rotation didn't work correctly. more
  
• Fixed that the lab GUI wouldn't update when the technology being researched changed. more
  
• Fixed loader front patch and back patch were not sorted correctly when drawing. more
  
• Fixed wire connection distance sometimes being inconsistent. more
  
• Fixed a rotation of modded pump with regard to blocked pipe connections. more
  
• Prevented a crash resulting from teleporting a pipe to a fluid system with blocked connection. more
  
• Fixed that the filter GUI tooltip would flicker when changing tabs. more
  
• Fixed fluid mixing from creating an underground pipe by script into a blocked fluid system. more
  
• Fixed fluid mixing from copy/pasting an infinite pipe next to a different fluid. more
  
• Prevented playing Jesus and changing water into other fluids. more
  
• Fixed assembler ghost fluid filters disappearing through loading. more
  
• Cliffs sections which are fully marked as indestructible can't be exploded. more
  
• Fixed interaction of underground pipes with modded length. more
  
• Fixed fluid mixing caused by fluid producing furnace. more
  
• Fixed that opening the technology GUI in the same tick as the entity tooltip being shown didn't work correctly. more
  
• Prevented rotation of a modded assembler with a blocked pipe connection that results in fluid mixing. more
  
• Fixed train condition button indentation not being properly updated under special circumstances. more
  
• Fixed that train schedule waypoint was considered to be passed when train departed the related rail rather when it entered it. more
  
  
• Fixed that storage tank entities ignored pipe_picture property in their fluid box definition. more
  
• Fixed improper action selection for UI actions for key bindings differentiated by modifiers only. more
  
• Fixed a crash related to a modded assembler and fluid mixing. more
  
• Applied the cannon shadow to the artillery wagon, fixing some unintended highlights. more
  
• Fixed crash when removing electric pole. more
  
• Fixed event handler could try to register events twice in some cases. more
  
• Fixed blueprinted locomotives would preview as snapped to train stop. more
  
• Fixed items spilling on the ground when using fast entity transfer while robots are trying to insert into the player. more
  
• Fixed hand reserving a non-empty slot in some situations when player inventory auto-sorting is disabled.
  
• Fixed custom lua slider sometimes initializing with the marker in the wrong position. more
  
• Fixed "list-box" and "drop-down" custom GUI elements would not update selected index when changing its items programmatically. more
  
• Fixed that the map editor 'instant blueprint building' would fail to place trains correctly.
  
• Rail signal that is to be reserved by circuit network doesn't allow train to go through even when the block is already occupied by the given train. more
  
• Rail signal will change from reserved by circuit network state to closed state when train is manually placed into the block it guards. more
  
• Fixed train stop name in map not being positioned properly. more

• Changed default value of LoaderPrototype::structure_render_layer from "lower-object" to "transport-belt-circuit-connector", in order to be consistent with other on-belt structure sprites.
  
• Different wall types will connect visually by default. If this behavior is not desired for a wall prototype, set it unique "visual_merge_group". more
  
• Added optional random_variation_on_create to all simple entity prototypes.
  
• Pump was changed to not expand its bounding box when connected to pipe. Collision box for vanilla pump was adjusted to reflect this change.

• Added additional filtering to LuaGameScript::get_filtered_..._prototypes() functions.
  
• Added optional "tags" to entities in blueprints and entity ghosts.
  
• Added optional "tags" to script_raised_revive, on_built_entity and on_robot_built_entity events when reviving ghosts.
  
• Added LuaEntity::tags read/write for entity ghosts.
  
• Added LuaItemStack::get_blueprint_entity_count(), get_blueprint_entity_tags(), set_blueprint_entity_tags(), get_blueprint_entity_tag(), and set_blueprint_entity_tag().
  
• Added on_force_friends_changed and on_force_cease_fire_changed events.
  
• Added "area" to on_chunk_charted and on_sector_scanned events.
  
• Added "position" to on_chunk_generated event.
  
• Added area to the LuaChunkIterator operator() return value.
  
• Added LuaPlayer::toggle_map_editor().
  
• The script_destroyed_entity event is raised for map editor instant deconstruction.
  
• Added LuaEntity::tick_of_last_attack and LuaEntity::tick_of_last_damage write.

You can get experimental releases by selecting the '0.17.x' beta branch under Factorio's properties in Steam.