• Updated map-gen-settings.example.json to use numeric multipliers, include cliff richness, and demonstrate expression overrides. more
  
• It is not possible to fast-replace pipe to ground by another that is in an orthogonal direction.
  
• Changed mining productivity cost to 2500 increase per level to fix that the last change was actually making it 5 times less expensive towards infinity. Lower levels are cheaper on the other hand.

• Fixed of loading of saves before 0.17.
  
• Fixed crash related to conflicting undo in multiplayer. more
  
• Fixed crash related to temporary stops and destroyed rails on the path that were already passed by the train. more
  
• Fixed yet another train pathing crash. more
  
• Fixed the hand logic for god-mode controller. more
  
• Fixed, that the hand logic could force an item to filtered slot that doesn't match it. more
  
• Fixed, that filtered inventory could ignore the hand when sorting or transferring in some cases. more
  
• Fixed overly generous migration of mining productivity research. more
  
• Right panel sizing fixes.
  
• starting_area (size multiplier) in map gen settings JSON can be represented by a number.
  
• Fixed crash related to removing technology from the research queue. more
  
• Fixed that driving backwards in vehicles wouldn't trigger the prevent-robots-from-working-because-i-am-driving-too-fast logic. more
  
• Fixed crash during startup on macOS 10.12 or older with GeForce GPU. more
  
• Attempt to fix tile transition rendering on Sandy Bridge iGPUs. more
  
• Fixed a performance problem related to undo in multiplayer. more
  
• Fixed upgrading ghost splitters wouldn't copy the splitter settings. more
  
• Fixed a couple of situations where fast replacing underground pipe could cause fluid mixing. more
  
• Fixed align in the blueprint library. more
  
• Fixed a crash when loading modded saves related to fluidbox removal in assembling machines.
  
• Fixed blueprint preview would be drawn out of its bounds. more
  
• Fixed the featured technology cost for upgrade technologies when the research queue is not enabled. more
  
• Fixed that search in the technology GUI would be cancelled by selecting a new research. more
  
• Fixed a crash on destroying an entity with fluid energy source. more
  
• Fixed a crash when deconstructing trains with inserters trying to put into them. more
  
• Fixed layout of circuit and logistic control windows. more
  
• Fixed that trying to join a multiplayer game too quickly would lead to a mods-mismatch error. more
  
• Fixed that behemoth biters didn't have resistance to acid (as all other biters have).
  
• Fixed NPE saves technologies were messed up by a migration in 0.17.5. more
  
• Fixed NPE issue where compi smashing a building would lead to a crash in migrated saves. more
  
• Fixed that it wasn't possible to access the game menu when the game was paused in multiplayer with the technology screen open. more

• Added LuaItemPrototype::mapper_count read.

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

• Fixed crash related to train waypoints and very short train paths. more
  
• Fixed wrong entity info positioning when all other things in the right container are disabled. more
  
• Fixed Wave defense victory not being triggered in some cases.
  
• Fixed Wave defense victory message being printed on every rocket launch.
  
• Fixed restarting the game after sync-mods-with-save would fail to auto-load some saves on Windows. more
  
• Fixed PvP error when loading 0.16 versions of the scenario. more
  
• Fixed selection in blueprint preview would have an offset if UI scale was not 100%. more
  
• Fixed pie slice used as progress indicator in crafting queue wasn't rendering for small angles. more
  
• Fixed that the /time command would give back the wrong time played.
  
• Fixed rendered terrain would increasingly get corrupted during movement when using 16bit rendering mode on some OpenGL drivers. more
  
• Fixed player.get_quick_bar_slot causing a crash for some values. more
  
• Fixed controls were lagging when application window was receiving lot of events it didn't recognize on macOS or Linux. more
  
• Fixed "Wait for V-Sync" graphics option was not working on macOS 10.14 Mojave.
  
• Fixed crash logs were missing stack traces on macOS.
  
• Adjusted the Supply Challenge requirements to make sense. more
  
• Fixed a crash when reviving entities through the Lua API.
  
• Fixed NPE crash on biter commands during rebuild quest. more
  
• Fixed NPE crash during cutscene if player left entity ghosts in the starting area. more
  
• Fixed NPE crash on sending biters if you plaster half the map with furnaces (yes, seriously). more
  
• Fixed NPE bug where Compilatron would sometimes not continue after players put the required items in his chest. more
  
• Fixed that technology slot tooltip didn't reflect the cost of the selected technology in the queue.
  
• Fixed NPE confusing flying text at startup. more
  
• Fixed that the train passed wait condition time was limited to 120 seconds. more
  
• Fixed hand not disappearing from the quickbar in some situations. more
  
• Fixed a crash related to the research queue. more
  
• Fixed that the research queue could show incorrect research levels. more
  
• Horizontal layouting fix of the mods gui. more
  
• Fixed that the island related changes in the terrain settings in map generator gui weren't updated if the island preset was preselected. more
  
• Fixed that custom Lua-defined shortcuts would desync the game. more
  
• Fixed a crash when player is not given when using surface.deconstruct_area(). more
  
• Fixed loading of blueprints containing rail temporary stations.
  

• Added SelectionToolPrototype flag "nothing".
  
• Made resource autoplace helper functions usable from mods. more
  
• Added LogisticContainerPrototype::landing_location_offset.
  

• Changed mining productivity technology to add 10% in one level instead of 2%, increased the formula from 100 * level to 500 * level and removed some of the low level intermediate levels.
  

• Blueprinting tools are no longer shown in the quickbar filter selection. more
  

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

• Fixed crashes related to Lua errors. more
  
• Fixed a crash when opening the fluid wagon GUI in the map editor. more
  
• Fixed that pressing "back" on the login prompt in the other settings GUI would exit the other settings GUI. more
  
• Fixed that robots could get stuck when trying to upgrade in some cases. more
  
• Fixed that the tooltips for tooltip times where backwards. more
  
• Fixed Lua commands wouldn't work show help correctly. more
  
• Fixed portable fusion reactor and rocketry tech pre-requisites - added military science pack. more
  
• Fixed uranium processing tech pre-requisites - added sulfur processing. more
  
• Removed ghost buildability consistency check until we properly integrate building of ghosts into the fluid mixing prevention logic.
  
• Fixed crash related to train pathfinding. more
  
• Fixed layouting of Map Generator gui when the preview is shown. more
  
• Fixed issues with rich text tags referencing entities that have no icon.
  
• Fixed crash related to moving blueprints from game blueprints to player blueprints. more
  
• Fixed crash related listing all players while while processing event of player being removed.
  
• Fixed a crash related to research that would continue even though the research queue is empty. more
  
• Fixed Compilatron placing a chest on top of things. more
  
• Fixed crash during quest to reactivate assembler in NPE. more
  
• Fixed that script render text would scale with GUI scale. more
  

• Made MiningDrillPrototype::radius_visualisation_picture tintable.
  

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

Read the post on our website.


https://cdn.factorio.com/assets/img/blog/fff-284-rocket-launch.mp4

So we finally released the 0.17 experimental this week. (patch notes) Hooray :)

Fun fact: The release script failed to post the release announcement on Steam and Reddit and we were wondering why. The reason is that the patch notes were so big, that it exceeded the maximum post size (40k characters). If this isn't the indication that we should split our releases into smaller chunks, than nothing is :).

Code wise, it is clearly the biggest release, and the amount of bugs we have to go through correlates with it. In other words, there are tons of bugs of all variety. We want to fix everything eventually, but it will take time, so we had to prioritize this week to aim for the most generally playable version before the first weekend after release. That means mainly unloadable saves, unavoidable crashes, game failing on startup, and the most frequently occurring problems. Our automatic bug reporting system is helping us a lot with the last one.

It is uncommon, but sometimes the automatically uploaded crash report doesn't have enough information for us to be able to fix the bug right away, but the number of times we see a crash happening is still extremely useful for prioritizing. When we see a crash on the forum, we can cross reference it to our automatic reports, and if is one of our 'top-hits', we know to investigate it right away. The most prominent crash related to loading specific kind of save happened with pipe ghosts happened more than 200 times. It was fixed (obviously), but lets wait and see what our top hit of 0.17.4 will be after the weekend.

Overall this means, that bugs that are not critical, require design discussions or are not that simple to fix are not being dealt with right now.

Also, we got quite a surprising cake gift today. It is extremely delicious and we are extremely thankful for it :).



0.17 is out and with it our new Introduction scenario. This FFF will be spoiler heavy, so if you want to play it without insider knowledge then go do that and come back.

One thing that you might have noticed is that the Introduction is not complete. The systems, quests, and graphical elements are all still under development and not up to the usual standard of our experimental releases. It is at the point where in house focus testing starts to be less useful than large scale community testing. That said, I think it is already an enjoyable experience.

During experimental, when you complete the scenario you will receive a message asking you to send us some automatically generated screenshots of your playthrough. The response has been enormous and my inbox has roughly 10gb of replies already. Most of the feedback has been very positive, but we are certainly not done tweaking, as you will see below.

Perhaps the biggest failing during the development of this Introduction was right at the start when deciding the design constraints. If I were a sane human, I would have settled for just making a new tutorial. Instead what we decided upon was:

• The scenario will be used as the free demo.
• It should be the first thing a new player sees.
• It must demonstrate the art style.
• It must demonstrate the open design gameplay of Freeplay.
• It should still be fun for seasoned players.
• First half should have tutorial elements.
• Second half gives the player a chance to test themselves in a 'real' environment.
• No jumping through hoops and simply obeying orders.
• Encourage the player to be creative.
• The player must learn the game, not how to finish the scenario.
• Include as much organic learning as possible.
• It must limit the environment enough that the player cannot become confused with choice.
• Players should not receive help until they need it.
• No quests without purpose.
• Nothing that I add should affect the Freeplay experience.

As you might expect I try not to mention the word tutorial anywhere.

If you have been on reddit or our forums in the last few days you will probably notice that many players feel the scenario is too difficult for new players, or that they played 'like a new player' and found it too hard themselves.

Two reasons were frequently given for this:

• The lack of splitters and underground belts make solving the design puzzles more difficult.
• Combat heavy gameplay is not what Factorio is about especially at the difficulty presented in the scenario.

We will come back to my thoughts on this, but for now just think about your own idea of 'how a new player interacts with the game'.

A normal video game tutorial is a terrible thing. Mechanics are broken down into smaller chunks and sorted by which order they must be done in the the main game. Sometimes when a game is complex the smallest chunk is still impossibly large, leading to walls of text that must be read before playing (see the Civilization mobile title). Sometimes the chunks are made very small but then the designers want to speed players through, so they force a series of narrow interactions (see Factorio’s old tutorial).

Neither of these solutions are bad, if your goal is to have the player finish the tutorial. If your goal is to teach them to play, then... well... we as educators can do better.

The deepest, broadest and most important concept we need to teach in Factorio is that of Production. That is the end goal, but where does it begin?

The blueprint for production is the humble recipe tooltip. This is where the player first sees how to make an item in the game. Our job is to teach them how to take the recipe and translate it into a production chain. This is the single most important lesson on the road to automation, so I set out to remove all obstacles. Let’s break our discussion down into the mechanical parts: Assembling Machines, Belts, and Inserters.





Assembling Machines are the core of automation but in Freeplay they have a dependency: Electricity. If this was a regular video game tutorial, we would first need to teach the player the following steps (in reverse order): Build power poles, Setup steam engine, set up coal mining.

What if we could just do away with all of this? Oh, we can? Wonderful! During the Introduction there are two assembling machines which require no electricity, one for Science packs and one for Iron gear wheels.

Now the main puzzle pieces are there, the player just needs to connect them. During focus testing, it was noted that the interaction between belts and inserters was not very intuitive to begin with. So again we need to break the concept of Logistics down into two concepts: traversal of items and change of inventory.

If this were a normal video game tutorial, we would probably just ask the player to obey, placing a belt in one place and then the Inserter next. Here in the Introduction, I want the player to see both concepts working separately, and to interact successfully with each one.



Compilatron builds a mining setup for the player and then the Objective window directs the player to feed the produced plates into the 'feeder'. Once that is complete, the 'feeder' is removed and the player needs to load and unload the assembling machine with inserters.

In the next step, the player needs to apply what they have learnt by building a copper smelting setup and then feed two different items (iron gears and copper plates) into a single 'feeder'. Once this objective is complete, the player has, without knowing it, set up Science pack automation.



There was a lot of feedback about the player not being given access to Splitters and Undergrounds. Some even considered this akin to 'handicapping the new player'. I would argue that there is a difference between complexity and difficulty. Having those tools makes the puzzle easier yes, but also more complex.

Many of the long time players mentioned that they enjoyed solving 'simple, long ago optimized' problems with a reduced toolset. Using an inserter to split a belt does work, and also makes the player realise the importance of Splitters when they are unlocked. #NoWrongWayToPlayFactorio

The factory must grow. This is Factorio. Progress never ending. How do we teach a new player the concept of never having enough?

I mentioned above that we wanted to remove quests which ask you to produce items for no reason. Several times in the old campaign the player was asked to produce 100’s or even 1000’s of items "because you will need them", only to move to the next level and take them all away. So, how do we give production a purpose?

Consumption. Consumption is the intent of Production. You produce with the intent to consume.

In Factorio there are only three ways that the player consumes items:

• Converting items into research progress.
• Constructing the factory.
• Killing Biters (either for defense or for land acquisition).

The first item, research, is a constant pressure in Freeplay Factorio, and not a large one at the beginning. In the Introduction we have created an entirely separate technology tree with much higher costs to support teaching production. However, it fails at showing the player they need to increase production (as opposed to just having some) because the costs are static. We see many players set up basic science pack automation and then go AFK while it finishes.

https://cdn.factorio.com/assets/img/blog/fff-284-NPE-slideshow.mp4

As for construction, in the second part of the Introduction we allow the player to build their factory any way they want, and to consume all of their resources to do so. Only after they are settled do we apply the third consumption pressure... combat.

I received a lot of feedback in the form of "Factorio is not about killing Biters" or "Factorio is not a tower defense". My response would be "killing Biters is not about combat, it is a production challenge". We all know that trees are the real enemy.

Not only is it a production challenge, it is one that requires no explanation. Also, unlike the other two consumption pressures, this one is reactive. The player must meet the demands or be overrun.

To understand production you need to experience the state of not having enough. This is accomplished best when you have two conflicting choices, but can only take one. I've heard it described at "A slave to two masters" and I think that sums it up nicely.

Many successful games use this to good effect. In Dragon Age you are forced to choose between your love interests and "doing what is right". In Factorio it is one step more complex than love because the decisions are not Boolean... we have ratios!

So I would argue that the most 'representative' way to make the player think about this is to ask them to research something while slowly increasing the consumption of ammunition.



Actually no, it isn’t so hard for new players. It is hard for veteran players. The attack system emulates Freeplays pollution system. If you pollute hard, you are attacked hard. The only difference is that the 'price' of a biter is lowered inversely to how far you are through the final research.

Dynamic difficulty is a big topic in the office, but even its staunchest opponent, kovarex, admits he had fun with the final wave. He also holds the high score for kills during the Introduction; Over 9000 :D.

We already use dynamic difficulty in the Freeplay, so I would consider it representative. The difficulty will of course get a bunch of balance passes and something will be added to warn players better of the dangers ahead.

The introduction is far from done, or even ready for all new players. My task for the next weeks is go over the massive amount of high quality feedback and start testing some tweaks. The scenario will not receive updates every time we update 0.17, instead I will bundle the changes once every few patches. If you would like to share any feedback about the new Campaign, we have set up a dedicated forum here, and if you find any bugs, we also have a place for them here.

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

• Disabled target leading for flamethrower turrets until it can be made better. more
  
• Changed train pathfinding in a way, that it can find path that ends in the same segment where it started. This worked only for the trivial case of all path of one segment before.
  

• Fixed possible crash related to browsing in the mods gui.
  
• Fixed that turning off exoskeletons didn't work correctly in multiplayer.
  
• Fixed shaking of blueprint preview in blueprint book tooltip. more
  
• Fixed the wrong detection of changed autosave interval in other settings. more
  
• Fixed /help *command* would print a number instead of the help message. more
  
• Fixed a crash when dying with the locomotive GUI open. more
  
• Fixed a crash when using sprite variation sheets with mismatched frame counts. more
  
• Fixed that the admin-only portions of the whitelist command where not localised correctly. more
  
• Fixed building underground pipe between pipes with different fluids. more
  
• Fixed visual direction of fluid flow. more
  
• Fixed dead-dry-hairy-tree and dry-hairy sprite shifting in normal resolution. more
  
• Fixed PvP error when changing enabled mods. more
  
• Fixed number pad Enter key-bindings would be converted to normal Enter when restarting the game. more
  
• Fixed small worms having fluid consumption. more
  
• Fixed that copy-paste of fluid recipes would sometimes not reset fluid box contents. more
  
• Fixed that double-clicking a technology in the tree view wouldn't start research. more
  
• Fixed pipes that would sometimes be too noisy. more
  
• Fixed that you could build multiple underground belts on top of each-other. more
  
• Fixed tightspot level 5 was unbeatable. more
  
• Added workaround for GPU accelerated texture compression producing corrupted textures. more
  
• Fixed that the technology window scroll position would keep getting reset. more
  
• Fixed that the current research panel would not update in multiplayer if some other player changed the research. more
  
• Fixed terrain not being rendered when using OpenGL and any game overlay was enabled. more
  

• Added LoaderPrototype::structure_render_layer with default value "lower-object". more
  

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

• Reverted default renderer on Windows to Direct3D on all configurations.
  
• All infinite technologies have Space science pack as a pre-requisite.
  
• Added textual error message when player tries to clean cursor but it isn't possible as inventory is full.
  
• Added /unlock-shortcut-bar console command to unlock all shortcuts at once. This command does not disable achievements.
  
• Keyboard shortcut for in-game undo feature will default to Ctrl+W on AZERTY keyboard layouts. more
  
• Control settings will revert to defaults when starting the game with pre-0.17.2 config with AZERTY keyboard layout.
  

• Fixed Join Game through Steam Friend would fail to connect to a game with an error saying Steam Networking is disabled.
  
• Fixed LuaGameScript::take_technology_screenshot() would crash the game.
  
• Fixed a crash when trying to use async-saving when hosting multiplayer games on Windows. more
  
• Fixed electric mining drill coverage area visualization was not drawn correctly. more
  
• Fixed missing sprites on DirectX on GPUs supporting only feature level 10.0. more
  
• Fixed that the GUI would be hidden if the game was saved and loaded while the technology GUI was open. more
  
• Fixed a crash related to non gun/weapon items getting into the gun/weapon inventories. more
  
• Fixed a crash when bringing up the escape menu in multiplayer while in the middle of using blueprints/deconstruction. more
  
• Fixed a crash when mining ghosts built in the latency state. more
  
• Fixed every incremental change of sound volume would save the full config file. more
  
• Fixed that the category dropdown in the install mods GUI would only work the first time it was used. more
  
• Fixed that mod thumbnails in zipped mods wouldn't show in the mods GUI. more
  
• Fixed pre-requisites for the first tier of all upgrade technologies so that the required science packs are unlocked first. more
  
• Fixed electric inserter technology description in the tutorial. more
  
• Fixed that the undo shortcut tooltip didn't reflect latency hiding values and invalid entries filtering.
  
• Fixed a desync when deconstructing item request proxies in the latency state. more
  
• Fixed crash related to the hand logic and switching controllers. more
  
• Fixed a crash when lamp with non-electrical energy source (modded) is viewed in the blueprint preview/tooltip.
  
• Fixed that read-only multi-line text boxes wouldn't wrap text. more
  
• Fixed that the fast and express loader entity icons had the wrong colors. more
  
• Fixed that the autosave interval setting was off by one. more
  
• Fixed map preview would not be cleared to black before preview is generated on some PCs. more
  
• Fixed that active blueprint in a book was not preserved when using the book directly from the blueprint library. more
  
• Fixed that the tutorial specific assembler was shown in the "made in in" row in the crafting queue tooltip. more
  
• Fixed that the map type selection changed done by reset or changing the preset didn't update the sliders properly. more
  
• Fixed a rare issue with migration of fluid mixing in a modded save. more
  
• Fixed that the provided map-gen-settings.example.json contained invalid settings. more
  
• Fixed that checking for updates could crash the game. more
  
• Solved, that blueprint library link from quickbar appeared as an empty slot when the target blueprint wasn't available anymore and it wasn't possible to assign a new item to it.
  
• Fixed PvP scenario error when updating space race frame with no silos present. more
  
• Fixed drawing of some wires and wire shadows more
  
• Fixed a possibility to mix fluid through fast replacing / upgrading a pipe with underground pipe. more
  
• Fixed drawing of some wires and wire shadows. more
  
• Fixed crash when opening the map generator preview for the first time with invalid settings. more
  

• Renamed EntityPrototypeFlag "hide-from-bonus-gui" to "hidden" and made it also hide entities from the made in property of recipe tooltips.
  

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

• Added shortcut bar shortcut type that fires Lua events, for use in mods

• Added LuaPlayer::is_shortcut_toggled, LuaPlayer::is_shortcut_available, LuaPlayer::set_shortcut_toggled, LuaPlayer::set_shortcut_available
  
• Added on_lua_shortcut event.

• Missing description.json in the campaign folder results into the folder being ignored instead of a crash.
  
• Fixed crash when trying to rotate quickbars with a controller that doesn't have it.
  
• Fixed crash when trying to open surface map generation settings.
  
• Fixed possible crash related to copy paste and multiplayer.
  
• Fixed it wasn't possible to use capital 'Z' in save name. more
  
• Fixed the infinity chest graphics.
  
• Fixed that the boiler didn't rotate in blueprints.
  
• Fixed that the bait chest showed in the upgrade planner.
  
• Fixed high CPU usage when using steam networking.

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

New version is up and the changelog is too big for a steam announcement post :D

Have a look over at our forum: https://forums.factorio.com/65070

Read the blog post on our website.

We have been playtesting a few days this week. There were some things we had to fix on the fly, but we still were able to play quite a lot, so I would say that it went surprisingly well. We have been able to get 3 multiplayer bases into a late game stage.

As we played 3 different games already, we discovered that the tile pollution absorption values are quite weird. Water was actually absorbing more pollution than grass, which in combination with the fact that water heavy worlds have less biters and more choke points, makes it way too easy compared to a desert world. In addition, grass and sand pollution absorption was brought closer together, as the difference between desert world and grass world when it comes to bitter attack intensity was way too high.

In 0.16 one of the the map starting settings related to pollution is called Dissipation rate. Its tooltip says "Control how fast pollution dissipates naturally". Since the word sounds alien to many (I had to search it up), no one touches the setting, and we actually had to dig through the code to figure out, what the option truly does.

It was a modifier of how much pollution is absorbed by tiles. And the range is from 1 to 1000. You can't really set it lower then the default 1 and setting it to 100 for example basically removes all the pollution effectively, as tiles suddenly absorb 100 times more pollution. So we changed the setting name and description to absorption modifier, with a tooltip saying "Modifier of how much pollution is absorbed by trees and tiles." The values now range from 10% to 400%, so you can actually use it to make the game harder. This should suddenly make it understandable. Oh, and the Deathworld preset value is now 50% :)

As you might know, the Spawner/pollution/attack mechanics work this way: Spawners absorb pollution that reaches them, and after absorbing a certain amount of pollution, they send a unit to join an attack group. The amount of pollution depends on the type of unit, and later units need more pollution. There is also a cooldown limiting the amount of enemies sent to attack per time.

So far, so good. But there is a fundamental problem with the algorithm we use, as we randomly figured out by looking at the debug data of a Spawner next to our base.



As you can see, the Spawner needs 200 pollution to send a unit to attack, but it already accumulated more than 100k pollution, which is enough for next 500 units. Basically, the problem is, that the Spawner can accumulate an unlimited amount of pollution at a much higher speed then it can ever use. So the first row of biter nests can easily prevent the other nests from accumulating any pollution, which kind of breaks the difficulty scaling and the whole mechanic. Whether you make a little bit of pollution or a crazy amount, the amount of attacks might be the same.

The solution is simple, the Spawner now has an upper limit to how much pollution it can absorb, which is 3 times the most expensive unit it can spawn for the current evolution factor.

We made some basic testing after this change, and it seems that it is survivable enough for the release, but we might want to tune the default pollution/evolution/attack modifiers during 0.17 stabilisation.

One of the other problems we noticed with biters is, that they got stuck in their own base quite often. We discovered, that they can be trapped by the positioning of Spawners/Worms quite easily.



To solve this, we just added a new optional property into entity definition called map_generator_bounding_box which defaults to collision_box. It can be made larger to limit the placement of the entity by the map generator to keep the space around the entity clear. It is also used when biters are building new bases. Adding a 1 tile safe space around all spawners and worms forced the bases to have enough space for the biters to move through it.



In the future, we (or anyone) could use this property, to limit the density of trees in a forest, or similar things.

The strategy to put belts in the path of bitters to upgrade defense is a nice piece of emergent gameplay, but we noticed, that it tends to be little bit too strong. It was discovered, that biters have a small bug in their code, that affects their movement by belts way much more than it should.

https://cdn.factorio.com/assets/img/blog/fff-283-biters-on-belts-bugged.webm

So posila went ahead and fixed that, and now, biters are still affected by belts, but it doesn't completely bug them anymore. How did we not notice it for like 2 years?

https://cdn.factorio.com/assets/img/blog/fff-283-biters-on-belts-fixed.webm

With 0.17, we will be releasing the first public version of the new Introduction Campaign.Because of this, naturally, we will be removing the old 'First Steps' and 'New Hope' campaigns.

The 'Main Campaign' will be added to the game later, and we will be providing some more details on the Introduction and Main Campaigns next week.

We were testing the algorithm, and there was a lot of back and forth, but the time was running by and there were some problems not that easy to fix. To prevent things from getting broken in a ways we couldn't anticipate and not to potentially delay the release any further, we decided to split the change.

So the fluid mixing prevention and fluid update optimisations are in 0.17, but the new algorithm was put aside for further research.

With the upcoming release of a new experimental version, a big question for the wiki is when it will be updated to that version. In the past we updated the entire wiki to the experimental version a few weeks after its release, but we are changing this up: The plan is to update the wiki to the experimental version immediately on release. I wrote some scripts to speed up this process, so the moment you see that the release is out, you can head over to the wiki and check out the new recipes and technologies without having to wait on some slow human to update that info. Furthermore, a clone of the 0.16 state of the wiki will be made and available as a read-only wiki at https://stable.wiki.factorio.com, for the players that prefer to stay on the stable version of the game.

Small news for mod creators. In the new in-game mod GUI (FFF-272) will show thumbnails for mods alongside mod description. Since you should be able to interact with the installed mod settings also in an offline mode, the thumbnails have to available in the mod package. To make a thumbnail show up, simply include thumbnail.png alongside your info.json. The resolution is 144×144 pixels, same as previously on the mod portal. From now on, the mod portal will only respect thumbnails provided in this way.

It’s common to think that the smaller is the entity the easier is to make it. Less pixels = less work. Well, not necessarily. Like an icon you have a very small space to express many concepts, material, use, style, etc. That means a lot of work in synthesis. I’ve been making drafts and 3d sketches for chests for a while, and this is the best version I’ve got for all of them:.

• Wooden: Nothing much to change here, just a translation of resolution and details.
  
• Iron: Before we had confusion between Iron and Steel. Now the difference is much clearer.
  
• Steel: More modern and industrial looking. Like a shipping container.
  
• Infinity: Not everybody knows this chest exists because it’s made for testing reasons, you will find it in the map editor.
  
• Logistics: The design tries to emulate the style of the Roboport, and we introduce a new concept, an animation for opening/closing the doors.

There are not that many entity graphics remaining that we have not touched in the last few years, be it a conversion to high resolution, a redesign, or both. The Rocket Silo has several specific qualities that make it very intimidating, and now time has come to face them.

We recognized that the design of the Rocket Silo you can see in 0.16, has various issues we would like to address. On the first sight it is obvious that it does not fit into the visual style of Factorio too well anymore, and looks out of place. Not just because it’s very dark, but also because the giant 9x10 tile entity is completely filled into a rectangular shape. This majorly contributes to it looking like a rectangular sticker on the screen instead of an integrated entity in the world.

A lot of the elements in the old model were too blocky and artificial for the modern Factorio look. Over time we have basically replaced all of the areas of the model with new meshes. Albert helped me by creating the robotic arms and their housings in the concrete base of the rocket silo that you can see below.

https://cdn.factorio.com/assets/img/blog/fff-283-rocket-silo-preparing.webm

When we started working on the high resolution redesign of the Rocket Silo, the first decision we made was that it will now be a 9x9 entity so you could rotate the blueprints properly, and it was clear from the start that we want to make fit on the ground more. This would mean that the structure at the top of the original rocket silo would have to go, and the hole would be moved more towards the center of the entity.

The Rocket Silo without the rocket uses sixteen 8192x8192px textures which makes our 1080Ti run out of VRAM to render.. Luckily I have made the rendering as optimized as possible through python scripting as always. Worth noting that without our long-term focus on automation and proper workflow, this could have been a massive problem.

It would not have been normal if we did not need to edit things in the code or fix things, and since the Rocket Silo has an obscene amount of layers, layer switching and other crazy quirks in its animation, our beloved posila helped us fix all those issues, though he may have mentioned a few nasty words to himself along the way, and his commit messages contained words like 'black magic' more than once.

Last but very far from least, the Rocket Silo has one huge benefit - a lot of the animation happens procedurally which means the source images themselves are static PNGs. This allows for a lot of flexibility and power in Photoshop post-production that we cannot afford with heavily animated entities like for example trains. This made the end of the process extremely enjoyable and allowed us to finish it really properly.

As you can see, there are a lot of things happening at the last moment, but it seems that there shouldn't be a big obstacle in the way of release next week.

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

Read this blog post on our website.

This week was the time to close and finish all the things that will go to 0.17.0.

Not all of the things that we originally planned to be done were done (surprise), but we just left any non-essential stuff for later so we won't postpone the release any further. The plan is, that next week will be dedicated to the office playtesting and bugfixing. Many would argue, that we could just release instantly and let the players find the bugs for us, but we want to fix the most obvious problems in-house to avoid too many duplicate bug reports and chaos after the release. Also, some potential bugs, like save corruptions, are much more easily worked on in-house.

If the playtesting goes well, we will let you know next Friday, and if it is the case, we will aim to release the week starting 25th February.

Since there are a lot of things we would like to do before we can call 0.17 good enough, we will simply push new things into the 0.17 releases as time goes on. Even if 0.17 becomes stable in a reasonable time, we would still push things on top of it. We can still make experimental/stable version numbers inside 0.17. Most of the things shouldn't be big enough to make the game generally unstable. I've heard countless times a proposal to make small frequent releases of what have we added, this will probably be reality after 0.17 for some time.

The smaller releases will contain mainly:

• Final looks and behaviour of new GUI screens as they will be finished.
• New graphics.
• New sounds and sound system tweaks.
• Mini tutorial additions and tweaks.

This is actually quite a large change to our procedures, and there are many ways we will be trying to maximize the effectiveness of smaller and more regular content updates.

There are several GUI screens that are finished. Others (most of them) are just left there as they are in 0.16. They are a combination of the new GUI styles and old ones. They sometimes look funny and out of place, but they should be functional.



The blueprint library changes have been split into several steps. The reason is, that there was a big motivation to do the integration with the new quickbar (final version introduced in FFF-278) in time for 0.17.0, while the other changes can be done after. The thing with the quickbar is, that it is quite a big change to one of the most used tools in the game and people generally don't like change even when it is for the better. To minimize the hate of the change, we need to "sell it properly". By that, we should provide as many of the positive aspects of the new quickbar at the time of its introduction.

So the change that is already implemented and working for 0.17 is the ability to put blueprints/books into the quick bar in a way that the quick bar is linked directly to the blueprint library window, so you don't need to have the physical blueprint items in your inventory. The other change is, that picking a blueprint from the blueprint library and then pressing Q will just dismiss it, instead of silently pushing it to your inventory. This works the same as the clipboard described in FFF-255. You can still explicitly insert the blueprint from the library to an inventory slot, but if you just pick it, use it, and press Q, it goes away.

In addition to this, other changes related to the blueprint library will follow soon after 0.17.0. The first thing is the change of how the GUI looks:



We will also allow to switch between grid and list view. It mainly provides a way to nicely see the longer names of the blueprint. We noticed that players try to put a large amount of info about a blueprint in its name, so we are planning to add a possibility to write a textual description of the blueprint.



The last big change is to allow to put blueprint books into blueprint books, allowing better organisation. Basically like a directory structure. Whenever a blueprint/book is opened, we plan to show its current location, so the player knows exactly what is going on.



Has it ever happened to you, that you have robots trying to put things into your full inventory, while you pick an item from it to build something, and then you just can't put it back, as the diligent robots just filled the last slot in your inventory by whatever they are trying to give to you? Wood from tree removal is the most frequent thing in my case.

This was annoying in 0.16 from time to time, but with the new quickbar, it started to happen even more, as now, you have only one inventory, and no reserved slots in the quickbar. To solve that, we just extended the "principal" of the hand. When you pick something from the inventory, the hand icon appears on the slot. As long as you hold the thing in your cursor, the hand stays there, and prevents other things from being inserted there. This way, you should always be able to return the currently selected item into your inventory as long as you didn't get it from external source like a chest.


The hand is protecting the slot from the robots.

Everyone has different opinions about what makes a good Factorio world.I've been working on several changes for 0.17, but the overarching themehas been to make the map generator options screen more intuitiveand more powerful.

This was talked about somewhat in an earlier FFF (FFF-258) regarding ore placement,but since then we found more stuff to fix.

In 0.16, the size control for biter bases didn't have much effect.The frequency control changed the frequency, but that also decreased the size of bases,which wasn't generally what people wanted.

For 0.17 we've reworked biter placement using a system similar to that with which we got resource placement under control. The size and frequency controls now act more like most people would expect, with frequency increasing the number of bases, and size changing the size of each base.



New preview UI showing the effects of enemy base controls.In reality the preview takes a couple seconds to regenerate after every change,but the regeneration part is skipped in this animation to clearly show the effects of the controls.

If you don't like the relatively uniform-across-the-world placement of biters,there are changes under the hood to make it easier for modders to do something different.Placement is now based on NamedNoiseExpressions "enemy_base_frequency" and "enemy_base_radius", which in turn reference "enemy_base_intensity".By overriding any of those, a modder could easily create a map where biters are found only at high elevations,or only near water, or correlate enemy placement with that of resources, or any other thing that can be expressed as a function of location.

We've added a 'continuity' control for cliffs. If you really ike mazes of cliffs, set it to high to reduce the number of gaps in cliff faces.Or you can turn it way down to make cliffs very rare or be completely absent.



Changing cliff frequency and continuity. Since cliffs are based on elevation,you'll have to turn frequency way up if you want lots of layers even near the starting lake.

Tile placement is based on a range of humidity and 'aux' values(humidity and aux being properties that vary at different points across the world)that are suitable for each type of tile. For example: grass is only placed in places with relatively high humidity, and desert (not to be confused with plain old sand)only gets placed where aux is high. We've taken to calling these constraints 'rectangles',because when you plot each tile's home turf on a chart of humidity and aux,they are shown as rectangles.

It's hard to make sense of the rectangles just by looking at the autoplace code for each tile, so I wrote a script to chart them. This allowed us to ensure that they were arranged as we wanted, with no gaps between them,and with overlap in some cases.


Rectangles.

Having the humidity-aux-tile chart is all well and good, but doesn't tell the whole story,since tile placement also depends on a noise layer specific to each tile type,and could also influenced by user-adjustable autoplace controls (e.g. turning the grass slider up).So to further help us visualize how humidity, aux, tile-specific noise, andautoplace controls worked together to determine tiles on the map,there are a couple of alternate humidity and aux generators that simply vary themlinearly from north-south and west-east, respectively.


Using 'debug-moisture' and 'debug-aux' generators to drive moisture and aux, respectively.

This map helped us realize that, rather than having controls for each different type of tile, it made more sense to just control moisture and aux (which is called 'terrain type' in the GUI,because 'aux' doesn't mean anything).


Sliding the moisture and aux bias sliders to make the world more or less grassy or red-deserty.

A pet project of mine has been toput controls in the map generator GUI so that we could select generatorsfor various tile properties (temperature, aux, humidity, elevation, etc) atmap-creation time without necessarily needing to involve mods.This was useful for debugging the biome rectangles, but my ulteriormotive was to, at least in cases where there are multiple options,show the generator information to players. A couple of reasons forthis:

• It was already possible for mods to override tile property generators via presets, butwe didn't have a place to show that information in the UI.So switching between presets could change hidden variables in non-obvious waysand lead to a lot of confusion.
• I had dreams of shipping alternate elevation generators in the base game.

For 0.16 I attempted to make the shape of continents more interesting. Some people really liked the new terrain, or at least managed to find some settings that made it work for them. Others called it a "swampy mess". A common refrain was that the world was more fun to explore in the 0.12 days.

So in 0.17 we're restoring the default elevation generator to one very similar to that used by 0.12. Which means large, sometimes-connected lakes.

The water 'frequency' control was confusing to a lot of people including myself.It could be interpreted as "how much water", when the actual effect was to inversely scale both bodies of water and continents, such that higher water frequency actually meant smaller bodies of water.So for 0.17, the water 'frequency' and 'size' sliders are being replaced with 'scale' and 'coverage',which do the same thing, but in a hopefully more obvious way.Larger scale means larger land features, while more coverage means more of the map covered in water.

In order to ensure a decent starting area, the elevation generator always makes a plateau there (so you'll never spawn in the middle oft he ocean), and a lake (so you can get a power plant running). Depending on what's going on outside of that plateau, this sometimes resulted in a circular ring of cliffs around the starting point,which looked very artificial, and we wanted to reduce that effect.

In the process of solving that problem I created another custom generator for debugging purposes.This one simply generated that starting area plateau in an endless ocean.I don't actually remember how this was useful for debugging, but at one point I directed Twinsen to look at it to illustrate the mechanics behind generating the starting area.

The rest of the team liked that setting so much that we're making it a player-selectable option. So in 0.17 you'll get to pick between the 'Normal' map type, which resembles that from 0.12,and 'Island', which gives you a single large-ish island at the starting point.There's a slider to let you change the size of the island(s).



Maps with multiple starting points will have multiple islands.


PvP islands!

And speaking of scale sliders, we're expanding their range from ± a factor of 2 (the old 'very low' to 'very high' settings)to ± a factor of 6 (shown as '17%' to '600%'). Previously the values were stored internally as one of 5 discrete options,but as the recent terrain generation changes have made actual numeric multipliers more meaningful in most contexts(e.g. the number of ore patches is directly proportional to the value of the 'frequency' slider,rather than being just vaguely related to it somehow),we're switching to storing them as numbers.This has the side-effect that if you don't mindediting some JSON,you'll be able to create maps with values outside the range provided by the GUI sliders.

Mods will be able to add their own 'map types' to the map type drop-down, too. If you really liked the shape of landmasses in 0.16 and want to be able to continue creating new maps with it, please let us know on the forum.




The design of the accumulator has been always good. The 4 very visible cylinders, looking like giant batteries, Tesla poles and the electric beams perfectly telegraphed its function in terms of style and readability. That’s why for the high-res conversion we were very careful about keeping this entity as it was.

The only thing that was a bit disturbing (for some) are the poles crossing to each other when more than one accumulator is placed in a row. So we decided to fix it (or break it). The rest of the work was making the entity compatible for the actual look of the game. But in essence accumulators are still the same.



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