Factorio News

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 BeltInserter 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: 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.