Read this post on our website.

Hello,
We released 0.18.2 and 0.18.3 this week. In terms of major releases, this one has very few bugs, so we haven't had a lot of pressure to crank out the releases at lightning speed.

In the sound design department we have been hard at work to bring you a better gaming experience with the help of some new and improved sound effects. It struck me that the whole sound track used to have a lo-fi, almost 'dirty' feel, by which I mean the sounds were unclear, had a low resolution and possibly used recordings made with the wrong microphone positioning. So with Val's help we have set about improving some of these sounds. For example, there are new sounds for all the transport belts, they don't sound very different but they are smoother sounding and less annoying.

https://cdn.factorio.com/assets/img/blog/fff-332-belts.mp4

Similar to the transport belts, we also have sounds for the combat robots that are designed to harmonise with one another. Val made a bunch of synth tones for these and I chose the three sounds that make a pleasing harmony when you add them together.

https://cdn.factorio.com/assets/img/blog/fff-332-combat-robots.mp4

However in my haste to get these sounds in the Tuesday release, I missed that the fast and the express belts had an annoying high pitched whine in there. So I have EQ'd off the high frequencies and now they work better.

The main reasons for having sound design in a game is not just to increase realism and immersion but also for player feedback and to increase the fun factor. Sometimes these things are hard to get right, especially in a game like this where there are so many sound producing entities so close to one another, often with very busy animations. You expect to hear a busy sound, but when you play them all together... it can be a mess. Add to this the innumerable ways sounds can be combined, well you get the idea.

I have described this game as a sound designer's dream... and also nightmare. So try and bear with us while we get the balance right. We are also trying to do all this without a modern sound engine, which brings me to my next point.

Tech wise, Rseding has been busy updating the sound code. For example we now have the listener position on the centre of the screen by default, which makes more sense to me and helps when you are in the map mode. Zoom level and attenuations have also been increased.

Innumerable other small fixes to sound levels have been made and hopefully the game is starting to sound the way we want.

In the 0.18.2 release this week we changed the map colors for a few entities from the default blue:

• Heat Pipes
• Pipes and Underground pipes
• Pumps
• Storage tanks
• Beacons
• Steam engines and Turbines
• Roboports

To us it is nice to have a bit more differentiation between entity types/families on the map view (without going crazy), and we think we are carefully getting there.



These changes should especially help tell give some character to power setups, and big assembling blocks with beacons. We're happy with the way it is looking, and with more time we might decide on some more tweaks.



Quite a lot of great things to share this week :).

Last Saturday, KatherineOfSky and Caledorn hosted a MP server with the goal to set a new record of over 500 players. The server was funded by the community through a {LINK REMOVED}GoFundMe.



They were successful, and managed to have at one point 521 players online. This is actually quite a surprise to us, especially since it was with the fresh 0.18.1 version of the game.

You can watch the full stream of the MMO event here.

Nefrums set a new speedrun record this week playing 0.18. He is getting close to a sub 2-hour run, just 5 minutes to optimize!



Reddit user minibetrayal created a Turing machine using Train network logic gates, comprising of 4,800 Locomotives, 6,172 Train stops, 56,030 Rail signals, and over 1,300km (800 miles) of Rail.

https://cdn.factorio.com/assets/img/blog/fff-332-rail.mp4

If you would like to know more, there are details in the Reddit thread.

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

• Improved map colors by adding specific colors to beacons, pipes, heat pipes, roboports and steam engines.
  

• New or updated sound effects include:
  
• Pump, pumpjack, boiler, heat pipe, offshore pump, substation.
  
• Logistic and construction robots, roboport.
  
• Train.
  
• Rocket takeoff sequence.
  
• Car and tank (pitch scaling adjusted to sound more natural).
  
• All transport belts, splitters, inserters, assembling machines, power switch.
  
• Added some UI sounds that were missing.
  
• Shotgun, small explosions.
  
• Entity destroyed alert.
  
• New sound tech includes:
  
• Listener position set to centre of screen by default. This will allow you to hear what you see even when in map mode.
  
• The ability to turn off the Doppler effect in Lua, used for the Substation so far.
  
• environment-audible-distance setting increased to 30 so you can hear entities a bit further away.
  
• zoom-volume-coefficient changed so you can hear more of the world when you zoom out. This will help with combat and give a greater sense of the overall factory.
  

• Fixed that pressing escape in some log-in screens lead to blank screen or incorrect states. more
  
• Fixed enemy walls should not render as connected to ghosts, since enemy ghosts are not visible. more
  
• Fixed undo on self-looped combinator ghosts not restoring wires. more
  
• Fixed achievement cards not showing description when descriptions are turned off in interface settings.
  
• Fixed that inserters from 0.17 save files could end up teleporting items into/from trains. more
  
• Fixed that the sync mods with save GUI wouldn't size correctly. more
  
• Fixed that thrown capsules could end up broken forever if thrown at exactly the right tick. more
  
• Fixed crash when using "create-entity" trigger effect item to create an artillery flare. more
  
• Fixed map view night LUT. more
  
• Fixed a crash that would sometimes happen when a biter, who was in previous versions of the game aggroed by a player in a car or tank, was aggroed again. more
  
• Fixed crash when joining a game through Steam without having previously logged in.
  

• Migrating loaders between loader and loader-1x1 will maintain the loader type (input/output). more
  

• Added LuaSurface::create_particle().
  
• Added LuaEntityPrototype::inserter_pickup_position and inserter_drop_position read.
  

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

Read this post on our website

Early this week we pushed the deploy button on 0.18.0. This was quite a surprise to many of our players, as more typically the time between major releases and the scope of the release is greater. However this isn't like the old days, we are trying to keep the size of releases as small as possible (FFF-314).

What this means, is that what is currently in 0.18 is only really a small part of the work needed to be done on 0.18, and releases in the coming months will continue finishing off our 0.18 task list.

Once everything on the 0.18 list is completed and the time is right, we will turn 0.18 into 1.0.

What we have accomplished with 0.18.0:

• GUI
  • Main menu redesign
• GFX
  • Water animation
  • Tree animation
  • Color correction (LUTs)
  • New explosions and damage effects
• Other
  • Optimizations
  • New Particle system
  • First work on new sound design
  • Steam login

What we have left to do in 0.18:

• GUI
  • Character GUI
  • Blueprint library
  • Statistics GUIs (production, electric network stats, etc.)
  • Entity GUIs (Inserter, Assembling machine, chests, etc.)
  • Main screen GUIs (Chat, minimap, etc.)
  • Many more...
• GFX
  • Offshore pump redesign
  • Assembling machine redesign
  • Beacon redesign
  • High-res icons
  • Final tweaks and polish
• Other
  • Further sound design improvements
  • Mini-tutorials
  • Replace NPE with old tutorial
  • Final game balancing and tweaks
  • Finalised locale and proofreading

With this in mind, it wouldn't make sense to mark 0.18 stable before most of the above is finished. We made 0.18 a major version because it will break mods with all the changes we are making, and while initially it hasn't broken that much, many things to come will have a bigger impact, such as the Character GUI.

Initially we planned for the Character GUI to be in the first 0.18 release. However the task was proving quite difficult the way it was written, and when the release date came it was not ready, so we delayed the entire 0.18.0 release (twice). After a tough and thorough review, we decided to discard most of the work, and start fresh with a different team member. With programming, you've got to know when to hold 'em, know when to fold 'em.

With this change, we decided to release 0.18 without the Character GUI, the alternative was an additional 4-6 week delay, which with only 8 months left, is a big chunk of time. We also don't want to get back into the old habit of always delaying the release for another and another reason, and the things we present in Friday Facts not being seen in-game for months and months.

After this decision, Dominik, who was working on the Character GUI, decided to leave the Factorio team.

In the recent FFF-329 we have mentioned two different approaches to the campaign. In this FFF, we are announcing that the campaign has been cancelled, and I’ll try to explain why.

After the Tutorial/NPE was cancelled, I realized several things and it made me re-evaluate what the campaign is trying to be, asking questions like:

• Is the campaign meant to be 'The Way' how to play the game or just 'extra content'?
• Should the campaign try to mimic Freeplay?
• Is losing progress and starting from scratch that much of a problem?
• ...

In my mind, if we would be trying to create 'The Way' how Factorio is intended to be played, it would make sense to try to stay very close to how Freeplay works, since that has been 'The Way' for many years now. However trying to mimic Freeplay inherently means it's never going to be identical to Freeplay, while certainly adding some new problems (and hopefully benefits).

Trying to be similar to Freeplay and create a representation of how Factorio 'should be played' was the mindset behind the work-in-progress expanding campaign. The main benefit compared to Freeplay would be that the content is segmented into smaller chunks (which is already kind of the case due to the science pack production/technology progression - the player can't build everything from the start). However, having a short-term quest, being in a limited area of the map, interacting with existing factory ruins that prevent the player from going to the next area, etc. brings a lot of unexpected problems. It was just not fun to play in comparison.

With that, the Freeplay with all its freedom will probably always be the best way how Factorio is experienced. It would make a lot of sense (to me) to rather strive to create a set of smaller scenarios as side content to give a fresh experience after 2,000 hours of Freeplay. To extend Factorio with separate scenarios, instead of trying to re-invent Factorio with the expanding campaign.

Being side content, I believe it'd be much more acceptable if progress is lost between levels if it creates fresh gameplay or an interesting challenge. The reason we chose the expanding map concept was to never force the player to lose progress and rebuild their base. If this restriction is lifted, we could split the scenarios over many levels. Over the Christmas break, I tried to recycle the work-in-progress expanding map into a set of separate levels, and we even implemented a playable but very crude version of them in the first week of January.

We sat down last week to reconsider what to do with the campaign out of the two options from FFF-329. The expanding campaign felt too risky due to all its problems, and we were not sure enough about it. The separate levels would be a safer option, but if they are not the main way to play the game, then they are not as important as the core of the game for the 1.0 release.

It is still possible we will add a campaign after the 1.0 launch, but for now we believe that abandoning the idea of a campaign gives us the focus we will need on the core of the game for the upcoming months.

Today I would like to talk about changes in the Train Pathfinder I made for 0.18. They are subtle changes to fix weird corner cases, but first a short glossary:

• Rail - a single entity over which trains can ride. The basic unit of building.
• Segment - a series of rails that are not split in between by junctions, signals or stations. The basic unit for pathfinder.
• Block - a group of segments that are colliding or connected without signals in between. The basic unit for train reservations.

in 0.17 and prior, the pathfinder used classic Dijkstra to find the path with the smallest penalty. The nodes are related to segments with extra information about travel direction. Edges are related to segment connections (transitions).
This was the issue that made me look into the pathfinder code. Train stops are always at the end of a segment. Segments can have at most 2 train stops, one for each direction of travel. Any more is not possible, since the train stop inside would split the segment into 2. This means that a train entering the last segment on its path, must travel the whole distance of it to reach its destination.

As it was implemented, the total cost on nodes was computed as cost of all previous segments and transitions. That means the node with the requested train stop would be picked from a priority queue before the cost of the last segment distance was added. Since the node has the requested train stop on its end, the path would be returned even if there are other nodes with a higher current cost but would be better since the cost of the last segment would be lower. The cost of the current segment would be added to the new nodes during expansion but it was already too late - the path was returned.


0.17 - Pathfinder chooses the bottom path which is longer

The fix was quite simple: include the node's segment length into the node's total cost from the start. This changed the node expansion code as it was not adding the cost of the current node's segment, but the next node's segment. This would lead to cases where the first segment distance would not be counted, so I added code that when creating starting nodes, creates them with the penalty of the whole starting segment.


0.18 - Fixed Pathfinder chooses upper path that is shorter

The second issue is also related to the last segment and has a similar explanation as the issue above. The cost of the train stop in the current segment was added only when expanding node to the next segments.


0.17 - The pathfinder chooses the bottom path because it does not contain the penalty of the opposite station

The simple fix of shifting the train stop penalty by 1 segment (when expanding, add the cost of the train stops to the next segment, not the current segment) and including both train stops inside the start segment fixed the issue (this is not the final solution as it will be explained in issue 5).


0.18 - The fixed pathfinder chooses the upper path that is shorter. Both paths have a penalty of 1 station.

Now after the fix for issue 1 I noticed that adding the penalty of the whole starting segment has a flaw - if a train can go in both directions and both train ends are in the same segment, the cost of the first segment would be same in both directions and would cancel out.


0.17 - The pathfinder chooses to go left. Path to the right has a cost higher by 2.

The fix here was simple: since the pathfinder is only given the start rail in the first segment, it has to go by all the rails in a given direction to find the end rail in a given segment. I have added the distance measurement during that search and used it as the initial cost. That way the position of train will affect the initial cost when looking at paths for both directions.


0.18 - the fixed pathfinder chooses to go to the right. The train position is considered.

Now that issue 3 was fixed, there happened to be extra code to handle single segment paths. It covers weird cases such as cyclic segment, or station in the same segment. This code is computing the path cost based on rails (not segments) and if it finds any path, it will choose the path of lowest cost and skip the main pathfinder logic for multi-segment paths.


0.17 - The pathfinder chooses the single segment path.

The solution for this - if there exists a single segment path, create marker node with cost of shortest single segment path and throw it into pathfinder priority queue. If this single segment path is truly the shortest, then this marker node will be picked up during expansion meaning all the multi-segment paths have a higher cost. If there would be a shorter multi-segment path, this marker node will not be picked up in time and so will be ignored.


0.18 - The fixed pathfinder chooses the multi-segment path because it has a lower cost.

After the fix for issue 2, every segment on the path with train stops would add the penalty of the train stops, not counting if it was on an entrance or exit of the segment. This means that a double-sided train for which one end is inside the segment with a train stop that is under the train, would still consider that train stop in the penalty.


0.17 - The pathfinder chooses the left path since the right path has the penalty of the train stop

Based on this, I decided to discard the penalty of opposite train stops in the first segment. Doing performance measurements here showed another issue: the fix for issue 2 was flawed. The penalty of the goal train stop in the last segment should not be added, because this forced the pathfinder to over-expand nodes up to the train stop cost looking for other paths that maybe would not have that last station penalty (when in fact, it was unavoidable). So now I saw: the opposite train stop in the first segment and the goal train stop in the last segment must not add a penalty. This gave the final solution for the train stop penalty: when expanding a node, the exit train stop in the current segment adds a penalty and opposite train stop in the next segment entrance adds a penalty.


0.18 - The fixed pathfinder chooses the right path. Train stop under the train is not counted.

This is quite subtle issue. It is related to this penalty rule:
"When the rail block is occupied by a train -> Add a penalty of 2 * length of the block divided by block distance from the start, so the far away occupied paths don't matter much."

This means that looking for path, not only the cost from the start is counted, but also the number of blocks from the start - every time a node expands to another segment that is from a different block than the previous node's segment, increase the total block count from start by 1. That was working fine as long node expansion would create a new node. In the case of updating a node, the total block count was not updated the leaving old value in the node. That means the updated node would have the cost of new, lower cost path, but would have the block distance from the start of the previous path.


0.17 - The pathfinder chooses the bottom path because blockDistanceFromStart is not properly updated in the upper contraption.

In this contraption, the issue happens in the upper part. The segment under the upper middle locomotive is expanded first when going from the straight segment on its left - it was of lower cost. Now this segment has the cost of the straight path and the block distance from start of 1, since there was only 1 transition to a different block. There was also the penalty of the block being occupied by another train.

When expansion goes through the upper siderail, it hits 4 rail signals and so the block distance from start is increased up to 4. This path has a higher cost up until the left rail signal near the upper middle locomotive. Here, however, the cost of the block occupied by another train is lower since we are entering the 5th block from start when going through the upper path. The side-rail path is chosen to update the node cost related to the segment with the upper middle locomotive, but the block distance from start was not updated. Because of this, the penalty on the next rail signal that goes to another occupied block, was equal to the last segment distance divided by 2 instead of 6. This difference would make the path through the bottom contraption of lower cost since the straight path here is cut and the node for the segment under the middle locomotive is created with the proper block distance from the start.

The fix was simple: when changing the cost from the start on an existing node, also change the block distance from start.


0.18 - Fixed pathfinder chooses upper path

This is not exactly a pathfinder issue but it lead to trains being stuck. If a train is waiting on a signal, it will repath periodicaly to find another possible path that may now be unblocked. The repath however clears the counter of how long the train is waiting on the signal. Periodic repath logic was aware of this so it would restore the previous waiting on signal tick counter when the train entered arriving-to-signal state. However some fix ago changed train behavior, and the train no longer goes through the arriving-to-signal state and so the tick counter was cleared. This broke the following rule:
"When the path includes a train currently waiting at a rail signal -> Add a penalty of 100 + 0.1 for every tick the train has already waited."


0.17 - The right train is stuck because the time-dependent penalty of the left train is reset every time the left train repaths.

Universal fix here: clear this counter only if the train changes state to anything other than waiting-on-signal.


0.18 - The fixed ticks waiting on signal logic, after 3 repaths the penalty of left train increases to a point where right train chooses the long path.

In the heart of the pathfinder there is a priority queue that collects open nodes. As it was implemented up until now, the priority queue was based on a double-linked list. Finding the node with the lowest cost (highest priority) was fast (constant), but inserting new nodes or updating existing nodes would be, in worst case, linear (O(n)). After a quick prototyping phase, I decided to implement a binary heap with min-property over array. This change alone gave around a 20% speedup to the pathfinder.

The second optimisation applied was the addition of a heuristic function that gives the minimum cost to any end. This means that node expansion is now guided into the goal by the heuristic function, and so less nodes should be required to visit before finding the goal. This gave another performance increase.

The rough guess as to impact of the train pathfinder changes, is that its about 2x faster, and should have fewer weird edge-cases.

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

• Train stop at train's starting segment exit is no longer counted into penalty. more
  
• Inventory transfers mini-tutorial has been updated to feature the quickbar.
  
• Split the map editor sub-menu into more options so it's more clear when scenarios are copied and when they are edited directly.
  

• Fixed replay gui covering tooltips. more
  
• Fixed tooltips in statistics window not showing force modifiers. more
  
• Fixed electric mining drill was missing dying explosion. more
  
• Fixed when using OpenGL backed turret range overlay was rendered incorrectly when zoomed in. more
  
• Fixed a crash when using script.get_event_order during control.lua init. more
  
• Fixed that LuaForce::reset_technology_effects() could change the enabled/visible when disabled state. more
  
• Fixed wrong lua docs about what event(s) could be filtered. more
  
• Fixed a wrong error message related to multiplayer and migration scripts. more
  
• Fixed crash when rail with temporary train stop is removed. more
  
• Fixed crash if you attempted to ping a train wagon immediately after placing it on a multiplayer server with high latency. more
  
• Fixed that clicking the drop-down widget in the map editor script section would stop the mouse from working. more
  
• Fixed nightvision effect was applied to zoomed-to-world view sometimes. more
  
• Fixed that enemies would attack rails. more
  

• Changed default value of LoaderPrototype::structure_render_layer from "transport-belt-circuit-connector" to "object", in order to be consistent with other on-belt structure sprites. more
  

• Added LuaEntity::get_damage_to_be_taken().
  
• Added LuaSurface::brightness_visual_weights to add back ability to control darkness of the night runtime per-surface. more
  

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

• Steam users can now log in automatically through Steam without needing their Factorio account password.
  
• Steam users without a Factorio account can create one by providing only a username.
  
• Reworked main menu structure.
  
• Added a "Continue" button which quickly loads the latest save game.
  
• Added a "New Game" GUI that shows all the ways to play the game
  
• Added a setting to the map editor to show/hide the extra entity settings.
  
• Added a map editor GUI to edit force data modifiers.
  
• Added a PvP team option to create a moat around the starting area.
  

• Added animation to water.
  
• Added animation to trees.
  
• Added LUTs and color corrected the game sprites.
  
• Added sliders to the graphics settings to adjust brightness, contrast, and saturation.
  
• Added on damaged effects for most entities.
  
• Added specific dying explosions for most entities.
  

• New or updated sound effects include:
  
• Nuclear reactor, chemical plant, furnace, fire, burner mining drill.
  
• Tank.
  
• Mining by hand, chopping wood
  
• Roboport door, Combat robots
  
• Player footsteps.
  
• Biter and Spitter footsteps.
  
• Worm breathing, Spitters and Biters, idling and attacking.
  
• New sound features include:
  
• The ability to fade out sounds instead of a sudden stop, e.g. for the furnace.
  
• Varying the pitch of sounds to a min/max level, to add more variety.
  
• A 'Random, no repeat' feature to reduce repetition, especially on sounds that happen frequently, such as player steps.
  
• The sound for the game has also been rebalanced to highlight certain sounds and make others fade into the distance.
  
• The default sound settings have also been updated to improve this mix.
  

• Optimized particle logic.
  
• Improved performance when side-loading transport belts.
  
• Improved performance of inserters interacting with assembling machines and furnaces.
  
• Improved performance of inserters when the circuit network turns them off.
  
• Improved performance of mining drills and inserters in general.
  
• Improved performance of burner entities.
  
• Improved performance polluting entities.
  
• Improved performance of smoke producing entities.
  
• Improved performance logistic and construction robot performance when they're flying towards their target.
  
• Improved performance of furnaces and assembling machines that use fluids.
  
• Improved heat pipe performance by 3x.
  
• Improved item request proxy performance by turning them off in 99%+ of the cases.
  
• Improved locomotive, cargo wagon, and fluid wagon performance by turning them off in 99%+ of the cases.
  
• Electric networks, fluids, and heat pipes are updated in parallel if you have enough cores.
  
• Improved script rendering performance for text and lines.
  
• Improved performance of rotated bounding boxes.
  

• Fixed the recipe tooltip showing negative values for some complex recipes. more
  
• Fixed graphical glitch when GUI element with blurred background got out of bounds of the screen. more
  
• Fixed hard coded English string in NPE. more
  
• Fixed potential crash in NPE when Compilatron is pointing at something that gets deleted. more
  
• Fixed issue where sometimes you couldn't move to the second area in NPE. more
  
• Fixed issue where Compilatron would sometimes tell you to build more boilers when that was not the problem. more
  
• Fixed issue where Compilatron's speech bubbles could block you from interacting with the world behind him. more
  
• Fixed items with excessively long names squashing the count label in the recipe tooltips. more
  
• Fixed accumulator charge text in statistics bouncing around because of inconsistent number of digits. more
  
• Fixed train path finding penalty when there are 2 or more trains in block. more
  
• Fixed a crash when creating trains during the player moved event that was caused by the player getting ejected from a vehicle because the vehicle died. more
  
• Fixed a crash when removing mods that had custom GUI elements. more
  
• Fixed a crash when using Lua event filters when the thing to be filtered becomes invalid. more
  
• Fixed that some turret sounds could be heard on other surfaces. more
  
• Fixed that the tooltip for the generator would not show its efficiency correctly. more
  
• Fixed a crash related to building tiles in multiplayer with some mods. more
  
• Fixed that turrets would sometimes fail to attack things that are in range. more
  
• Fixed follower robot lifetime tooltip property not taking into account following_robots_lifetime_modifier. more
  
• Fixed cliffs sometimes getting marked for deconstruction when they shouldn't have been. more
  
• Fixed inconsistent rounding in the statistics window. more
  
• Fixed a desync when setting .active=false on beacons through script. more
  
• The map will be re-charted when the mod configuration changes. more
  
• Fixed inserters sometimes not being highlighted when selecting a large modded vehicle. more
  
• Fixed a crash when entity grid would destroy itself during update. more
  
• Fixed a crash with rich text tags and dynamic images. more
  
• Fixed setting the held stack of an inserter didn't update the inserter state correctly. more
  
• Fixed tooltip alignment in some specific cases. more
  
• Fixed a crash when lua removes pipe-to-ground between entity revive and deferred pipe connection fix. more
  
• Fixed a crash when setting infinity chest filters to legacy items. more
  
• Fixed that splitters could be set to have invalid bounding boxes that would lead to corrupt saves. more
  
• Fixed word wrapping of rich text containing tag that doesn't fit given width would duplicate the tag on multiple lines. more
  
• Fixed if migrating old achievement data to Steam Cloud failed, the old file would not be deleted resulting in the same error on every startup. more
  
• Fixed train pathfinding penalty for circuit network closed rail signal was not applied in some cases. more
  
• Fixed a crash when mods would define construction robots without some sprites. more
  
• Fixed that trying to do 0 damage would still trigger the entity-damaged event. more
  
• Fixed a save corruption issue related to modded loaders with different belt_distance values. more
  
• Fixed that train would forget amount of ticks waiting at signal when doing repath. more
  
• Fixed that train pathfinder was not counting penalty of last segment length in path cost. more
  
• Fixed PvP error on configuration changed. more
  
• Fixed pump tooltip showing double pumped amount when pumping to fluid wagon. more
  
• Fixed manual ghost revive of a loader in unload mode would not work in visually matching direction. more
  
• Fixed calling LuaEntity::order_deconstruction() on item-request-proxy would corrupt the game state leading to crash. more
  
• Landfill can be placed over shallow water.
  
• Fixed that LuaEntity::color wouldn't accept "nil" to reset the color. more
  
• Fixed that train pathfinder was not counting penalty of opposite train stop at last segment.
  
• Fixed that train pathfinder was counting penalty of whole starting segment instead of only part in front of locomotive. more
  
• Fixed that train pathfinder would return single segment path even if there are shorter, multi segment ones. more
  
• Fixed technology screen not showing modifier tooltips when tooltip descriptions are disabled. more
  
• Fixed belt tooltips sometimes showing their speed in exponent format. more
  

• Added UnitPrototype::light.
  
• Removed the "particle" prototype type.
  
• Added the "optimized-particle" prototype type.
  
• Added the "burner-generator" prototype type.
  
• Removed GeneratorPrototype::burner.
  
• Added the "pass_through_mouse" option to speech bubble styles. This lets mouse interactions fall through to interact with the world behind.
  
• Added optional "radius_color" property to capsule prototype.
  
• Removed EntityPrototype::emissions_per_tick, it is replaced by emissions_per_second.
  
• Removed EnergySourcePrototype::emissions_per_second_per_watt and emissions, they are replaced by emissions_per_minute.
  
• Removed TilePrototype::ageing, it is replaced by pollution_absorption_per_second.
  
• Removed ItemPrototype::stackable, primary_place_result_item and can_be_mod_opened, they were replaced by ItemPrototypeFlags "not-stackable", "primary-place-result" and "mod-openable".
  
• Added "probability" to trigger items and trigger effect items.
  
• Added "script" trigger effect item. It will call the "on_script_trigger_effect" when triggered.
  
• Added AttackParameters::rotate_penalty and AttackParameters::health_penalty.
  
• Added generic support for rendering radius visualisations on entities through radius_visualisation_specification.
  
• Changed construction robots and logistic robots sprites to be optional.
  
• Changed the loader prototype type so it has a fixed belt_distance of 0.5.
  
• Added the prototype type "loader-1x1" that has a fixed belt_distance of 0.
  
• Changed render layer of belt structures (underground belt, splitter, circuit connector) to object layer. They now have special sorting logic, so they are not rendered over player or cars.
  
• Horizontal directions of splitter sprites were separated to two sprites (for purposes of the special sorting logic).
  
• Added AttackParameters::ammo_categories.
  
• Added optional artillery projectile property "rotatable".
  
• Scenarios can now contain a description.json file. In the file "order" determines the sorting in the New Game gui; "multiplayer-compatible" determines weather the scenario is shown for multiplayer games.
  
• Added "multiplayer-compatible" to description.json file of campaigns also.
  

• Added on_unit_group_finished_gathering and on_build_base_arrived events.
  
• Added LuaRendering::bring_to_front().
  
• Changed LuaGameScript::particle_prototypes to reference the optimized-particle type.
  
• Added LuaGuiElement::scroll_to_item() function.
  
• Renamed LuaInventory::hasbar(), getbar() and setbar() to supports_bar(), get_bar() and set_bar().
  
• Added LuaEquipmentPrototype::attack_parameters read.
  
• Added on_script_trigger_effect event.
  
• Set lower limit of zoom parameter of LuaGameScript::take_screenshot to be 0.0315 (1 pixel per tile) instead of allowing any value greater than 0.
  
• Added LuaPlayer::get_infinity_inventory_filter(), set_infinity_inventory_filter() functions.
  
• Added LuaPlayer::remove_unfiltered_items, infinity_inventory_filters read/write.
  
• Added LuaSurface::get_entities_with_force().
  
• Added optional "dealer" parameter to LuaEntity::damage().
  
• Added "force" filters to the on_built_entity and on_robot_built_entity event filters.
  
• LuaSurface::min_brightness doesn't have any effect on rendering as brightness of night depends only on color LUT of night.
  

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

Join our community hosted Massive multiplayer test

Find it in the Matching server with the name: Big Community Games Test.

You can also connect directly with the address: bigcommunitygames.uk.to

Read this post on our website.

Up until I looked at the source code, I was always confused about the differences between "Start campaign", "New game" and "Scenarios". New game seems like the same thing as "Scenarios"->"Freeplay", but are there any differences? We then later added a few more bonus scenarios, but they are hidden in the scenarios menu, with no explanation about what each is, what to expect or if it works in multiplayer. I believe it's very important to communicate to new players information about the game's content. It's also important to show that freeplay is the intended way to play. So all this prompted me to rework the main menu a bit.

I started with the structure. The structure always seemed odd to me, compared to what I'm used to from other games. Important options like "Load game" are lost among options that are never used (like "Replay game").
So I came up with a new structure. It looks like this:

• Continue
• Single player
  • New game
  • Load game
• Multiplayer
  • Host new game
  • Host saved game
  • Browse public games
  • Browse LAN games
  • Connect to address
• Map Editor
  • New scenario
  • Convert save
• Settings
  • ...
• Mods
• About

The first new thing to notice is the "Continue" button. Since "start the game and continue my last save" is probably the most common thing players will do, it makes sense that there is an option for this right at the top of the main menu. The button will contain the name of your latest save. Pressing it will immediately load the game and get you in game. Due to implementation complications, for now it only handles save games and it will NOT connect you to the last server you played on if your last play session was multiplayer, but I might implement that if it's highly requested.

Next, everything was grouped into either Single player or Multiplayer. There are much fewer options, since "Replay game" was moved as a small button in "Load Game", and every way to start playing the game was moved to the new "New Game" GUI.

The "New game" GUI shows all the ways to play the game. It also groups them nicely, places freeplay on top, shows a description and even a nice image. This GUI is used for new game, multiplayer hosting and map editor, thus simplifying the menu quite a bit.



For modders, scenarios can now contain a description.json file. In the file "order" determines the sorting in the New Game GUI; "multiplayer-compatible" determines whether the scenario is shown when trying to host multiplayer games. "multiplayer-compatible" was added to description.json file of campaigns also.

While working on the main menu, another thing I changed quite a bit is how logging in is handled. With Sanqui's help, we did some small improvements, such as better error handling and error localization, but a more important feature is being able to log in using Steam only. I found it annoying that even though you bought the game on Steam, if you want to play online, you need to make yet another account, whose email and password you are probably going to forget.

For the Steam version of the game, when you try to use any online feature, the game will try to authenticate using Steam.

• If you have an account and that account is linked to your Steam account, you will be automatically logged in without having to remember your password.
• If you don't have an account, the game will ask you to choose a username (your nickname in multiplayer games) and then log you in. No password or email or email confirmation required. We call these "mini-accounts"

"Mini-accounts" can be upgraded to normal accounts by going on the website, logging in using Steam, and then adding an email and password. They can be used for the non-steam version of the game.

These changes are ready to be released, so you should see them as soon as we release 0.18, soon™.

A few years back, we were using a collection of hard drives stuffed into a leftover workstation as an office shared drive. This drive had all sorts of stuff on it, from unfinished art assets, to a collection of pictures of developers in a wind tunnel, we had it all. The inevitable day came, and we ran out of space on the disks. A decision was made at the time, to buy some new, high density drives, and put them in a QNAP enclosure. This is basically a little computer, with 4 front mounted hard drive bays, and some special software for file shares and management. We figured this should be less hassle since it’s designed to be used by normal people. This was supposed to make our lives easier, as it should be an easy-to-use setup for normal people. It even had a friendly GUI with a little clippy guy!


"It looks like you're trying to setup replicated live snapshots"

After only three months, unfortunately the little guy died. Doesn’t power on, just dead. Of course, we start the return process, but it’s going to take about a month to get the replacement sorted, during which time we will be without access to our files. So, we did what any reasonable capitalists would do, and we bought our way out of the problem once again, by just buying another QNAP NAS to use while we waited. When the warranty replacement arrived, we would use it as a backup target.

Side note: we couldn’t actually read our data off the drives we took out of the broken QNAP. The QNAP OS is just Linux with a custom GUI on top, so you’d expect we could get our files by plugging them into another Linux machine, but no! QNAP have customised their Linux kernel in a way that makes it impossible to read on a normal install (for those interested, they modified LVM to add some more efficient form of snapshotting, from what I can tell). Mmm... delicious vendor lock-in!

All was well with the world of large file storage in Wube software, until one day disaster struck again!
After a solid 14 months this time, the replacement NAS that we had bought also died. At this point, we begin to question our decisions.

With our original setup, we had a normal PC running the ZFS filesystem. We have decided to just return to this approach. The final lesson is, that sometimes the "buy the solution" easier option is not actually easier at all. Sometimes it’s just best to invest the time and effort to do it right yourself. If you're a technically inclined person who's not afraid of a command line, you should really check out ZFS. Despite some recent misinformed statements by highly influential figures, it is a really great filesystem with advanced features not really available in any other production quality filesystems, like snapshotting, checksumming, and live replication.
Oh, and you should probably avoid QNAP NASes...

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

Read this post on our website.

Our e-shop is now open again after taking a break over the holidays and new year.

We have also restocked our new Factorio sew-on patches, so if you didn't manage to pick one up over the last weeks, now is your chance to order one.


After deciding to cancel the Introduction/NPE (Tutorial/Demo) we took some time to assess what we learnt. Here are just a few of the points that we took away from the experience:

• Players dislike being told that they must restart.
• Players (ironically) don't have regrets after they restart.
• It is valuable for new players (< 30 hours) to rebuild 1-3 times.
• Lowering player constraints increases design difficulty.
• People like Compilatron to be there.
• People don't like it when Compilatron does anything for them.

In addition to those, self-motivated discovery of new mechanics (FFF-327) is a more important part of Factorio than actually using the new mechanics. This means letting the player do things the hard way, and not rushing them to the realization that there is a better way. For example, veteran players know not to handcraft science packs for 30 minutes while standing still, but forcing a player to discover this by artificially not allowing them to handcraft, lessens the Factorio experience.

While we were working on the Introduction/NPE we were also researching and designing what we wanted from a full featured Campaign. The game already had a Campaign which took the player up until Advanced circuits, but there was a feeling that we could do better. For the last year we have been working on and off to implement the design we came up with (from here on called the Expanding campaign), as talked about in FFF-245, FFF-257, FFF-291. More specifically the design was trying to remove the feeling of lost progression that comes from starting a new level and being forced to build a new factory from scratch.

After the Introduction/NPE was cancelled, we took the holiday period to reassess if this goal was worth pursuing, and thought we should at least prototype some alternate solutions before committing completely to "the one design". The prototype came together very quickly this week because we were able to reuse a lot of work from the Expanding campaign prototype.

Now we have two prototypes and wanted to present the ideas behind them:



This is the main prototype that we have been working on so far. A single map which starts small but grows after each objective is complete. This would emulate Freeplay gameplay in that the player can build very large bases and expand in the directions they want, but with quest objectives to steer the player towards building the rocket.

Technology and progression are preserved perfectly, since we never ask the player to start again. As a result, the player can build a really big factory. This prototype focuses more on the long term problem solving that Freeplay requires, such as deciding where your next outpost will be.

Main Problem: At the end of each 'chapter' the number of different situations the player could have gotten themselves into is near infinite. This makes it very difficult to predict the state the player is in, and construct an appropriate challenge. Clever objective and map design should be able to mitigate this issue.



Consisting of approximately five separate missions, each with an interesting starting condition. At the start of the level, all the technologies available in the last mission are pre-researched, and the player is given a new subset of the remaining technologies to be researched.

Every level the player needs to build a new factory. They will have some starting items, and the gameplay is about short term problem solving. This would be very different from Freeplay and similar to what people expect from traditional campaign content. If the player fails, or wants to try a different strategy, they can restart the level and not lose a lot of progress.

Main Problem: Players need to rebuild their factory each level, repeating things they have already done. This is especially problematic in a game like Factorio. We imagine that this issue can be mitigated by making the starting conditions interesting.
While these two prototypes have some large differences, there are many aspects they share:

• Freeplay will stay the same regardless of the choice here.
• No story.
• No exploration gameplay.
• Same tech tree as Freeplay.
• All content of Freeplay available at some point.
• Complex concepts (oil/logistics/trains) are broken down into smaller pieces.
• Almost identical quest structure.

These two approaches are actually very similar in their core quests, this is more of a decision on how we present the progression. Internally we are still discussing which approach is more appropriate for Factorio.

Over the last weekend the Youtuber The Spiffing Brit hosted a server with the goal of completing a speedrun with 500 players online at the same time. There were 2 streams in total, one on Friday evening, and another on Sunday. Things went a lot more smoothly on Sunday, and we managed to reach a peak player count of 462.

Spiff has edited down the stream from Sunday into a much shorter video, so those who could not attend can enjoy the spectacle.



There will be some further attempts to set a new record soon, with some upgraded hardware. Just recently one of the organizers of the server on Sunday has confirmed the order of a i9-9900k with 10 gigabit networking. If you are interested in more info on the servers, you can join the discord here.

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

Read this post on our website.

Hello,
The office here in Prague is still 'closed' until next week, so not much is happening (so our team can rightfully rest). Things will get cracking again on Monday, and our first task is to get 0.18 done!

For that reason, the FFF today is a little on the short side.
2019 was quite a 'typical' year for us. We released 0.17 early in the year, did some bug-fixing for about 6 months, and then we went back to development work. Saying that, we hit some major milestones this year:

• There was the all time concurrent player peak of over 22,500 with the 0.17 launch.
• The historically low count of bug reports on the forum.
• 2 million sales which we reached just last week.

You can see some correlations between this timeline and the commit frequency graph below.


Please note, the number of commits does not reflect the value and quality of an individual :).

It seems like we are somewhat 'in-sync' with each other, which I suppose has good and bad effects.

This year was also pretty good for the FFF blog itself. I would even say, this was the best year yet, with the highest quality and most well received posts we have ever produced.

In terms of readership (on our website), here are the top 5 FFF posts of this year:

• Friday Facts #283 - Prepare to Launch
• Friday Facts #282 - 0.17 in sight
• Friday Facts #317 - New pathfinding algorithm
• Friday Facts #303 - Under 100 bugs (but still not stable)
• Friday Facts #278 - The new quickbar

No surprise that our 0.17 launch announcement ones are the most popular.

And here is a graph showing the total website viewership statistics, because I also find them super interesting. You can really see the spikes every Friday :D. It is also funny, this year we started getting a lot of spam emails asking about posting 'sponsored articles' on our website. We would never accept any such proposals.



We really have a tough journey ahead of us this year, we are getting ready for the game to come out on September the 25th... Do or die, come what may. There are 9 months remaining now, and we have our work cut out. We'll keep you up to date on our progress, and we hope you will keep us up to date on your thoughts, at the usual place.

Read this post on our website.

2020 is going to be quite an exciting year for us. We have our 1.0 date set to the 25th of September, and there is a lot of preparation to do.

It is no doubt to any of us that we would not be able to have any success without the great community that has developed for the game over the last years, and the support of all our players and fans.

As is almost tradition, Albert has prepared a commemorative postcard/wallpaper to celebrate the last FFF of the year.



Here's to a great year to come!

I had few months of "vacation" from work by playing world of warcraft classic and generally getting some distance to be able to help with the finishing of Factorio with some perspective and a clear head. Now I have returned from the lands of Azeroth, back to work with fresh mind to finish what is needed - hopefully.

In this time, I was thinking about games in a bigger perspective. I have seen and admired videos related to game creation subject like A Love Letter to GOTHIC's Open World Design, Bethesda's game design is insulting, The decline of Gaming and the unbelievable story of the Fallout 76 fails that goes way further than I thought it can.

And then I played our new tutorial again and realized what we did. We found something very close to a local maximum. To start from the beginning: The whole goal of the new tutorial introduced in 0.17 was to explain Factorio to the wider audience. To make sure, that even someone who wouldn't normally play the game would understand the concept and would automate. The motivation was partially due to the fear of someone playing the tutorial who just doesn't automate on their own. That someone would miss the idea of the game and would had completely wrong perception about the game. For example, that someone would play it only for 30 minutes and would think it is just about endless grinding and manual crafting, and they would never experience the automation midgame which is where the game starts to shine.

This was a noble goal, but we didn't realize all the costs we had to pay for it.

To make sure that the players know how to research and use assembling machines, and they get to experience that part of the game fast enough, we had to force them to do it early on. Firstly, this breaks the progression, which is one of the cornerstones of Factorio game design. The progression in the beginning is roughly this:

Manual Mining -> Automated mining -> Automated logistics -> Automated production & science.

The order of the progression is very important, as in every step you start doing something new that you had to do manually before, so you appreciate the upgrade. Also, when you are starting, you are exploring the game mechanics in the logical order and understand the motivation for those. This is in clear contradiction with forcing players to use assembling machines in the first 5 minutes of the game.

Long story short, there was no way of just tweaking the new tutorials, the fundament on which it was built was wrong. Luckily, I wasn't the only one feeling that way. So I had to do the very hard thing, and telling the people that worked on it, that we are scrapping it, and in 0.18 we will switch to using the old tutorials again. They are way less polished with lower production value, but these things are much less important than the core gameplay mechanics as far as I can tell. We plan to tweak several things in the old tutorials, but the structure is planned to be kept the same.

This is definitely a lesson for the future.

It has long been on the horizon, and the Christmas gift giving has given us that last push, for us to reach 2,000,000 sales. I would say its quite an achievement for a Indie game that has never been on sale.

We first hit one million sales in May of 2017 (FFF-192), so its been about two and a half years to sell another 1,000,000 copies. I wonder how long till three million... Any bets?

I find it quite interesting (and not surprising) to look at the proportion of the sales that come from each of our distribution channels. As you can expect, Steam accounts for the majority of all copies of the game sold.



What is also interesting, is that we had a lot more sales on our site before we launched on Steam. Either this is Steam cannibalising our website sales, or just everybody who wanted to buy it on our site did so before launching on Steam. Another data point for speculating on, is that 81.3% of people who purchased the game on our website, redeemed and activated their Steam key. Factoring that into the above numbers, about 96.7% of all players own the game on Steam.

When we reached one million sales, we threw a party to celebrate. We're not going to do the same this with this milestone, but we are thinking of having a party to celebrate the 1.0 launch next year. Any news of that will of course be communicated in the usual way.

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