Aug 2, 2019

Factorio - Klonan

Read this post on our website.

Warning this Friday facts is about the Introduction scenario, not about anything that will be in Freeplay Factorio. You may want to read previous FFFs (FFF-257, FFF-284) about the Introduction.

TLDR: the Stable candidate of the Introduction scenario is now in Experimental please play it and send me your screenshots. Feedback especially on the “freeform endgame” would be greatly appreciated. We have also released a Experimental version of the Demo, be sure to send this link to your friends ASAP

SPOILER WARNING: If you have not yet played the Introduction Scenario, go play it before you read this.

Introduction scenario as Tutorial

The tutorial components of the Introduction are working very well now. There is still more polish to do, but I feel confident it is ready for new players of all kinds.

Introduction scenario as Demo

The rest of this article will discuss the Introduction, but from the point of view of a player who has not payed for the game yet. Once 0.17 Stable comes out, the Free Demo will be replaced with just the Introduction Scenario.

What we wanted from a new version of the Demo

The old demo has a very limited amount of content, and only about 2 hours of playtime. The content it does present is very dated, and hardly could be called representative of contemporary Freeplay Factorio, it did not even include Research!

We had some design constraints for the new demo, some of which were:

The player can fail during the demo
Difficulty is respectful, Fake danger is disrespectful

Whatever happened, we hoped that the new demo would demonstrate a wider range of Factorios concepts, including a small taste of deathworld difficulty. I would say we were too successful.

We decided to do this with a final quest where the player has to quickly complete a long research while the biter attacks increase in strength. The player needs to be completely attentive, otherwise their defense will fall over.

An invisible, dynamic difficulty curve meant that everyone was challenged to the breaking point, veterans and new players alike. See FFF-284. For the goal of being a challenge, I would say it was working well.

What other people were thinking

People loved it or hated it. I received many elated emails saying how intense the final battle was and how sweet the victory felt. I also received pseudo-hatemail about 1,000 hour players rage quitting.

The reason a lot of vets were failing was because they were pretending to be new players. This generally meant playing as a vet (using shortcut keys, and high APM, heavy pollution) but placing few turrets, generally in sub-optimal locations, and being lazy with ammunition delivery.

Newer players felt pressured and were generally able to pull off a close victory. Many said they were overrun at the end, but still were victorious, giving an interesting moment to leave the game and start freeplay with a high heartrate.

Feedback was far more positive than negative, but from the negative feedback there were two recurring themes.

The most common negative feedback was that such intense combat is not representative of Factorio.
The second most common feedback was that the player did not expect such a difficulty in a 'tutorial' level.

Failed Solution 1: Sending less biters

This removes the chance that the player can lose, but introduces new problems with the design. It removes ammunition as a production pressure, and makes Turret placement irrelevant.

Failed Solution 2: Ramp up the attacks slower

This sounds like it could work and for the second problem listed above, it does. The player has more time to react. However this means that only new players experience the challenge, as they most likely have built the fewest Labs, and take the longest to finish the quest. Vets will finish before the attacks built up to any meaningful level. Just making it easier for the players who are able to overcome the challenge the most seems odd.

Failed Solution 3: Add more time between waves

In order to have a decent number of biters so the production challenge is not lost, the waves need to be very large. For the player to have enough notice between waves, there is a chance they will be able to finish the research before the first one comes. Also the most common failure state was when a Turret with 200 rounds is destroyed, meaning the player cannot craft enough new ammo to keep up with the waves. This happens more often with bigger, less frequent waves.

All three of these solutions have one thing in common: we would need to implement them in a way that removed the challenge almost completely. So I suggested an alternative solution.

New Solution: Remove the Challenge quest completely

Now there is no timed research and defence quest at the end of the Introduction. Instead the player is told to destroy Biter spawners to reduce the attack frequency, and then they are left to deal with Freeplay style attacks. The structure of the final quest is similar to Freeplay itself "Research a technology at the bottom of the tech tree". The player now needs to automate Logistic Science packs to win the Introduction.

If the player cannot survive here, they will not survive a Freeplay game, but realistically the biter challenge in Default settings Freeplay is not particularly worrisome.

Other new Demo goodies

Having a great Demo is important to us. We don’t want someone to pay for the game, just to see if they like it. It is also fits well with our no sales policy. We already offer an extended refund period to players who buy on our website, if they gave the game a red-hot go but discovered it was not for them.

Demos are in general a super cool thing from the 90’s that most people here wish still existed.

So we will increase the amount of content in the demo. You can continue playing at the end of the Introduction, and I suspect there is about 10 hours of stuff to do. We are also adding more recipes and technologies to the Demo.

The new list of what is available:

A complete and unique demo techtree that uses Automation and Logistics science packs, Mining Productivity infinite tech, Shooting speed infinite tech, Grenades, Steel, Piercing rounds, Car, Medium power poles, Heavy armor, Submachine gun, Assembling machine 2, Turrets, Lamps, Long handed inserters, Gates, Walls, and more to discover.

The size of the final play area is also much larger.

Click to view full size

We have released the changes today, and also released an experimental version of the demo. Please let us know if you have any feedback or suggestions in the usual places.

Jul 26, 2019

Friday Facts #305 - The Oil Changes

Factorio - Klonan

Read this post on our website.

Lua Mod GUI additions

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.

The Oil Changes

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.

Basic oil processing changes

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

The use of Light oil

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.

Rocket fuel behind chemical science pack, requires light oil

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.

Chemical science pack change - Sulfur

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.

Robots behind chemical science pack

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.

Flamethrower ammo change - Crude oil

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.

Adjusting the numbers

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.

Jul 25, 2019

Version 0.17.59 released

Factorio - posila87

Balancing

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

Changes

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

Bugfixes

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

Modding

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

Scripting

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.

Jul 19, 2019

Friday Facts #304 - Small bugs; Big changes

Factorio - Klonan

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 update

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

Rail-planner obstacle avoidance

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.

MP server description

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.

Oil processing changes

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.

Laser turret moved to chemical science

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.

Laser turret shooting speed fixed

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

Laser beam glow

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.

Inserters getting stuck

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.

Jul 12, 2019

Friday Facts #303 - Under 100 bugs (but still not stable)

Factorio - Klonan

Read this post on our website.

Under 100 bugs

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.

G2A - Worse than Piracy

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