• Basic oil processing produces only Petroleum gas, for more streamlined oil setup in the beginning.
  
• Basic oil processing keeps some of the refinery input/output slots unused, so it is more clear which ones will be used by Advanced oil processing.
  
• Chemical science pack requires Sulfur instead of Solid fuel.
  
• Flamethrower ammo requires crude oil instead of heavy and Light oil.
  
• Rocket fuel requires light oil.
  
• Laser Turrets, Lubricant, and Worker robots technologies need Chemical science pack.
  
• Deathworld marathon preset was made a little bit easier.

• Fixed a crash when trying to show invalid thumbnails for mods. more
  
• Fixed that up/down keyboard navigation of the load/save game GUIs and manage mods GUI didn't work in some cases. more
  
• Fixed that cloning belts with items didn't preserve the item positions correctly. more
  
• Fixed a script error in train stations mini-tutorial. more
  
• Fixed a script error in the NPE. more
  
• Fixed car turret shadow would rotate in opposite direction to the turret. more
  
• Fixed that changing sound settings didn't persist through game restart. more
  
• Fixed that the migrated-content GUI wouldn't show in some cases. more
  
• Fixed that right-click-and-drag didn't work in the blueprint GUI to remove things. more
  
• Fixed that unit groups would use paths going through cliffs. more
  
• Fixed some cases of entity rotation with blocked underground pipes. more
  
• Fixed inserters sometimes getting stuck when picking up from a non-backed-up underground belt. more

• Added CraftingMachinePrototype::default_recipe_tint.

• Added LuaEntityPrototype::supports_direction read.
  
• Fixed that LuaGuiElement::force_auto_center() didn't work. more
  
• Added LuaGameScript::get_filtered_entity_prototypes(), get_filtered_item_prototypes(), get_filtered_equipment_prototypes(), get_filtered_mod_setting_prototypes(), and get_filtered_achievement_prototypes().
  
• Added workaround for a driver crash when calling D3D11CreateDeviceAndSwapChain. more

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

Read this post on our website.

Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game.



When someone new to Factorio modding is introduced to how they function, they almost always have the same questions:

• Why is mod GUI part of the game state?
• Why do mod GUIs need to be deterministic?
• How can I edit the base game GUIs?

And then comes the explanation:

The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event.

Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game.

That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading.

However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc).

Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI.

There are some critical parts to this new system. It needs to:

• Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort).
• Not break with simple refactoring.
• Not cause other programmers trouble by existing.
• Not prevent base game GUIs from working how they need to work.

So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.


In the last FFF, we presented changes to how Basic oil processing works along with some other changes (mainly moving Worker robots behind Chemical science pack), which resulted in a lot of discussion as it is a very sensitive topic.

We have discussed with as many of you as we could, and in this FFF we would like to present to you what conclusions we came to, and try to explain our ideas in more detail.



A significant portion of you has voiced concerns about removing Light and Heavy oil from the outputs of Basic oil processing, be it about the change itself, or that it does not fit because of some other factors...

Automating Chemical science packs is generally considered to be a huge step by many, mostly because even for veteran players, setting up oil processing consists of many steps, and for newer players there’s many new things to learn very quickly. This change is trying to address both of these issues.



As for the complexity, the most confusing factor is the specific mechanic of the Oil refinery, that all products need to be used or stored in order to keep it working. This is made worse by the common situation that the player can be very far ahead with what they have unlocked with technologies, while being very far behind with what they have already automated.



This can lead to a new player having every Logistic science technology researched before setting up the refinery, and just the sheer number of new unknown items and recipes can get very confusing, especially when some are not really useful at the moment.



One of the ways we can look at the Chemical science pack is "the proof that the player has managed to set up a functional refinery". With this in mind, it fits very well to have them set up a rather basic refinery, and get to know most of the new entities/items/recipes that are necessary to progress, first.



After 'proving' that Basic oil processing is working, the player can proceed to a more advanced version with more outputs and more recipes - but as the player is already familiar with the basics and has their infrastructure already in place (Pumpjacks, oil transport, how pipes work, Chemical plants, ...), it’s not nearly as confusing and daunting to unlock and orient themselves in the Advanced oil processing, yet it still has new concepts to grasp (multiple outputs, cracking, more recipes).



A lot of people have voiced their concern about simplifying the game, but setting up Advanced oil processing (or Coal liquefaction which also has the same challenge of multiple outputs and using cracking) is still mandatory in order to launch the rocket. The learning curve is just smoother.



All in all, we would like to keep this change as we believe it has a positive impact on the game both for newer and veteran players, however when discussing the changes, we realized there are things that would make this change fit in the game much better...

Many of you pointed out that Light oil has very few uses in the game - mainly producing Solid fuel efficiently, but it’s possible to ignore Light oil altogether and just produce Solid fuel from Petroleum gas, sacrificing some Crude oil efficiency for simplicity.



One of the topics repeated many times was that with the proposed changes, suddenly the player is incapable of producing Solid fuel "the right way" (from Light oil) from the start. While this alone is not a big problem and can be justified by "at least the player will appreciate Advanced oil processing more", the efficiency of Solid fuel from Light oil is fairly unobvious, and the player has so many more critical problems to focus on that it’s easy to miss.



We are adding Light oil to the Rocket fuel recipe, and therefore moving Rocket fuel behind Advanced oil processing, with Rocketry taking the pre-requisite of Flammables instead. This should help as a slight hint to produce Solid fuel out of Light oil and to make the recipe a little more interesting - we don’t have many assembling machine recipes with fluid input and a refinery-related fuel recipe is a good fit. One of the obscure details was that the only motivation that made Advanced oil processing mandatory was just Lubricant - which does not feel like a high-tech product - now there is Rocket fuel as well.



The more important question many of you have asked would be "why even make Solid fuel with the changes". This applies even more now that Rocket fuel is behind Advanced oil processing.



One of the great things about the idea of adding Solid fuel to a science pack was that it could be created from the excess Light oil that the player has no use for until unlocking Advanced oil processing. Then it could easily be burned to get rid of it to keep the refinery working, but since Basic oil processing has no excess byproducts anymore, every bit of Petroleum gas is valuable - therefore producing Solid fuel feels like a waste, unless the player has a desperate lack of coal to burn.
There is however an item that is much more useful than Solid fuel, and is also created from Petroleum gas - Sulfur.



It opens the path towards Sulfuric acid (for Batteries both for Modular armor and for Accumulators), and more interestingly Explosives. Unlocking the Rocket launcher often feels like a big side step mainly because it requires setting up Explosives production. With Sulfur set up for the science pack, this is one step more convenient. A similar case occurs with Tank and Cannon shells later.




Therefore we find it fitting to replace Solid fuel with Sulfur in the Chemical science pack recipe, as there are multiple uses for it even with Logistic and Military science packs, and Solid fuel has lost a lot of its charm with the new changes.

One of the obviously controversial changes from the last FFF, was that Worker robots would become gated behind Chemical science pack. Our thought process behind this change was that you need to set up pretty much all of the oil refining recipes anyway, so it is not as much of a big jump as it seems.

In fact, we believe it has been a confusing trap - it has appeared as a Logistic science pack tier technology, but in reality requires all the items that the next technological tier would expect you to have. On top of that, worker robots are a good motivation and reward for unlocking Chemical science pack which does not have that many big shiny technologies behind it.



With the change of putting Sulfur into the Chemical science pack recipe, worker robots are even closer to it as all the items in the science pack directly contribute to getting robots.

With Heavy and Light oil behind Chemical science pack, Flamethrower ammo needed to be moved as well or have its recipe changed. Rather hastily we chose to change the recipe for Petroleum gas instead of the oils which does not make much sense, especially as the Flamethrower turret can’t take Petroleum gas. After some of you pointed this out, it shall be Crude oil instead. Technically you can already use the turret with Crude oil barrels on the offensive, so making Flamethrower ammo simpler is not a problem.



We made slight changes to the numbers in the recipes - specifically, Basic oil processing results in a bit more Petroleum gas (45 instead of 40), and Advanced oil processing results in more Heavy oil (25 instead of 10) than before. This is because it was common to use Basic oil processing over Advanced oil processing when you needed a lot of lubricant for Express transport belts.



We are confident about these changes but nothing is set in stone, so let us know what you think about them. We actually found a bug with the new 'block water input fluidbox' feature we added, so we won't release the changes until we have that sorted. You can test these changes (except the reserved fluid inputs) with this mod.

• Changed expensive variant of electronic circuit to require 8 copper cables instead of 10.

• User verification must be enabled for public multiplayer games. LAN games, direct-connect, and Steam still don't require user verification.
  
• Network message segment size can be configured in server-settings.json, for server providers with large enough upload bandwidth.
  
• Added "Build with obstacle avoidance" into controls settings with CONTROL + Left mouse click as default. It re-introduces the possibility to build rails in ghost mode that avoid trees rocks and cliffs.
  
• Decreased base damage of Personal laser defense from 40 to 30.
  
• Decreased base shooting speed of Laser turret and Personal laser defense equipment from 3 shots per second to 1.5 shots per second.
  
• Reverted combat latency behavior to do latency hiding while in combat. more

• Fixed that extra fast (modded) splitters didn't work properly. more
  
• Fixed an inconsistency between area selection and logistic network highlight. more
  
• Fixed that probabilistic recipe result that is also a catalyst didn't put itself into consumed statistics when the probability check failed and the item wasn't produced. more
  
• Fixed visual errors when dragging train schedule conditions. more
  
• Fixed that locale settings didn't save when changed. more
  
• Solved that pressing ALT while walking right (D being pressed) stopped the character as it interfered with ALT + D. more
  
• Fixed connection preview of underground belt in blueprint in a specific case. more
  
• Changed accumulator/wall/underground belt map color to be more contrast against certain tiles. more
  
• Fixed laser turrets were shooting beams that would last until target was destroyed even if it got out of range and turret stopped shooting. more
  
• Fixed Laser turret shooting speed research didn't increase damage of laser turret. more
  
• Fixed Laser turret shooting speed research didn't increase damage of Personal laser defense equipment. more
  
• Fixed that biters sometimes couldn't get past other biters. more
  
• Fixed that migration scripts couldn't use "require". more
  
• Fixed a crash related to fast-replacing modded generator entities without fluidboxes.
  
• Fixed loaders would not wake up sometimes after picking up items from them manually. more
  
• Fixed that space science pack technology did not have accumulators and solar panels in prerequisites. more
  
• Fixed that switching to another window while dragging a widget (slider) with a tooltip didn't clear the tooltip. more
  
• Fixed that rails would report bounding box sizes of zero when read through the LuaEntityPrototype API. more
  
• Fixed that unit groups could get stuck at the end of their assigned path. more
  
• Fixed a desync related to changing forces in the map editor. more
  
  
• Fixed a crash related to fluid connection changes in mods. more
  
• Fixed that creating character corpses using player_index was off by 1. more
  
• Added extra check to prevent infinite cycle in fast belt building. more
  
• Fixed a crash when building train stations when the backers.json file is empty. more
  
• Fixed that entities could have their light rendered twice. more
  
• Fixed that biters had difficulty pathfinding around crescent-shaped lakes. more
  
• Fixed that the "not enough rails" error didn't work correctly in the map editor. more
  
• Fixed train would not stop exactly in the station preventing pumps to connect to fluid wagons when a mod was changing speed of breaking train. more
  
• Fixed that trains would try to path to train stops on different surfaces. more
  
• Fixed pump would not disconnect from fluid wagon when rail besides pump was mined or destroyed. more
  
• Fixed a crash related to the rail planner. more
  
• Fixed that the mod info label in the technology tooltip didn't line wrap. more
  
• Fixed a crash near the start of the NPE. more

• Changed how beams are drawn to improve seamless tiling of beam segments. Head and tail segments are now stretched to fill space from source/target position to next segment.
  
• Changed how beams apply damage. By default, they no longer trigger their action every damage_interval, instead the action is triggered when its owner triggers shooting. The old behavior can be turned on by setting BeamPrototype::action_triggered_automatically to true.
  
• It is possible to specify fluid product or ingredient with a fluidbox_index so they use exactly one slot corresponding to the specified fluidbox of the machine.
  
• Changed the "market" entity from entity-with-health to entity-with-owner so it now has a force and unit_number.
  
• Changed fluid energy source prototypes to error when no consumption limits are set instead of logging a warning.
  
• Added util.parse_energy().

• Added LuaGui::screen.
  
• Added on_gui_location_changed, on_gui_selected_tab_changed, and on_gui_switch_state_changed events.
  
• Added LuaGuiElement type "empty-widget", "tabbed-pane", "tab", and "switch".
  
• Added LuaGuiElement::add_tab(), remove_tab(), and force_auto_center().
  
• Added LuaGuiElement::location, auto_center, drag_target, selected_tab_index, tabs read/write.
  
• Added LuaGuiElement::switch_state, allow_none_state, left_label_caption, left_label_tooltip, right_label_caption, right_label_tooltip read/write.
  
• Added LuaStyle::badge_font, badge_horizontal_spacing, default_badge_font_color, selected_badge_font_color, disabled_badge_font_color, selected_font_color, selected_hovered_font_color, selected_clicked_font_color, strikethrough_color read/write.
  
• Added clear_and_focus_on_right_click to LuaGuiElement text-box.
  
• Added LuaGuiElement::get_slider_value_step(), get_slider_discrete_slider(), get_slider_discrete_values(), set_slider_value_step(), set_slider_discrete_slider(), set_slider_discrete_values().
  
• Added LuaGuiElement::get_mod().
  
• Added LuaEntity::loader_container read.
  
• Added LuaEntity::belt_neighbours read.

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

Read this post on our website.

Hello,
We are down to 28 bugs on the forum. The last bugs are often the ones we have been putting off for a reason, they generally require some more meaningful changes and decisions. That is why this week we have a lot to discuss.

G2A got back to us this Monday, nothing much has happened so I will keep it short. They asked if we would agree to an audit to verify the money lost to chargebacks, we said yes, and they said they will start contacting some audit companies, and that it will 'take some time'.

Kovarex was convinced by members of the forum to add someway to use the obstacle avoidance mode of the rail planner. Now when planning a rail path, holding CTRL will make it use the obstacle avoidance ghost planning.

Dear server owners: the server description field is being enlarged from 120 to 5000 characters, and it now loads immediately. As soon as the next release is out, you may stop abusing the "tags" field for your colorful descriptions.

We decided to change the Basic oil processing recipe so that now it only outputs petroleum gas.

Normally this recipe change would mean all 3 outputs would be petroleum gas, but we added a new feature so that a recipe can specify a specific fluidbox to use. We also used the same system so the future water input (for advanced oil processing) is closed.



We believe this contributes to make oil a bit less of a difficulty spike, and also means we no longer need to remember which side the water goes in.

This means that light and heavy oil is only available after Advanced oil processing is researched. The biggest issue this introduces is that worker robots require lubricant made from heavy oil.


Click to see more technologies.

The solution we chose to apply is to move worker robots behind chemical science pack. This change does delay how quickly you are able to get worker robots, but the difference should not be too drastic as in order to get robots operational you already need to set up a complete refinery, advanced circuits and 2 upgrades of engines - which is already most of the science pack done.

Basic oil processing now produces 25% more petroleum gas to offset the loss of light and heavy oil for solid fuel.

Technologies which newly received chemical science pack now require less science packs to research them so the total resource price is not too far off either.

We prefer to keep flamethrower as it is, but flamethrower ammo now requires petroleum gas instead of light and heavy oil.

For a long time we have felt that there aren’t really enough useful technologies unlocked by chemical science, and laser turrets are a big game changer so we’re moving those to chemical science pack along with the worker robots.



There was a bug with laser turrets, the shooting speed upgrade didn't actually increase their firing rate since we switched them to use beams. Posila fixed it, so that more turret shooting speed actually results in more damage per second, not just for laser turrets but for personal laser defense too.



Now that the shooting speed bonus works properly, we decreased the base shooting speed of the laser turret and personal laser defense by 50%, and with all the upgrades the shooting speed will be 160% of what it used to be.

Another result of this bugfix, we decided to change the initial damage of the personal laser defense from 40 to 30. However with full shooting speed technologies the DPS is much higher (at the cost of more energy).

After fixing that laser beams didn't glow in dark, OwnlyMe releases a "Glowing Laser beams" mod that makes laser beams illuminate ground under them. Vaclav requested this to be base game feature, but there was a catch: Beam graphics didn't tile properly.



We were aware of issues with tiling of beam graphics ever since we added laser beams, but Vaclav was able to workaround the problem by decreasing intensity of a glow on sprite edged and make the overlapping almost invisible. Almost.

Vaclav tried to workaround the tiling problem by adjusting edges of sprites again, but it quickly turned out it was not possible to do.

After going through code that draws beams I realized that we calculate the exact position of each beam tile, but then pass it to drawing functions which convert the position to MapPosition, which uses fixed-point coordinates with only 8 bits for fractional part. Because of this, the tiles didn't align properly and they sometimes created a gap or overlapped. To cover gaps, the sprites were drawn scaled up by 1%, which resulted in them overlapping even more. Originally, when electric beam was made back in 2015, this did not create any visible issues.

So fixing the accidental rounding of rendering position was easy, and the body of the beam started to tile properly, but there were still visible seams at the head and tail of the beam. I was reading up on how triangle rasterization works on GPUs, so I figured that it must be due to head and tail sprites having different sizes than body sprites, so they don't share an edge exactly, which causes some pixels on the edge to be rasterized by both quads and some by neither quads. After spending some time on fixing this problem I found out that the problem was not in rasterization of edges, it was caused by texture filtering.

The head and tile sprites that I was using to test the issues were larger than they should have been, and were overlapping the body sprites. Lights are almost always gradients spanning over large area and are rendered using bilinear filtering. So the edge of body tile was aliased because that's where quad ended, but edge of head sprite was bilinearly filtered, because that's where the edge was drawn in the sprite, not the actual edge of the sprite quad. So I changed how the head and tail sprites are drawn, in order for them to always share an edge with body sprites, and that fixed the issue. As a bonus, we were able to turn on trilinear filtering on beam sprites, we didn't use it on them before because it used to make tiling issues even worse.



Now the beams and the glow are as close to pixel perfect as we can get them. The glow really does make the scenes look that much nicer.



I did some improvements to Inserters during some releases of 0.17. I made them faster by removing what I thought were pointless pauses where the Inserter would do nothing for 1 tick in some situations. But after 0.17.50, this started happening:



In some specific situation, the Inserter would aim for an item coming towards it, but because the item was too fast, it would overshoot the inserter head. If this is timed in a certain way, it would happen indefinitely. Before 0.17.50 this didn't happen because the Inserter would pause for 1 tick after failing to pick up an item, breaking any timing loops, but it also meant that an Inserter would potentially wait up to 10 ticks during one swing (since the Inserter tracks items on moving belts throughout it's entire movement).

So I didn't want to revert back to the previous logic. Many more complex solutions were not very feasible either since Belt<->Inserter interaction is a performance critical part of Factorio. So the final solution was to pause for 1 tick after failing to pick up an item, but only if the Inserter head is on top of a belt. This is should be the best compromise all things considered.

We plan to do a release on Monday, so you will have a chance this weekend to share your thoughts regarding any of these changes over on our forum.

• Restored ore placement to match that of 0.17.50 more
  

• Optimized synchronization time of blueprint library to a new game map. more
  

• Fixed glitch in pollution cloud overlay rendering. more
  
• Fixed joining multiplayer through Steam Friends would not work sometimes. more
  
• Fixed rail signal consistency for a very special corner case. more
  
• Fixed that the Linux server's standard input could get closed under some circumstances. more
  
• Fixed crash when enabling blueprint library cloud sync when local blueprint library did not exist. more
  
• Fixed that trains couldn't be rotated while in the map editor. more
  
• Fixed that LuaGameScript::ban_player() only worked with real players. more
  
• Fixed that the changelog GUI could have unnecessary scroll bars. more
  
• Fixed that hiding the search bar didn't unfocus it, so it was still possible to write to the invisible search bar. more
  
• Fixed wrong signal placeability in some specific cases. more
  
• Fixed that the entity tooltip would flicker in some cases related to the tooltip delay. more
  
• Fixed a crash when opening assembling machines with fixed_recipe set in the latency state. more
  

• Added a prototype property for hiding recipes from the player crafting GUI.
  
• Renamed spot noise argument 'minimum_candidate_point_spacing' to 'suggested_minimum_candidate_point_spacing'
  
• Added base_productivity to assembling machines, mining drill, and lab prototypes.
  
• Added LuaEntityPrototype::base_productivity read.
  

• Added optional "ignore_characters" to LuaSurface::clear().
  
• Added on_gui_confirmed event.
  
• Added LuaGuiElement::numeric, allow_decimal, allow_negative, is_password, lose_focus_on_confirm, clear_and_focus_on_right_click read/write.
  

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

Read this post on our website.

We have a record low in our bug report forum, of only 55 active bug reports. I don't think in the history of Factorio the bug forum has been so clean. No doubt once we mark 0.17 as stable the count will shoot up again.

For this weeks graph I added the count of players on Steam as the left axis. We thought it would be somewhat interesting to see if there is any correlation between the two.


Note: The axis have different scales.

I also prepared the same graph but for the duration of the 0.17 release. You can see our player numbers are dropping quite a lot, from the all time peak of 22,457 on the 3rd of March 2019.



While bug reports might be at an all time low, we are not going to call the game stable yet. We still have an important milestone to reach, that is, implementing the new Introduction campaign graphics (FFF-301). A lot of the team has been on vacation these last few weeks, including the whole campaign team and most of the art department. What this means is that we expect it will be a few more weeks before we can call the current version stable.

We have been asked a few times when stable will be released, but my question is, why does it matter exactly which version we call stable? Are you waiting for stable to play a new playthrough? The thing is, this stable is only going to be the 'first' stable. Our plan is to have a number of short experimental phases after the first stable, where we will add new GUI's and such, which will add bugs and technical debt. After fixing the bugs in a 'small' experimental content release, we will then mark that as the 'new' 0.17 stable.

Besides, there are still a few edge cases with signals that kovarex is busy fixing:



For instance the setup above took him 3 hours to fix. The cause of the issue was that the segment has both an incoming and outgoing signal at the same position.

There was recently some news about G2A, prompted by a tweet by Mike Rose of No More Robots. In a follow up tweet he said: Please, if you’re going to buy a game from G2A, just pirate it instead! Genuinely!.

We have talked about the grey market resellers in some previous Friday Facts (FFF-145 and FFF-171), and our stance is pretty much the same as Mike, we would rather you pirate Factorio.

Upon hearing the news of G2A advertising Descenders, we took a look ourselves, and we discovered they were doing the same with Factorio:



Obviously we aren't super happy about it, but after looking into some trademark/copyright law, it seems there is not much we can do.

After the news broke, G2A posted an article on their website: {LINK REMOVED}G2A vows to pay devs 10x the money proven to be lost on chargebacks. After reading it through, I thought I would take them up on their offer.

We had a ton of chargeback and fraud issues in 2016 just after our Steam launch, with over 300 Steam keys of the game being purchased with stolen credit cards. With an average chargeback fee of about $20, we estimate the total amount of fees we paid because of chargebacks is about $6,600. We will be doing a deeper evaluation of our historic accounting records to get a more exact figure, but it doesn't matter so much now.

So I emailed G2A about the article and their 'vow' last week, and they are not exactly prompt in terms of dealing with the request. I have a list of all the Steam keys I had to revoke because they were purchased fraudulently, and G2A offered to check the keys. Currently this is where the story ends, they haven't replied to my last email (2 days ago) sending them the keys and asking how many of them were sold on the website.

Funnily, we already know that at least some of the keys were sold on G2A, because after I revoked them, I had people emailing to ask what was wrong with their key:

• Hello, on 2016-12-26 I bought my brother a Factorio steam cd key from G2A website. On 2017-01-20 he got a message on steam that the game was revoked. What happened and how can we solve this issue?
• Hey, I got this game from my friend on my birthday a while back, March 11thish. He sent me it by key, I didn’t really question it. Yesterday, though, I was greeted by a popup telling me the game had been removed. After investigating, I learned my friend bought it from a site called G2A, little shady site from what I hear. Steam support says it was “revoked at the request of the publisher.”
• I bought Factorio on G2A last week for Steam. However, I can't find it in my Steam library anymore.
• On 3 March I bought the game Factorio on G2a It was 5 euro cheaper than on your website so I thought let's buy it here. But today I got a pop-up from steam saying that my Factorio steamkey has been revoked because of a problem with processing payment for this item.
• Today i logged in, after playing this game rougly 300 hours and about 2 month and got a message that Factorio was removed from my account. I got my key from G2A.
• I bought Factorio on steam a while back and when i went to play it, it said i had to purchase it. I contacted steam and they said that it had been revoked and i should contact the publisher. How and will i get the game back? I bought the game off of G2A.
• I bought the game on g2a and got the steam product code and my account is saying that I don't have the game bought.

Well anyway, after we switched payment providers to Humble Widget, the fraudulent purchases stopped. We don't really care about G2A anymore (but we are in a unique position due to our no sales policy).

There are still Steam gifts of Factorio being sold on G2A, these are most likely 'legit', in that they were not purchased using stolen credit cards. The question is, where do these gifts come from? Obviously people would not be selling Factorio Steam gifts if it did not generate a profit. We have some ideas:

• Regional fraud - Buying the game in 1 country and gifting it to someone in another. This is likely, as we can see that the Europe gift is cheaper than the US/Worldwide.
  
  
• Speculative buyers from before the price increase - The price of the game was $20 a year ago. So buying 1,000 copies and waiting 1 year, nets you a profit of $5,000 if you sell for $25. Not a bad gain in a year. For Factorio the opportunity only came once, but other games go on sale multiple times each year, which is where the speculative buyers and the grey market cash-in.

To conclude this whole topic, we strongly recommend people buy from us or one of our official partners. Not only for the reasons you might think. If you buy from a grey-market site and have a problem with the game, or something goes wrong, you will have to deal with their support system. I don't have the exact details of how to request a refund or customer support from G2A, or how long they will take to respond to your issue.

If you buy from us directly, we offer a 28-day refund policy. If you have a problem with the game, you decide it's not your cup of tea, you thought the biters were too cute, just send us an email and you will have a refund in short order. We also deal only with Factorio related support problems, we don't process orders of thousands of different games, so you can be sure your case will be handled expediently by team members who know the game in and out.

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

• Added option to enable Steam Cloud Sync for blueprint library to Other Settings GUI. Please backup your blueprint-storage.dat if you chose to enable it. The option is available in Steam version of the game and Cloud Sync needs to be enabled in Steam for the library to be actually synchronized.

• Fixed that the blueprint library GUI sometimes wouldn't update until the mouse was moved. more
  
• Fixed that deconstructing tiles in the map editors instant-deconstruction mode didn't work. more
  
• Fixed setting FireFlamePrototype::spread_delay_deviation to 0 or 1 would crash the game. more
  
• Fixed logistics system tutorial after game script migration. more
  
• Fixed that the game would freeze when using LuaLogisticNetwork::remove_item() if the item was only in the players cursor. more
  
• Fixed yet another case of rails not merging blocks as expected. more
  
• Fixed occasional crash when dragging train wait conditions with brackets. more
  
• Removed the focusability of buttons, as we don't support it graphically and the functionality was just half-functional. more
  
• Fixed that copy-paste for assembling machines would ignore fixed_recipe. more
  
• Fixed that failing to join multiplayer games through --join-game-by-id would fail to show the error and show an empty background. more
  
• Fixed inserting items into underground belts with inserters could put items onto the belt leading into the underground belt. more
  
• Fixed rail signal internal consistency for some cases of rail cycle with one signal. more
  
• Fixed that electric energy interface stopped accumulators from working. more
  
• Fixed high CRC time related to large amounts of electric networks in multiplayer games. more
  
• Fixed that multiple map settings prototypes could be defined.

• Removed label style want_ellipsis as it will be used automatically everywhere as with button.
  
• All rail bounding boxes are now hardcoded/not moddable. This is to avoid unexpected collision/rail block merging behaviour.

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

• Fixed that some of the textboxes didn't allow to write characters bound for different actions when focused. more
  
• Fixed a desync related to removing rail signal that merges two rail blocks reserved by different trains into one.
  
• Fixed that the belt-gap-fill logic could replace splitters/underground belts in some cases. more
  

• Added LuaPlayer::connect_to_server().
  

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

Read this post on our website.


Last month I joined KatherineOfSky's MMO event as a player. I noticed that after we reached a certain number of players, every few minutes a bunch of them got dropped. Luckily for you (but unluckily for me), I was one of the players who got disconnected every, single. time, even though I had a decent connection. So I took the matter personally and started looking into the problem. After 3 weeks of debugging, testing and fixing, the issue is finally fixed, but the journey there was not that easy.

Multiplayer issues are very hard to track down. Usually they only happen under very specific network conditions, in very specific game conditions (in this case having more than 200 players). Even when you can reproduce the issue it's impossible to properly debug, since placing a breakpoint stops the game, messes up the timers and usually times out the connection. But through some perseverance and thanks to an awesome tool called clumsy, I managed to figure out what was happening.

The short version is: Because of a bug and an incomplete implementation of the latency state simulation, a client would sometimes end up in a situation where it would send a network package of about 400 entity selection input actions in one tick (what we called 'the megapacket'). The server then not only has to correctly receive those input actions but also send them to everyone else. That quickly becomes a problem when you have 200 clients. It quickly saturates the server upload, causes packet loss and causes a cascade of re-requested packets. Delayed input actions then cause more clients to send megapackets, cascading even further. The lucky clients manage to recover, the others end up being dropped.

The issue was quite fundamental and took 2 weeks to fix. It's quite technical so I'll explain in juicy technical details below. But what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.

The basic way that our multiplayer works is that all clients simulate the game state and they only receive and send the player input (called Input Actions). The server's main responsibility is proxying Input Actions and making sure all clients execute the same actions in the same tick. More details in FFF-149

Since the server needs to arbitrate when actions are executed, a player action moves something like this: Player action -> Game Client -> Network -> Server -> Network-> Game client. This means every player action is only executed once it makes a round trip though the network. This would make the game feel really laggy, that's why latency hiding was a mechanism added in the game almost since the introduction of multiplayer. Latency hiding works by simulating the player input, without considering the actions of other players and without considering the server's arbitrage.

In Factorio we have the Game State, this is the full state of the map, player, entitites, everything. It's simulated deterministically on all clients based on the actions received from the server. This is sacred and if it's ever different from the server or any other client, a desync occurs.



On top of the Game State we have the Latency State. This contains a small subset of the main state. Latency State is not sacred and it just represents how we think the game state will look like in the future based on the Input Actions the player performed.

To do that, we keep a copy of the Input Actions we make, in a latency queue.



So in the end the process, on the client side, looks something like this:

• Apply all the Input Actions of all players to the Game State, as received from the server.
• Delete all the Input Actions from the latency queue that were applied to the Game State, according to the server.
• Delete the Latency State and reset it to look the same as Game State.
• Apply all the actions in the latency queue to the Latency State.
• Render the game to the player, based on the information from the Game State and Latency State.

This is repeated every tick.

Getting complicated? Hold on to your pants. To account for the unreliable nature of internet connections, we have two mechanisms:

• Skipped ticks: When the server decides what Input Actions will be executed in what game tick, if it does not have the Input Actions of a certain player (e.g. because of a lag spike), it will not wait, but instead tell that client "I did not include your Input Actions, I will try to include them in the next tick". This is so when a client has connection problems (or computer problems), they will not slow down the map update for everyone. Note that Input Actions are never ignored, they are only delayed.
• Roundtrip Latency: The server tries to guess what's the roundtrip delay between the client and the server, for each client. Every 5 seconds it will negotiate a new latency with the client, if necessary, based on how the connection behaved in the past and the roundtrip latency will be increased and decreased accordingly.

By themselves they are pretty straightforward, but when they happen together (which is common when experiencing connection issues), the code logic starts becoming unwieldy, with a large amount of edge cases. Furthermore, the server and the latency queue need to properly inject a special Input Action called StopMovementInTheNextTick when the above mechanisms come into play. This prevents your character from running by himself (e.g. in front of a train) while experiencing connection problems.

Now it's time to explain how our entity selection works. One of the Input Action types we send is entity selection change, which tells everyone what entity each player has their mouse over. As you can imagine this is by far the most common input action sent by the clients, so it was optimized to use as little space as possible, to save bandwidth. The way this was done is that each entity selection, instead of saving absolute, high precision map coordinates, it saves a low precision relative offset to the previous selection. This works well, since a selection is usually very close to the previous selection. This creates 2 important requirements: Input Actions can never be skipped and the need to be executed in the correct order. These requirements are met for the Game State. But, since the purpose of the Latency state is to "look good enough" for the player, these requirements were not met. The Latency State didn't account for many edge cases related to tick skipping and roundtrip latency changing.

So you can probably see where this is going. Finally the issue of the megapacket started to show. The final problem was that the entity selection logic relied on the Latency State to decide if it should send a selection changed action, but the Latency State was sometimes not holding correct information. So, the megapacket got generated something like this:

• Player has connection issues.
• Skipped ticks and Roundtrip Latency adjustment mechanisms start to kick in.
• Latency state queue doesn't account for these mechanisms. This leads to some action being deleted prematurely or executed in the wrong order, leading to an incorrect Latency State.
• Player recovers from his connection issue and simulates up to 400 ticks in order to catch up to the server again.
• For every tick, a new entity selection change action is generated and prepared to be sent to the server.
• Client sends the server a megapacket with 400+ entity selection changes (and other actions also. Shooting state, walking state, etc also suffered from this problem).
• Server receives 400 input actions. Since it's not allowed to skip any input action, it tells all clients to execute those actions and sends them over the network.

Ironically, the mechanism that was supposed to save some network bandwidth ended up creating massive network packets.

In this end this was solved by fixing all the edge cases of updating and maintaining the latency queue. While this took quite some time, in the end it was probably worth doing a proper fix instead of some quick hacks.

Clusterio is a scenario/server system that adds communication of game data between different servers. For instance sending items between different servers, so you can have a 'mining server', which will mine all the iron ore you need, and send it to the 'smelter server' which will smelt it all and pass it further along.

Last year there was an event using the system which linked over 30 servers together to reach a combined goal of 60,000 Science per minute. MangledPork has a video of the start of last years event on YouTube.

The great minds and communities behind the last event have come together again to host another Clusterio event: The Gridlock Cluster. The goal this time is to push the limits even further, explore and colonise new nodes as they are generated, and enjoy the challenge of building a mega-factory across multiple servers.

If you are interested in participating in this community event, all the details are listed in the Reddit post, and you can join the Gridlock Cluster Discord server.

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

• Removed the message of "<X> is in the way" when building over the exact same entity with same direction and position as in cursor. more
  
• Rails under trains can be marked for deconstruction. more
  
• Better latency hiding in multiplayer when experiencing connection issues. Less issues with rubber-banding or character teleporting.
  
• Latency hiding is no longer completely disabled when the character is shooting. Character position and animation are still not latency-hidden while the character is in combat (10 seconds after shooting or taking damage). This should make combat smoother in multiplayer.
  
• The Linux version of the game now depends on PulseAudio.

• Fixed adding conditions to a train station after it was dragged. more
  
• Improved drawing of a wall preview in some special cases. more
  
• Fixed that the sync-mods-with-save could in some cases leave mods enabled. more
  
• Added Right Control as secondary binding for "Temporary station modifier" controls. more
  
• Fixed that migrating saves could in some cases mess up damage bonuses. more
  
• Added a migration for unloadable saves because of invalid train paths caused by bugs in previous versions. more
  
• Fixed that rails wouldn't build correctly if they had a fast_replaceable_group defined. more
  
• Fixed flamethrower turret tooltip was missing info about created fire. more
  
• Fixed that modded units with minimal attack range wouldn't try to get away from a target if they were too close. more
  
• Fixed that train built from blueprint could miss a connection occasionally due the rail building order. more
  
• Fixed that electric-energy-interface and heat-interface entity types didn't export properly in blueprint string format. more
  
• Fixed Compilatron speech bubble hologram effect would cause entire screen to flicker when "Full color depth" graphics option was disabled. more
  
• Fixed a map corruption issue related to building blueprints outside of the map through script. more
  
• Fixed that too long description of shortcut tool could make the selection frame to be too big and unclosable. more
  
• Fixed that undo doesn't work for trains. more
  
• Fixed that reading 'disabled' from train stop control behaviors from Lua would report bad values in some cases. more
  
• Fixed that rich text tooltips would flicker in multiplayer. more
  
• Fixed possible crash in NPE when Compilatron builds an iron mining setup. more
  
• Fixed multiplayer issue where a client and server would sometimes send a large amount of data, causing players with slower connection to disconnect (https://factorio.com/blog/post/fff-302)
  
• Fixed that the wind sound would cut off abruptly when the technology screen was opened. more
  
• Fixed that inserter tooltips would list pollution despite inserters being unable to produce pollution. more
  
  
• Fixed that the bar of train wagon in blueprint was lost when the game was saved and loaded. more
  
• Fixed that textfield selection wasn't removed when the focus was lost. more

• Equipment with the "manual" shape now renders backgrounds/outlines automatically like equipment with the "full" shape.

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