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.

Read this post on our website.

WoW classic has been released, which means several of our top men have taken time off to spend hours raiding and having fun in Azeroth.

This isn't great timing, as a few new bugs related to train signals appeared. We want to get these bugs solved before we do another release (another stable candidate). As it turns out, the only person with the skillset to fix these specific train signal bugs is also deep into levelling his Priest...

We are still making the rest of the preparations for the stable release. We have started writing up the stable annoucement blog post, and have produced a 0.17 postcard image. Other than the few more critical rail bugs, there doesn't look like there is much else to block the stable release, on the forum we are down to 27 bugs.

Since there are so few bugs left to deal with, some of the team has starting working on 'post-stable' features. Wheybags is working on the new campaign, Oxyd is diving into some detailed pathfinder improvements, and Rseding has started work on some particle optimizations. We will delve deeper into these topics and more in future FFFs, as we always love to do.

Heat pipes were released with 0.15, since then, we (the GFX department) contracted a debt with this feature. The original plan was to be able to visualize the amount of heat by using a glow on the pipes. Due to the tight schedule of the 0.15 release we decided to postpone the feature.
Finally Ernestas took care of it, and we can proudly present it integrated in the game.



As you can see, the pipes emit light due to the red hot metal. The fact that they are connected to the reactor and the heat exchanger, made us make some extra patches. It would look wrong if the heat pipes were glowing, but the pipes on the reactor were not. The final result apart from beautiful is also very readable for the player, which is the main point of the entire design.



The glow intensity is proportional to the heat. Now the visualisation should be crystal clear. The new graphics are already merged into master, so will be included with the next experimental release.

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

Read this post on our website.

The boring phase of bug-fixing is still going, slowly but surely. Stable should be released next week, but with some people on vacation (Ben, Jitka, kovarex, Klonan, Sanqui) and with the release of WoW Classic, it might get slowed down a bit. (By the way, some of us will be playing on Pyrewood Village, Alliance, so if you want to have the chance of meeting Twinsen, kovarex or dominik while leveling, you can join that server).

So since there's not much happening, this week we decided to explore some unpopular or controversial opinions about the game from within the team.

In Wube we don't have a very strict management structure, everyone is free to have ideas and opinions about almost all aspects of the game. This means that with almost every change we argue and discuss a lot before making a final decision. Sometimes we argue about everything, from the smallest GUI change, to how a major feature should work. This is probably not a bad thing since this means changes are usually well thought out and unpopular ideas or changes don't make it to the game very often. Some people feel quite strongly about their opinions or sometimes the team is very divided on what should we do. Today we'll share some of those opinions and controversies.

Keep in mind that these are simply opinions and none of them will actually make it into the game, we are simply sharing them to have an interesting discussion.

What I always liked about Factorio is that it's a very precise game. Ratios, throughputs, crafting times are all well explained and even if it gets complicated, everything can be calculated to the last item. Miners mine resources at a precise rate, smelters and assemblers craft items at a precise speed, belts move the items at a precise throughput. But inserters... due to their behavior where they track items on the belt before grabbing them, they don't have a precise throughput. This really grinds my Iron gear wheels, as it's hard to even know if an inserter will be fast enough to load a simple assembler. There are Wiki Tables and References, but they are ridiculously complex since it depends on the inserter type, source, destination, belt type, belt orientation and inserter capacity bonus. Even after accounting for all that, the numbers are still not precise since it depends on timings and how items are placed on the belt.

My proposition is to remove this complex movement of item chasing and have inserters move to their predefined pickup location and immediately pick up the closest item (in the case of a belt).This will:

• Make inserters have a constant throughput. It will still depend on some factors like stack size (e.g. stack inserter will pick up faster from chest than from belt), but it should simplify things significantly and allow us to have a calculated throughput for chests and belts that we can show in inserter tooltips.
• Prevent all the issues with inserters getting stuck (e.g. burner inserters running out of fuel because they chase items they can not grab). We often argue if this is a bug or not and if it should be fixed.
• Improve performance (maybe significantly). Inserters currently chase items throughout it's entire swing, tracking the items on the belt each tick and searching for a new item each time one goes outside the belt (which happens quite often for blue belts). Removing this requirement would mean less memory access to other entities and much simpler mathematical calculations. Since inserters are the second most common built entity, these improvements could lead to a big UPS boost.

But on the other hand, this will mean:

• It will graphically look much worse. While I believe we can do many things to make this look good enough (by separating drawing animation logic from game logic), it will probably not look as nice as it does now.
• It will remove some of the nice organic feel of the game. And it will remove some (arguably) fun emergent situations.

Combine this with the fact that changing something so core to Factorio in such a significant way would have big implications. So we decided this wont be done.

The blueprint library has always been a controversial topic. We argued about how it should work technically, in multiplayer or if it should exist at all. But one thing that I particularly don't like is blueprint import/export. It's obvious that it's more fun to make your own setups and it's probably universally agreed within the team that importing large sections of factories is not what players should do. This promotes "instant gratification", it eliminates the satisfaction you feel after finishing your creation you spent hours tinkering and planning. And could easily make a 100-hour game into an 10-hour game. It's sad when we release an update and the first comment is "does anyone have the blueprint string for the nuclear reactors" or someone immediately asks for an artillery shell production blueprint.

It's our job as developers to incentivise the player to play the game properly. If importing blueprints is obviously so bad, why are we providing this tool as a vanilla tool? Not only that but we also place it in the "tools" section, as a shortcut in the main screen, as if you are expected to use it often.

So my proposition is that this tool should only be modded in. By making it a mod it's clearly not a an intended way to play.The very common counter argument is "since it's obviously not fun, players won't use it. Put it in and let the players decide". That's like putting a "level up" button in an RPG and saying "well it's obviously not fun, it skips content, players won't use it, but let them decide". Yes they will, as soon as they encounter a problem a player will evaluate his options. A tempting "skip-ahead" button is irresistible in such situations.

It's hard to remove such a powerful tool now, since it's oh-so-tempting to import that nice blueprint book with belt balancers, so you don't have to deal with designing those complex things yourself. Until a different consensus is reached, the tool will stay in game. But I urge players to restrain themselves from adding too many blueprints to their library that are not their own (or their friend's).


Weapon lock on and the distinction between shooting with spacebar and C is a constant source of confusion for new players. Also, it is just weird and not even fun. Weapons should all work like the shotgun, you point and shoot, and the bullets hit whatever is in that direction. There's only one button to shoot, and that can be spacebar. We could take inspiration from the huge number of top down shooters out there to figure out satisfying weapon mechanics that would work with this new style. Even if you don't like this style, we already have it for some weapons (shotgun), and using it for some weapons but not all is inconsistent and confusing. (Klonan made a mod a while ago which does something like this).

Currently, you can get by with only walling off part of your base, responding to attacks as they come, and leaving the rest fairly open. This runs opposite to what "most new players" [citation needed] would expect. For example, I always started off by walling and turreting my entire base, presuming that if the biters noticed a part of my perimeter that was uncovered, they would just go through there. The counter-argument is that it makes the game less fun, because you spend way too long building massive defensive walls instead of making your factory. My counter to that is that for a lot of people, making defenses is very fun, everyone loves turtling in RTS games. Maybe it's just my play style, but this is what I was doing anyway even when it's not necessary, and leaving big holes in my walls just feel wrong. IMO if you don't enjoy that, you should just turn off biters. Also related is the way that biters will sometimes ignore your structures, if they are not polluting or military. For the same reasons, I think you should have to defend your railway lines, power poles, etc.

Related to the point above, I think that clearing the bases inside your pollution cloud should provide only a very temporary respite from attacks. Biters should very regularly expand back into your pollution cloud, meaning you always have to defend. Alternatively, the whole pollution cloud mechanic could be removed, and replaced with a worldwide pollution count.

Every other interaction between a belt and a building uses an inserter to move the items to/from the belt. Why are miners any different? From a pure consistency point of view, I think this should be removed. As far as I know, the reason it has been left this way so far is just convenience. (Bonus fact: I used to put inserters in front of my miners for an unspecified-but-way-too-long time when I was new to the game).

During our in-house testing, one of the things we did was invite people who had never played the game before into the office to try the new introduction campaign, while we observed them. One stumbling block that almost every person hit, was connecting their steam engine to the water output of their boiler, instead of the steam output. I understand that the current setup allows for some interesting layouts, but IMO it is not worth the usability cost.

Pipes and fluid have been a constant annoyance for a long time. Thanks to the labours of another of our developers (Dominik), this has improved greatly, and is due to improve even more. However, if I had the choice, I would just remove the headaches outright, by making pipes function like magic liquid teleporters. Each "pipe network" (a block of connected pipes) would have a set of inputs and outputs. The load would be drawn equally from all inputs, and distributed equally to all outputs. Of course, this would mean that there would be no flow limits for pipes. So you could, for example, have a massive array of offshore pumps connected via a single pipe to a large nuclear plant, and it would work just fine. There would also be no way to visualise the flow, so the windows would have to be removed. IMO, the cost is worth the gain.

I can't get my wife to play Factorio with me because she's not really that into Factory building.But she and I have been playing Satisfactory because it gives herreasons to explore the map and discover new places and collect items.

The obvious change that could be made to Factorioto accomodate that play style would be to scatter useful itemsaround the map.I imagine things like an abandoned railyardthat would give one early access to a few prebuilt enginesand rails, totally changing the way an early factory is designed.

But there is a second aspect leads to Factorio not being very exploration-driven,and that is that you can see ridiculously far and nothing obstructs your line of sight.Who needs to explore when you can just plop down a few radar towers?Forests would be much more meaningful if you couldn't see through them,and had to actually poke around and through them to know what was there.(I personally take inspiration from Ultima 3for line-of-sight calculations in 2D games).

And speaking of line-of-sight-blocking terrain features, we also need mountains.Not just rows of cliffs, but large and impassiblemountain ranges that compliment the impassible (but non-sight-blocking and land-fillable)bodies of water.

Games with a first-person perspective automatically give you the line-of-sight effect.Another thing that true 3D game engines give you out of the box that 2D onesusually don't is the possibility of non-planar worlds.Bridges and tunnels can provide alternate (or secret) routes and interesting loops.But it is possible to get some of the same effects out of a 2D engine.Since Factorio already supports multiple surfaces, it wouldn't be too much of a stretchto add a cave system (preferrably with an odd topology) underneath the surface surface,with entrances in mountain sides.

I'm not sure that making vanilla Factorio more fun for peoplewho want to focus more on exploration is itself controversial,but all these features take time and energy to build and maintain,and "Factorio isn't supposed to be about exploration",so it hasn't been a priority.

In my estimation, the main cause of bots becomingoverpowered in late-stage factoriesis that they take up zero space(large amounts of logistic or construction bots can occupy a single point on the map)and take zero time to pick up or drop items or to deconstruct things.This leads to the following:

• Laser-turret-creeping enemy bases is trivial because construction bots can instantaneously place enough turrets to completely overwhelm all the biters.
• There is no reason to mess with belts at all when bots can 'teleport' unlimited resources between storage chests.

Buildings taking time to construct (such as they do in games like Total Annihilation)would to some degree solve the first problem,since an already dug-in force would have a chanceto defend itself while turrets are being built.

Bots taking up space (so that they have to queue up to pick up and drop off items)would solve the problem of bots completely obsoleting belts;to transport large numbers of items quickly you wouldneed to spread out the pickup and load boxesto give the many robots space to work.

The main reason we're not doing this is that bot movement logicis currently written such that calculations are needed only when something changes(a robot completes its task, its target is moved, etc).Having to keep bots separated would add a lot more calculationsthat need to be done while a bot is en route,which would probably result in a lot of complaintsfrom people with huge bot-based factoriesthat the game got all slow.

Similar to the overpowerdness-of-bots problem,being able to carry multiple locomotives (or rocket silos)around in a backpack or in a train car feels silly.Big things should require time and space to move around.

Solving that would require completely changing how construction works—large things would have to be built on-site a la Total Annihilation or Satisfactoryinstead of being preassembled.But that could lead to its own interesting situations.Some objects would require more resources than can fit in a standard stack,so special assembly buildings would be needed.

There are mods(such as Rocket Silo Construction)that try to do this with certain buildings already.

I believe it is alright for a game to have power-user controls that are not bound to any keys by default. For example "Toggle exoskeleton" introduced with a 0.17's toolbar is a feature that most people probably will never need, and lot of people won't even realize it exists. It is probably useful for some people, and it also useful that it can be toggled by a hotkey, but it doesn't need to be bound to any keys by default. People just get confused why they run slow when they press the hotkey by accident, even if they knew about the feature, but don't actively consider its existence.

I think if we changed our attitude towards default keybindings we could go nuts with adding new shortcuts and there would be little bit for everyone. I mean, how many people use hotkeys for connecting or disconnecting trains, and how many people would use a shortcut for toggling manual driving in trains.

In Factorio the game makes a large effort to not punish the player for experimenting: you can mine up anything you build and move it somewhere else or just try different setups. The game doesn't punish the player for this (or so most people think). You can hand craft things and if you change your mind just stop crafting to get the ingredients back.

When it comes to furnaces and assembling machines this is different. Anything which is in-progress when you mine a furnace or assembling machine is lost. If you had a Kovarex enrichment process running with 40 Uranium 235 and you mine the centrifuge the game deletes all 40 of the Uranium 235 and you're left with nothing.

In a previous version of the game it would just give back everything it had consumed when the recipe started. However, because of a possible incredibly tiny exploit related to productivity modules and being able to get an extra % of items back if you time it correctly this was removed (bug report).

We continue to get bug reports about deleted items and all of them get filed under "not a bug". There have even been mods created to address this specific shortcoming in the game.

Remember that since we are focusing on 1.0, these ideas are currently nothing more than a cause for heated discussions in our office. But let us know what you think (on our forum) and maybe we will change our mind based on the feedback. (maybe after 1.0...)

Read this post on our website.

Hello,
we had a party last night in the office to celebrate the work we have done over the last 6 months on 0.17 stablisation. It was nice to have most of the team together to share some beers and pizza.

Unfortunately a couple of nasty bugs appeared this week, in no small part due to forum member boskid and his crusade to find bugs. In the last month alone boskid has reported over 20 bugs, so very special thanks are due. Saying that, we have been efficient in our fixing, and are now down to 32 open bug reports on the forum.

While there are issues being reported, the number of crashes is at an all time low. Below is a comparison between 0.16 and 0.17.



We compared the current number of 0.17 crashes to the number of crashes in 0.16 before we released 0.17. From what we can tell, comparing the number of crashes against average player counts, about two thirds of players are playing on 0.17. Factoring the player counts into the data, we can determine that 0.17 is close to being as stable as 0.16.

A lot of the crashes are from older 0.17 experimental releases, which might be skewing the data. Additionally about 1 in 20 of the bug reports are due to Cheat Engine, and not something we can fix.

What this means for the stable release, the plan is the same as last week. We have just release 0.17.66 with a bunch of fixes, and if it weathers the weekend player base and nothing critical arises, we will mark it as stable next week.

Forum member lilstrip has spent over 8 months working on a map, based on the idea of an Abandoned Colony/City, first talking about his baby in this thread. After long last he has a version ready for publishing, and a little bit of a backstory to go with it.


Click to view full size

In the years before the gates shut Nauvis used to be a promising colony. Equipped with a massive orbital ring the planet was an absolute power house when it came to building ships for the Tyrador Safeguard Coalition.

Sadly the colony was lost in the first AI war long after the collapse. In reality things weren't going too well in the first place after the gates closed, famine and unrest were a common occurrence for the colony of Nauvis. To this day [REDACTED] of the AI war still roam the system in massive numbers and eventually a few decades later the location of the colony was lost..

Xterminator has made a video showcasing the map too, if you want a more hands-on preview.

https://youtu.be/kBlFp9FF81k

You can find the download link and the information on the scenario in the forum post. The scenario itself requires a pretty beefy PC to run, a map this large is stretching the limits of the engine a little.

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