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

Read this post on our website

For many weeks now the GFX department has been focused on preparing replacements for the placeholder graphics of the campaign crash site. The subject as usual is not that easy because we had to first solve the main concept of the crash site.

It happens that those new entities belong to the Factorio universe, but they come from a different reality than the usual DIY/diesel punk of the game. So we had to invent a new way to design machines that look like Factorio but that are not too familiar.

Here a proof of concept of the look:



The concept is that the big (medium) spaceship broke into pieces as it crash landed, and lost many components that the player, during the introduction, will repair and use for his own profit.

The look of the spaceship remnants are a little bit based on the designs of the 60’s/70’s pulp Sci-Fi. Fortunately we can keep the look of Factorio due the accident, which allows us to destroy and dirty up the machines show many inner mechanical details.

It is also part of the concept that all the machines that the player builds, are based on an existing technology from his home planet. So the machines that we see in the regular game are like 'cheap' versions of the original ones.



For the lab, we keep the dome shape and the beams inside in order to keep consistency with the regular laboratory. So slowly the player gets used to the meaning of the shapes.



The generator is similar to a substation -more or less-, connectable like a pole but it also produces electricity. Sometimes we really have to invent.



This works like an assembling machine. The design is more based in the (yet unshown) redesign of the assembling machines, rather than on the actual 'classic' ones.



These cylinders are like chests. We decided to make them cylindrical instead of a box for this difference in technology level that we are speaking about. The player will recognize them for the shape, color, and they also always have a number printed. You don’t really want to know the meaning of the numbers.

All this new content is a work in progress, and we made these new entities first for the testing of the campaign. Based on feedback with testers we will have the chance to tweak and adapt whatever is necessary. In the case of the introduction, the positioning of the entities can have a large impact on the flow of the gameplay. Once we are more sure of the final placement, we can see how all the pieces will fit together.

The next round for the crash site is the main crashed spaceship, and some other assets that converts the scene into a full composition, more proper for the introduction of the game.

I've heard it many times and said it myself: "It's only ..., there aren't a lot of them in the base game so it should be fine." And then mods come along and bring a slap of reality: if a mod *can* do something a mod *will* do something.

The other week I got a bug report that the game was using a large amount of memory and took an excessive amount of time to exit. After reading over the bug report I had my theories as to why it might be happening but first I needed to reproduce it. A few failed attempts later I got the correct set of mods and mod settings to make it happen. To my surprise (well not really - it happens almost every time with these things now) - it wasn't what I thought it was going to be.

Sprites.
Not the video-texture kind but the internal wrapper class we use to store information about the video-texture. The game was creating an insane amount of them due to what the mod was doing. Specifically: the mod was making a lot of variations of each biter, spitter, worm, biter nest, and spitter nest. Normally that's not a problem - the game can do that easily. The problem came from how worms work. Worms have multiple directions with multiple animations for each direction. The end result is each base game worm creates 7668 sprites. ... "It's only 7668 sprites per worm, there aren't a lot of them in the base game so it should be fine." The base game has 4 worms: small, medium, large, behemoth. This mod was asking the game to make 3020.

The base game:

• 188'056 sprites on the main menu
• 1.281 seconds from launch to the main menu
• 245 MB idling on the main menu
• 0.1 seconds to exit

The mods:

• 41'071'478 sprites on the main menu
• 47.395 seconds from launch to the main menu
• 15'791 MB idling on the main menu
• 47.5 seconds to exit

Many ideas and attempts later (plus fixing all the broken stuff introduced by those changes with the assistance of Oxyd) I had reduced the time complexity of making and destroying the sprites by a significant amount and found that some just weren't needed.

The result:

• 23'681'677 sprites on the main menu
• 37.444 seconds from launch to the main menu
• 5'484 MB idling on the main menu
• 2.9 seconds to exit

A significant improvement on every measurement. I always love working on these kinds of problems because they almost always involve a lot of thinking and experiments.

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

• Fixed a crash related to equipment rendering.
  
• Fixed a crash related to tile building. more

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