Factorio News

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 log() or game.print() 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 debug.debug() and print() 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 remote.call() and most of script 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 log() - 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.

[previewyoutube][/previewyoutube]

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.

[h3]Choose your teams[/h3]
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.

[h3]General cleanup[/h3]
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...

[h3]More biters; more money[/h3]
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.

[h3]Predictable attack locations[/h3]
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

[h3]More wave power; same wave size[/h3]
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.

[h3]Infinite map option[/h3]
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!).