• The production statistics and electric network GUIs now have a new look.
  
• The kills GUI (K keyboard shortcut) has been removed. Kills statistics are now accessible as a tab in the production statistics GUI.
  

• Fixed an issue with nested items in items. more
  
• Fixed Character GUI missing logistics tab due to missing technology migration. more
  
• Fixed Character GUI recipes constantly scrolling up when crafting or when inventory changes. more
  
• Fixed that simple mouse click on double slider button would not set a slider as active. more
  
• Fixed that tabbing out of empty high value textfield of double slider would reset it to 0. more
  

• Removed the defines.gui_type.kills value from defines.gui_type.
  

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

• The character GUI now has a new look.
  
• Personal logistics has been moved to a separate tab. Logistic requests and auto trash have been merged into one panel.
  
• Using quick inventory transfers in the player inventory of the character gui will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.
  
• Updated the look of filter, item and circuit signal selection GUIs.
  

• Personal logistics are now unlocked by a single research. This unlocks personal logistic requests and auto trash(unlimited count), plus 30 character trash slots.
  
• Removed the restriction of not allowing to have two identical blueprints in the blueprint library or blueprint book.
  
• Allowed to delete blueprint/books/upgrade planners/deconstruction planners also when opened in other inventory.
  
• Removed the utility slots (to create blueprint, book etc) from blueprint library as it is now available directly through quick tools menu.
  
• Allowed to edit blueprints in the blueprint library the same way as when it is an item.
  
• Allowed to export blueprint books in blueprint library (it was only possible in inventory before).
  
• Allowed to choose whether train fuel should be included in a blueprint.
  

• Fixed that 3rd last row of 4th sheet of gun turret shooting had duplicate frame. more
  
• Fixed desync when changing recipe that was outputting large amount of fluid per crafting cycle to recipe that outputs low amount of fluid. more
  
• Fixed sprite button would not respect draw_shadow_under_picture style property. more
  

• Added main_menu_background_image_location to utility constants.
  

• Removed LuaStyle::extra_padding_when_activated read/write.
  
• Added LuaStyle::extra_top_padding_when_activated, extra_bottom_padding_when_activated, extra_left_padding_when_activated and extra_right_padding_when_activated read/write.
  

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

Read this post on our website.

It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots.
​
The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.

https://cdn.factorio.com/assets/img/blog/fff-338-tabs.mp4

Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request.

https://cdn.factorio.com/assets/img/blog/fff-338-setting-filters.mp4

With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science.

Searching now not only searches the recipe GUI, but also the inventory and logistic requests.

https://cdn.factorio.com/assets/img/blog/fff-338-search.mp4

By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots.

https://cdn.factorio.com/assets/img/blog/fff-338-toggle.mp4

Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released.

Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be <s>focusing</s> obsessing that much on the GUI in the future. We will finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0.

This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.

Over the past two weeks, an overhaul mod called Krastorio 2 has been going through closed alpha and beta testing. Krastorio 2 is an overhaul mod that aims to provide a vanilla-style experience with an expanded post-rocket game and updated recipes. The mod will be released later today, so I wanted to take the opportunity to spotlight it.


My factory, grown over the two weeks of testing, showing off the custom mod graphics.
Click to view full resolution

The mod changes almost all recipes without introducing many intermediates, making it close to vanilla while still being a new experience. One of the bigger changes is that late-game technologies do not require the starting tech cards (science packs). Combined with the tech cards mostly needing intermediate products, you can reroute the ingredients of the tech cards into other production as the tech cards become obsolete.


Post-rocket tech cards are consumed in the lab area on the left in the image, the pre-rocket tech labs stand disused in the bottom right.

The biggest feature of Krastorio 2 is that it adds a significant amount of content beyond the rocket launch, including a new win condition. After automating rocket launches there are three more tech cards waiting to be researched, two new resources waiting to be harvested, and many more useful items to be crafted. All that production and the win condition take a significant amount of power but thankfully the mod adds an effective power generation option to fulfill the factory's needs.


Fusion power

All in all, the mod can be described as a great mix of updated recipes and fresh mechanics that are kept in line with vanilla. This means that the mod is not as overwhelming as overhauls that really focus on certain mechanics such as many additional resources, fluids or intermediates. Instead Krastorio 2 strikes a great balance between old and new. The mod has many more features that I did not mention here; so if I made you curious, check out the mod for yourself and have fun playing!

• Fixed player character shadow didn't animate in idle state when not facing north.
  

• Fixed that LuaEntity::splitter_filter would reject a LuaItemPrototype. more
  
• Fixed smart entity collision mode in tile editor did not work with offshore pump. more
  
• Fixed that modded shortcuts that spawned items not visible in the blueprint library didn't work. more
  
• Fixed that technology tooltips didn't show debug tooltip data the same as other tooltips. more
  
• Fixed that crafting machines would report as supporting backer names through the Lua API. more
  
• Fixed that un-researched recipes couldn't be used while in the map editor. more
  
• Fixed that the removed-content GUI didn't include some translations. more
  
• Fixed a desync related to invalid rail signal requested to be closed by circuit network. more
  

• Added InserterPrototype::chases_belt_items. more
  

• Added LuaEntityPrototype::inserter_chases_belt_items read.
  
• Added surface to the selected-area events.
  
• Changed LuaSurface::spill_item_stack() to return the created entities if any.
  

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

Read this post on our website.

The statistics GUI (electric network stats, production stats, etc.) is one of the GUIs that has been in the game for a very long time, and has had its functionality fleshed out reasonably over the years. It was not long ago when Twinsen added hovering and highlighting to the graphs.

Given that, and the relatively short timeframe for 1.0 release, the update of the statistics GUI has really just been a style update, no new features or heavy logic rewriting. Oxyd has most of the work done, so we are happy to show some real in-game screenshots of how it looks:



A notable change with the electric stats is that the Satisfaction/Production/Accumulator charge are next to each other in a single row, as opposed to each in a separate row. The label for the exact amount has also been moved to inside of the progress bar, which itself is much thicker.





The production stats are pretty much the same functionality wise. One new button you might spot is the search button.



However there are some problems with the search feature. As you can see, production and consumption frames have a different search box independent from each other. The main problem is when pressing CTRL+F to perform a regular search: How do we know which frame to open? Of course this could lead to different solutions like the use of a cycle for the focus of the search, in which the second time you press CTRL+F the other frame gets the focus. Or both of the search boxes open at the same time but only one gets the focus. Or only one frame gets the focus and the other one works only by pressing the button. But let's face it, these "solutions" are not solid at all and create inconsistency in the main design.

To solve this issue we decided that the simplest way to go is the use of just one search box on the header of the panel. This new location works as a general feature for the entire panel. One single search gives you 2 results, one on each frame. This solution is used in the new character window -to come soon- making it consistent with the whole design of the GUI.



You can also see we took this opportunity to integrate the Kill statistics in with the rest, instead of being its own window with its own hotkey.

The Statistics GUIs will need a few tweaks and polishings here and there before it is ready for release, but unless something unexpected happens you can expect it coming out in a release soon.

This topic is a guest post by our community member and mod maker justarandomgeek.

Historically, while developing Factorio mods, you just had to write some code and try it, until you get one of these:



Then you go back and find that spot in your code and try to figure out what went wrong. If the error is particularly confusing, you start sprinkling <tt>log()</tt> or <tt>game.print()</tt> around to try and figure out what the heck is going on. And, of course, when you find the problem, you inevitably forget to clean all of these up, and now you're spamming the log or chat forever.


Well there's your problem! Perhaps a bit constructed...

For the last few months I've been working on a debugger to improve this experience. The first step was to spend some time with the Lua debug library and VSCode's Debug Adapter Protocol making introductions to get them talking to each other. Factorio doesn't give me many options, but Lua's <tt>debug.debug()</tt> and <tt>print()</tt> functions are enough to interact with the (normally invisible) console.

VSCode can launch Factorio and attach itself to this console to inject commands as needed to read and manipulate the state of the running code. This gets us VSCode's debugger interface, with all the pre-built tools for displaying variables, setting breakpoints and stepping through code. Wrapping some of the game's APIs like <tt>remote.call()</tt> and most of <tt>script</tt> to add a little extra special handling, we get nice labels on event handlers in the call stack and a first version of break-on-exception for when things go wrong. I even built some nice detailed variable views for the most common LuaObjects:



But there's a catch, and it's a big one: because of the way Factorio sandboxes mods, the debugger (which is itself a mod, in part) can't actually get to your mod to install all these hooks! The first solution to this is to simply add a line to load the debugger, but this puts us right back where we started with <tt>log()</tt> - you put something in for debugging and forget to remove it.

To solve this problem we need a little help from the API, a way for a mod to hook every other mod. Unfortunately, this level of hooks is too powerful of a capability to be generally available to mods, so it can't really be added to the normal mod API (it allows you to fairly trivially break nearly all assumptions about data lifecycle and mod sandboxing). After some discussion with Rseding, we eventually arrived at Instrument Mode (released with 0.18.10), a special mode which allows a selected mod to hook all the Lua instances Factorio creates, at the cost of disabling multiplayer and only allowing one Instrument at once. This also provides a hook for a better version of break-on-exception.

This gets us all the way to the rich debugger experience: When you run under the debugger, all loaded mods automatically get debug hooks installed for the session (but not permanently), and you can step through the code and examine all your variables!

While I was building tools, I also added some highlighters for locale and changelog files, and validation for changelogs:





And of course, it's a game about automation, so we need some modding workflow automation too:



Modders, please give it a try and let me know what you think!

• New offshore pump graphics.
  

• Removed the sound effect from the console-only electric-energy-interface.
  
• Item localised name takes priority over place-result localised name when showing item's tooltip. more
  
• Offshore pump is now buildable on ground tile adjacent to water instead of water tile adjacent to ground.
  

• Fixed that the map generator GUI didn't reset to the correct defaults when changing presets. more
  
• Fixed blueprint window sizing for wide blueprints.
  
• Fixed some cases of not considering dark background icon when drawing alt mode overlay. more
  
• Fixed that burner generator idle_animation and animation could have different frame counts.
  
• Fixed icons with overlays were drawn incorrectly when used in sprite widget. more
  
• Fixed crash when loading map after removing fluid recipes with indexes. more
  
• Fixed spitters would not break from attacking an obstacle when the obstacle moved away. more
  

• Added Instrument Mode to support mod development tools.
  
• Added optional burner generator prototype properties always_draw_idle_animation, performance_to_sound_speedup and min_perceived_performance.
  
• Added optional offshore pump prototype properties min_perceived_performance, adjacent_tile_collision_box, adjacent_tile_collision_mask and center_collision_mask.
  
• Changed offshore pump graphics definition. Old definition will still be accepted, but is deprecated.
  

• Added optional parameters daytime and water_tick to LuaGameScript::take_screenshot() function.
  

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

Read this post on our website.

As one of the last entities which do not have high resolution graphics, the time has come for the offshore pump.

The offshore pump is practically a 1-tile entity, but they must have a 1 tile gap between each other. It is also the only entity placed on a water tile at the moment.

When we changed the way how terrain to water transitions work, we moved the offshore pump to be placed on the water tile. This can result in the pump drawing over terrain in ugly ways.



With the redesign, we took the oppourtunity to move the offshore back onto land, and additionally the pump checks a 2x3 tile water area in order to be buildable.



The new placement rules only applies to newly built pumps. Offshore pumps on existing maps will keep functioning, they’ll just be shifted out from the shore.

There is no blue colour for water integration at the tip of the offshore pump, so the offshore pump will look correct even with unexpected water types (not a big problem in vanilla). The water integration is split to an underwater layer which does not show when the pump gets landfilled over.



In the basic concept, the offshore pump is another type of a pump, so it should be similar to the other pump entity Albert made a few years ago, including the animation and visible fluid in it.

The obvious difference is the connection to water. However we felt that is not different enough and needs more visual balance, so we added a pair of supportive legs.

https://cdn.factorio.com/assets/img/blog/fff-336-offshore-pump.mp4

We are planning to release the new offshore pump graphics with the next release, likely next week.

Beacons strongly motivate building in rectangular repeatable patterns. The results generally look clean, but also very predictable and boring. Furthermore, the differences between different recipe builds are only minimal, so the visual difference between builds is minimal.



The issue is, I like to build the opposite of clean and predictable. The factory looking increasingly complicated and harder to expand over time is what keeps me engaged to continue playing a map. When it starts looking easy, I lose interest.

I’ve been trying to solve this for myself by either restricting myself from using Beacons (which is a massive sacrifice of productivity and speed), or by putting the sub-factories with high Beacon counts outside of the starting area, as keeping the organic starting area is key for me.



Eventually I thought about creating a mod that makes machines behave as if they had the maximum possible amount of beacons around them - allowing me to upgrade the starting base, but that also causes higher demand on the throughput of logistics, which the most interesting part - snaking more belts, fitting in more rails.



The mod defines 3 tiers for every producer to simulate beacons with tier 1, 2 or 3 of Speed modules in them. These machines cannot be further affected by normal Beacons and only accept special productivity modules defined by the mod.



Creating the mod was a ton of fun. I rewrote it about 3 times as I was learning how to do it better. I hacked together some basic graphics for it from some special passes (height and Ambient Occlusion) that we use for postproduction in our gfx workflow.

I played with the mod and got some interesting results (imgur album) as I was able to continue building in the starting area instead of refactoring it for Beacons.

Click to view full resolution

Lastly, I wrote a timelapse-screenshot tool. It can either be used by taking a screenshot each N ticks automatically, or in my case I give it a folder with savegames and it takes X number of screenshots, then moves to the next savegame. It's quite crude so I won't release it on the mod portal for now.



Making Beacons disappear into producer machines to allow for more organic bases fits my perverted playstyle, but Beacons actually do bring a lot of interesting motivations to the base game, and it can be a lot of fun to mess with the building rules that Beacons force.

You can find the mod on the mod portal if you are interested.

• Added Rocket rush scenario. more
  

• Changed Team production team joining system and cleaned up the map sets.
  
• Changed Wave defense bounty system and refactored unit spawning logic.
  
• Changed fire sticker to deal damage only once per 10 ticks.
  

• Added big scorch mark which is now used by atomic rocket and nuclear reactor meltdown.
  

• Fixed that fluid energy source effectivity was not shown in the tooltip. more
  
• Fixed that the default column ordering in the update-mods GUI didn't match the visual ordering. more
  
• Fixed that train could accelerate for one tick into wrong direction when train stop is disabled. more
  
• Fixed that minimap would not allow setting temporary train stop when train would have to change movement direction. more
  
• Fixed damage value in sticker tooltip was 60 times too small.
  
• Fixed icons with overlays were drawn incorrectly when used in rich text. more
  
• Fixed PvP error when DEFCON was active alongside normal labs. more
  
• Fixed that modded recipes with no products or no ingredients still showed those sections in the recipe tooltip. more
  
• Fixed that modded burner generator equipment didn't show pollution in the tooltip. more
  
• Fixed teleporting or changing the force of an entity with a control behavior that was connected to the logistic network. more
  
• Reverted optimisation that caused inserters picking up items from belts to be slower.
  

• Added support to filter on-damaged trigger effects through the trigger prototype definition.
  
• Added secondary_draw_order property to simple-entity prototypes.
  
• Added StickerPrototype::damage_interval, defaults to 1.
  

• Updated the window of creating/editing blueprint.
  

• Added LuaTile::surface read.
  
• Added event filtering support to on_sector_scanned and on_entity_cloned.
  
• Added "original-damage-amount", "final-damage-amount" and "damage-type" filters to the on_entity_damaged event filters.
  
• Added LuaGameScript::is_valid_sprite_path().
  
• Removed the required argument from LuaEnity::to_be_deconstructed() because it did nothing.
  

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

Read this post on our website.

Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love.

So after 4 years of accruing wisdom, I started making some general improvements.

I think this is one of the main suggestions people had for team production. The scenario just shuffled the players and assigned people randomly, and you could end up all alone playing against your two best friends.

Now I believe anybodies first choice would be to add a GUI to handle this. I will go on about GUIs later, but short story is, I didn't want to add a GUI. They add a lot of complexity, and my development mood these days is to keep things simple and small in scope.

So I added little colored launchpads!



I think it is quite intuitive, you will instantly be able to see which team has which players, you will see what map position you will be in when the round starts, etc. Another benefit is that if you want to spectate, you can simply just not walk onto a launchpad, and use the map view to see what's going on (before, there was a button you would press to join the spectators team).

The idea to use tinted concrete came from Albert, as originally it was just a tinted square rendering over the tiles (which didn't need any new prototypes defined) and it looked very janky. A consequence of this is that we now have colored concrete tiles in the game. There is no item available to place color concrete, but players will be able to access them in the editor mode.

This is the not so glamorous but still important polishing we need to make. Things such as fixing GUI styles, switching the loaders to stack inserters, making sure the map sets are making sense, etc.

I also spent some time making the challenges more predictable, the logic before could give a lot of variance to the difficulty of the production objectives, and make things hard to balance. One problem I see in the future, is that the production challenges are 'hardcoded' for the base game. If I find some more time later I might work on a system to more procedurally create the objectives.

I was inspired by some comments a few weeks ago, saying that the Wave defense scenario was a bit of a pushover, especially with a couple of players working together. So I thought an easy adjustment would be to scale the 'wave power' somehow to the number of players. It was a simple change and we released it with 0.18.4 a few weeks ago. Jobs a good'un right?

Well after play-testing it more extensively over the weekend, I realised it wasn't quite so simple...

A major problem is that the players earn bounty for every biter that it killed. So if I make the waves bigger, then the players earn so much more money, and can buy so many more upgrades, that the scenario is even less challenging than before.

The solution to this is quite abrupt, I just remove the bounty from the units, and this makes the design work better in my eyes:

• Bounty is only earned from spawners and worms.
• You can't sit inside your walls and earn money for upgrades; You need to actively go out of your base to earn upgrades.
• Players could set up infinite money farms by spawn camping the biters; This is no longer possible.

A consequence of this is that the upgrade prices and bounties needed to be rebalanced, which was actually a little bit easier since the number of spawners and worms is way more predictable.

I also noticed that biters spawning would always hit the base defences at the same places very reliably. This is great if you are the player and only want to invest 1 flamethrower turret to repel all the attacks.

https://cdn.factorio.com/assets/img/blog/fff-335-waves-before.mp4

So I added an extra command to the biters orders, that tells them to first go to a random point within the base, and from there go and attack the silo. This means that the positions where biters intersect your defences will be less predictable.

https://cdn.factorio.com/assets/img/blog/fff-335-waves-after.mp4

Another observation I made is that even though I increased the 'wave power', the number of biters was still being limited by the number of nearby spawners. This was due in part to a mix of me being clever with optimization and wanting to not make the groups too big. In short the spawning would work something like this:

• Determine the wave power, bases on factors such as wave number, player count, difficulty.
• Determine how many spawners we spawn from, something between 4 and 15 typically.
• For each spawner, pick a random number of biters to spawn, between 20 and 30.
• Spawn the biters, and remove their 'cost' from the wave power. If we have no more wave power we stop.
• Once we have gone through all spawners, we are done (even if there is a lot of wave power left).

The problem here, is that we are constrained by the spawner count and unit count. Even if wave power was 10x higher, the logic could still just decide to spawn 50 small biters from 4 bases and call it done.

Well okay I was a clever boy, and now lets remove all this complicated logic and keep it simple:

• Determine the wave power, bases on factors such as wave number, player count, difficulty.
• Determine how many spawners we spawn from, something between 5 and 20 typically.
• Divide the wave power by how many spawners we have.
• Keep spawning units at the spawners until all the wave power is used up.

This way, if we have 10x more wave power, no matter how many bases we spawn from, the wave will be 10x more powerful.

I had a few requests for this, and it wasn't so hard to add. If enabled, the Wave defense map will be infinite instead of an island, and the only way to win will be to launch a rocket.

Adding a new scenario at this point of development is a surprise to be sure, but hopefully a welcome one. The concept for this is that you are on the 'space platform', and you are preparing to land on the surface, and once on the planet you need to launch a rocket as fast as possible. You start with all technologies unlocked, and some money to buy starting equipment.



Once you and your friends are prepped, you head down to the launchpad to start.



And then that is pretty much it, you get teleported to the surface, and play the game as usual. We can afford to add this scenario because it is so small in scope and so simple, and it took less time to make this new scenario from scratch than updating what we already have. Maybe it is not the best thing since sliced bread, but I am hoping that my small investment of a few weekends will at least give some players a few more hours of enjoyment. I would be interested in adding more 'small scope simple scenarios' in the coming months, if we have enough time. If you have ideas that might fit this definition, please let me know (but no promises).

It is the classic problem, we optimise a system so its 5x faster, and then we use it 5x more. This time it is the case of flamethrowers and particles again. With 0.18 we added the damage effects for entities, and we generally like the way it works. However when this is combined with flamethrowers, we encounter some problems.

https://cdn.factorio.com/assets/img/blog/fff-335-biter-damage.mp4

First you might say, "It doesn't make sense that a burning biter will spurt blood", and I would agree. Second you might say "That is a lot of blood", and I would agree with that too. In fact it is 1,416 damage events worth of blood particles. The way flamethrowers currently work means they do a small amount of damage very frequently, in contrast to say a grenade which does a high amount of damage in a single action. Even with all the particle optimizations, the performance would once again suffer due to the sheer quantity of particles being created.

So Rseding has gone ahead and killed 2/3 birds with 1 stone, and added damage type filtering to the entity damaged and entity died trigger effects. This means for our immediate problem of bloody burning biters, we can just filter the damage effect to not occur if the damage type is fire, which solves it perfectly. In the longer term the benefits are even greater, as we now have the capability to for instance, make custom dying effects for being run over, or damaged by laser, or dying by poison etc.

Well that solves half the problem, but still, 1,400 damage events is still going to cause problems in other cases. A big part of this comes from the 'fire sticker', which applies damage every single tick. Since it lives for 30 seconds, that is 1,800 damage events. So a nice easy change posila has done, is to add a 'damage interval' to the sticker, so that damage is only applied every n ticks. For now we have set the fire sticker to do 10x the damage, but only every 10 ticks, reducing the number of total events for the sticker from 1,800 to 180, a lot more reasonable. (Note, changing this frequency can affect the damage balancing, as the resistances system in Factorio has an absolute reduction and a percentage reduction. In our case, the entities affected by the fire sticker had no absolute fire resistance, so the result is the same.)

All the changes you see here should be released soon, we are in a rhythm now of doing 1 release every week (typically on a Tuesday), and everything you see here is pretty much done (but anything can change!).

• New visuals for poison capsule effect.
  
• New dying effect and remnants for flying robots.
  

• Entity destroyed alert - Sound softened and lowered in volume.
  
• Weapon sounds (WIP) - new Pistol, Submachine gun, Gun turret, Laser turret.
  
• Logistic chests open sound (WIP).
  
• Poison capsule cloud (WIP).
  

• Fixed that reordering heat buffers during the same tick a different heat buffer was built would leave the heat buffer state corrupted. more
  
• Fixed that entity sounds with probabilities would loop forever once they started playing. more
  
• Fixed rocket silo tooltip did not include contents of the rocket result inventory. more
  
• Fixed that styles were applied to wrong slot in a filtered train view. more
  
• Fixed that server authentication would fail if both the token and username and password were provided. more
  
• Fixed that changing inserter pickup/dropoff through mods didn't work correctly. more
  
• Fixed that combat robots had their fire resistance overwritten. more
  
• Fixed that rolling stocks were not pulled correctly when train was moving through curved rails. more
  
• Fixed that LuaEntityPrototype::burner_prototype didn't work for the burner-generator entity type. more
  
• Fixed janky construction robot flying animation during repair work. more
  

• Added optional LuaItemStack::build_blueprint raise_built.
  
• Added LuaInventory::find_empty_stack(), count_empty_stacks(), and get_insertable_count().
  
• Added LuaEntityPrototype::heat_energy_source_prototype, fluid_energy_source_prototype, and void_energy_source_prototype read.
  
• Added LuaGameScript::encode_string() and decode_string().
  
• Added on_player_set_quick_bar_slot.
  
• Added on_pre_player_toggled_map_editor.
  
• Removed LuaPlayer::name write. more
  
• Removed core lualib util.encode() and util.decode().
  

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