Feb 7, 2020

Factorio - Klonan

Read this post on our website.

Hello,
We released 0.18.4 this week, same old same old, more bugfixes, more bugs, more changes. At this stage of development, not many interesting things are happening, we are just polishing what we have.

Minor terrain render optimization (posila)

Just a couple days before the release of 0.18.0 I had an epiphany about a terrain rendering problem that was bugging me for a really long time. When rendering terrain, we reuse the texture from the previous frame. How this was always done, is that we would render the texture shifted to the new position, fill up the gap, and then copy the final result back into the texture for reuse in next frame. So what was bugging me about this? This simple operation would result in rasterizing 2 screens worth of pixels. While that is not a problem for at least half decent GPUs from the past decade, it's a significant work load for integrated GPUs, which in general have an order of magnitude lower memory bandwidth than dedicated GPUs. It could also be equally bad for old low-end dedicated GPUs.

One of the extreme examples is the Intel HD Graphics 3000 - an integrated GPU on the Sandy Bridge CPU architecture. When you sit still and the terrain can be reused without shifting, it would take 'just' 2 milliseconds to copy it to the game view. But when you started to move, the GPU time to render the terrain could go up to 5 milliseconds. And that is only at 1600x900 resolution. Not even 1080p. So, it was bothering me we were spending nearly 1/3rd of a frame time (16.66 ms) to render the terrain, when the engine has much more work to do to render the rest of the game (for comparison GeForce GTX 750Ti or Radeon R7 360 would do the same under 0.5 ms at 1080p).

The realization I had, was that I can 'scroll' the buffer texture. If I remember the offset of the top left corner, I can un-scroll it to the game view, and then instead of copying all the terrain back to the buffer, we can just adjust the offset and update the parts that changed. So, the number of pixels copied is proportional to how much the terrain scrolled. It is so simple I am embarrassed not to have figured this out years ago.

https://cdn.factorio.com/assets/img/blog/fff-333-tile-buffer.mp4

Most people could not have noticed this optimization, as most GPUs people have nowadays did the un-optimal thing in a fraction of a millisecond already. But it still made me very happy to be finally able to remove this inefficiency. Contemporary integrated GPUs are also significantly faster, and while it might not be as much of a challenge to render the game for them, they do share some resources with the CPU - be it the last level of cache, or CPU cooler, so the integrated GPU working hard may cause the CPU to slow down.

However, the point I wanted to illustrate by this post is how broad a range of GPUs there is. People see a 2D game and expect to be able to play it on essentially anything. If we want to live up to that expectations, we have to impose a lot of limitations on ourselves, because 'anything' also includes a couple orders of magnitude slower GPU than is found in an average gaming computer of today. CPUs got a lot faster in the last decade too, but mostly due to increasing the number of cores and adding wider vector computation units. They didn't get that much faster when executing serial code, which is unfortunately most of Factorio's game code. So if you play the game on a laptop with a Core 2 Duo and GeForce 320M, you'll run into framerate issues due to the weak GPU much sooner than a UPS slowdown due to the old CPU.

Side note: You might ask, why do we bother with caching the terrain in the first place and not just re-render it from scratch every frame. Short answer is - because Factorio's terrain rendering is insane due to its complicated tile transition rules, and re-rendering it every frame is just not fast enough.

Jan 31, 2020

Friday Facts #332 - More sounds & Map color tweaks

Factorio - Klonan

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.

New Sounds (Ian)

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.

Updated map colors (Klonan)

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.

Community spotlight (Klonan, V453000)

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

KoS 500 player MP server

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}.

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.

New 0.18 Any% speedrun record

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!

The Biggest and most Useless Rail Network Ever...

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.

Jan 24, 2020

Friday Facts #331 - 0.18.0 release & Train pathfinder changes

Factorio - Klonan

Read this post on our website

0.18.0 release (Klonan)

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.

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.

Campaign cancelled (V453000)

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.

Trains Pathfinder changes (boskid)

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).

Issue 1: the last segment distance is not counted into penalty

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

Issue 2: the opposite station in the last segment is not counted into the penalty

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.

Issue 3: the first segment distance would not consider train position

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.

Issue 4: a single segment path had priority over multi-segment paths

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.

Issue 5: the opposite station in the first segment was added into the penalty

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.

Issue 6: the block distance from the start was not updated properly

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

Issue 7: repathing would clear a train's counter of ticks waiting on signal.

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.

Train Pathfinder optimisation - priority queue

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.

Train Pathfinder optimisation - heuristic (conversion from Dijkstra to A*)

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.

Jan 21, 2020

Version 0.18.0 released

Factorio - wheybags

Features

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.

Graphics

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.

Sounds

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.

Optimizations

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.

Bugfixes

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

Modding

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.

Scripting

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.