1. Factorio
  2. News

Factorio News

Version 0.18.18 released

Changes


  • Adjusted steam engine and turbine collision boxes so player can walk between two steam engines.
  • Roboports allow exporting both logistics and robot stats at the same time. more
Graphics


  • Added offshore pump remnants.
  • Added new dying effects for biters, spitters, worms, and spawners.


Gui


  • Added confirmation box for deleting blueprint book.
Sounds


  • New or updated sound effects include:
  • Transport belts - new concept for these sounds.
  • Turrets rotation sounds and fold/unfold.
  • Weapons improved and made more powerful, e.g. submachine gun, shotgun, gun turret, vehicle machine gun, Laser and electric beam.
  • Particles: Water splashes, Tree debris.
  • Various mix level tweaks including the train, enemies.
  • Attenuations (audible distance) adjusted for entities such as Pipe, Substation and Offshore Pump.
  • New sound when walking over ore patches.
  • Default Sound Settings Updated:
  • Music, Game Effects and Walking sound lowered, Environment sounds and Master Level raised.
  • Zoom audible distance and volume levels adjusted.
  • Maximum Environment Sounds increased (edited).
Bugfixes


  • Fixed mining entity with randomized mining result amount would never return the largest defined amount. more
  • Fixed crash when loading replay. more
  • Fixed reading LuaPlayer::entity_copy_source when the player is dead. more
  • Fixed that upgrading and delivering modules at the same time didn't work right. more
  • Fixed a crash when closing the game while some GUIs are shown. more
  • Fixed crash when setting max_group_gathering_time and min_group_gathering_time to the same value. more
  • Fixed discharge defense equipment had the wrong sprite in the equipment grid. more
  • Fixed that artillery wagons wouldn't show out of ammo icons. more
  • Fixed that modded cargo wagon colors wouldn't copy correctly through blueprints. more
  • Fixed furnaces with recipes using fluid ingredients could cause crash. more
  • Fixed a crash when removing a player that has modded associated character entities. more
Modding


  • Furnaces now ignore off_when_no_fluid_recipe property of their fluid box definition. Fluid boxes will not be disabled based on enabled recipes. more
  • Changed colored concrete tiles to be non-mineable.
Scripting


  • Added LuaEquipmentPrototype::automatic.
  • Added "include_entities", "include_trains", "include_station_names", and "include_modules" fields to LuaItemStack::create_blueprint.
  • Added LuaRoboportControlBehaviour::read_logistics and read_robot_stats
  • Removed LuaRoboportControlBehaviour::mode_of_operations


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

Friday Facts #341 - Audio, Artillery, Attenuation

Read this post on our website.

Sound design update (Ian)

One advantage of switching to home working during the COVID-19 crisis is the ability to listen to the game using speakers rather than headphones, and this has proved useful in balancing the relative levels of the game. Val has also been getting to grips with Lua, and this has led him to working on attenuations, which have been proving problematic. For instance, we noticed that sounds such as the radar were getting cut off when you walked away from them, rather than fading out cleanly.

I investigated and discovered we had a maximum environment sound limit of 15, by raising this to 50 we have eliminated many of these problems. But then the downside is that there are now more sounds playing and therefore more clutter to mix and balance.

Pink squares indicate which sounds are active.=

Limit of 15 nearby sounds.

Limit of 50 nearby sounds.


Rseding has been working through the list of sound design programming tasks, for instance we finally have the sound for the artillery turret rotation integrated into the game (which was featured in FFF-252 quite a while ago).

https://cdn.factorio.com/assets/img/blog/fff-341-artillery.mp4
Real in-game footage of the new artillery sounds

In other news, we have an updated concept for the transport belts. We listened to feedback from the community that they were still a bit too present and annoying. The idea of the new sounds is that they will drift into the distance a bit more and become unnoticed (until you try to fall asleep).

More fun sounds include water splashes, electric and laser beams, more powerful weapons such as the gun turret and vehicle machine gun. And our old robot sounds have come back as additions.

If all goes to plan, we will merge the sound changes into master very soon, and once we've done all our pre-release checks, release it to the 0.18 experimental.

After that, I plan to spend time on UI sounds, and also balancing the overall levels to get them more in line with other games, which is trickier than normal given the lack of audio middleware. However we have also made some changes to the default sound settings that move us in the right direction.

Attenuation (Val)

Lately Ian and I were occupied with mixing and sound attenuation of the game. Attenuation of the sounds is a great tool for mixing a game. Using it you can make all sounds more located, take a certain place, you can clearly hear what object you are passing by, and sounds don’t overlap each other as much. Another bonus is that reaching an object won’t shock you with the full volume of its sound, as it is audible at a distance and ramps up in volume. All that brings you a clearer mix of everything you hear in the game.

While checking the offshore pump and I noticed that pipes produced a small part of their loop when I walked near them, even if there was no water flow inside.

https://cdn.factorio.com/assets/img/blog/fff-341-fluid-sound.mp4
The pipe is making a sound, even though no fluid is flowing

Rseding told me that it must be a conflict of the entity working_sound in combination with the max_sounds_per_type we use to limit the number of certain types of sounds playing at the same time. After thinking a while, I decided to remove the max_sounds_per_type and added a audible_distance_modifier with a very small value for pipes. I tested that, and for my happiness it worked well in this case.

There are probably another 100 little issues like this in the sound design, it is not as simple as replacing all the audio samples, and we are getting there. This is also why your feedback and bug reports on the sound changes are extremely useful to us, as we need to take care of as many areas as we can before 1.0 arrives.

Friday Facts #340 - Deep desyncs

Read this post on our website.

Not mentioning it would be weird

I really think everybody has heard all about this and nothing else over the last few weeks, but yes, the Coronavirus.

For now, with Factorio, everything seems okay. We are all working from home, the team is still going, and so far we are following our plan quite well. We released the Character GUI and Statistics GUI last week, and some improvements such as new water splashes and leaf animations this week. Things are still moving along.

However it is still early days, we haven't really had any experience having the whole team work remotely, so there may be some challenges we need to tackle as time goes on. At the moment we don't know whether this will affect our 1.0 release date, I guess it will one way or the other, but for now we aren't announcing any changes.

[h3]Business as usual[/h3]
Apart from the development side still running, our e-shop is also remaining operational, and we have just restocked on all variants of our t-shirts. While we can't guarantee anything, if you order from us at this time, we should still be able to get your t-shirts to you.

Deep desyncs

Last week there we had quite a few more players than usual, and Krastorio 2 was released, which meant a lot more hours into a lot more areas of the game. During the week, Boskid and I received quite a few desync reports with mods. Generally we believe, that it is probably the mods causing the problem, as it is quite easy to cause a desync with the control scripting if you don't know some very important gotchas.

But still, we decided to investigate to help the players find out which mod is causing the problems.

[h3]Serpent cyclic references[/h3]
One quite tricky desync we found, is related to cyclic references, and the way serpent serialises the global Lua data.

Take the example here of the Construction Drones mod. You have a player which dispatches the drones to go do work; the player needs to keep track of what drones he owns, and the drones need to remember which player they belong to.



Now this works fine during runtime, you can access the drone from the player object, and access the player from the drone object. When the game is saved, Serpent goes through all the data in 'global' and serialises it for later. To handle the cyclic references, if serpent detects that it has 'seen' an object already, it writes a placeholder value, and comes back to fix it later.

The problem, is that serpent chose nil as the placeholder value. In Lua, writing a table value as nil is the same as deleting the key, and the key won't be seen when looping the table in the future. When serpent then goes back to 'fix-up' the placeholder values, it ends up with each peer saving a different table ordering (because of some even deeper technicalities with our custom version of Lua).

So the problem is deep and was quite hard to find, but the fix is quite simple. Boskid simply changed the placeholder value from nil to 0, and now the iteration order is saved and loaded correctly every time.

[h3]Unit group max speed[/h3]
Another report came in from a player using Krastorio 2 and Rampant mods. This one on the surface really seemed like the mods fault, since all the diffs in the desync reports were related to unit positions, and the Rampant mod is all about units.

The desync was extremely fragile, and was very hard to reproduce, but eventually Boskid managed to narrow it down. This is a screenshot taken on the exact tick that the desync occurred.



What jumped out to me as immediately suspicious, is that the biter is only just moving onto the creep. This is because the creep (from Krastorio 2) gives the units a speed bonus when walking on it. I did a quick experiment by commenting out the tile bonus code in the engine, and the desync did not occur again.

But of course removing the code here would only treat the symptom, and the cause will be something deeper (FFF-296). So with lots of patience, Boskid narrowed it down further and further, deep into the movement and unit behaviour logic. What we found, is that the unit is part of a unit group, and this group was caching the value of its 'max speed' based on the fastest unit in the group. However this value was not saved with the save game, but was recalculated each time the game was loaded. Since the unit was walking on creep, it has a higher max speed, so the group calculated a higher max speed when the game was loaded.

Now this logic has been in the game since unit groups began, but it only became a problem more recently. In versions of Factorio 0.16 and before, a units max speed was always going to be based on its prototype, which does not change after the game is loaded. With version 0.17 we added 2 (really nice) mod capabilities:
  • Allowing units to be affected by tiles;
  • Allowing scripts to change unit speeds directly.
It didn't come up as a problem initially, as the freeplay base game doesn't really use these capabilities.

Well every change has the potential to break things. Since we know the only 2 cases where the units speed can change, Oxyd made it so that the unit will notify the group to recalculate its max speed when it is necessary.

Version 0.18.16 released

Graphics


  • New water splash effects using water particles instead of an animation.
  • New animations for leaf particles.
Bugfixes


  • Fixed the tank not being properly centered to its bounding box (graphical issue).
  • Fixed GUI windows not drawing properly when they can't fit the screen width. more
  • Fixed glowing Heat pipe ending sprites. more
  • Fixed some character bonuses in bonus GUI not being printed correctly. more
  • Fixed character GUI player color sliders not changing chat colors more
  • Fixed that hotkeys wouldn't work while using the character logistics GUI in some cases. more
  • Fixed a desync related to unit speed changing while part of a unit group. more
  • Fixed some Trigger Effects not showing correct repeat count in tooltips. more
Scripting


  • Added LuaEntity::effective_speed
  • Added LuaControl::is_flashlight_enabled
  • The 'on_ai_command_completed' event will now fire for distraction commands.
  • Added 'was_distracted' to the 'on_ai_command_completed' event. If true, it means the completed command was a distraction command.


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

Friday Facts #339 - Beacon HR + Redesign process

Read this post on our website.

The beacon is one of the last entities left to convert to HR. As always, before 'just re-rendering' we take the chance to re-think the concept and modernize it. This post will try to go a bit deeper in the process of redesigning such an entity.

The old beacon




At the beginning of the project, the style of the game was less or more clear: nothing looks brand new. Everything looks dirty and DIY. The machines need to be full of details, if possible trying to explain its mechanics. The colors are provided by the raw materials. The bounding box is everything. And some other rules that I don't even remember now.

The main handicap at that time was that we didn't have the experience of how the average player is composing the factories. So we produce a nice looking model but once it is placed in the factory, it doesn't look that nice due to the lack of context.

The process for the new beacon

The beacon is a very advanced late game entity. Usually placed very close to each other in long rows, horizontal or vertical. Its function is to provide extra power to other entities in its surroundings through the air.

One of the main objectives for the redesign is not only a better coverage of the most common needs of the entity (shape recognition, working good in its context, and total integration in the world of the game) but also its expressivity.

It would be really good to understand the use of the machine just by looking at it.



In this early sketch the main concepts are already defined.

It needs to be a tower in order to transmit the effect. But the tower has to be transparent, otherwise it will occlude the other entities behind, creating a problem of readability.

It has to look modern. That's why the conical shape with rounded windows. It reminds of a soviet space capsule. The blinking lights inside will help not only to look more technological, but also will help for visibility.

Due to its normal usage in long rows, the plan was to create an extra tileset of cables connecting the beacons to each other. So the composition would look much more interesting and organic with the player moving under this network of beacons.

The idea is cool and it works on paper, but once we get to work, we realise that it's needed to fill a square of 3x3 tiles. Once in the 3D viewport, this concept changes too much to not think of different solutions.

Connecting the entities with cables. It looks like the beacons are interacting with each other creating a more powerful net of beacons, and this is sending the wrong message.

Save the good stuff and solve the problems in a new version

The main problem was the need of stuffing the tower in a squared area. This rule of the collision box forces every entity to be some sort of a blocky box on top of the ground, always, and for this entity we really needed the tower.



To solve this issue a new concept appears: Let's create a hole in the ground that covers the collision box area, and build the tower inside. It looks higher than what it really is, and the occlusion with the tiles behind is in the acceptable limits.



The beacon looks modern, colorful, tall, high tech, and integrated in the world of Factorio. It even solves the collision box issue and is easy to recognize from afar. But it has something wrong: it doesn't work fine in an array, and the center of the entity is too complicated. It creates a chaos of pixels that is hard to see, especially when overlapping with another beacon vertically.

A better beacon

To solve the ultimate complication for the array situation, a few changes are relevant to do.
Cleaning up the center of the entity in a way that works as a background with himself when overlapping in vertical (or any other tall entity, like a pole).



In the so common array situation, it's going to be really nice seeing the beacon with some variations. This will make it look more natural, and pleasant to the eye.

We would like to use this sort of variations for every entity, but the amount of work and VRAM needed would be just insane.



This is still a work in progress. Right now I’m working on the animation of the beams. I’m trying to make it much more subtle, because the way it is here it calls too much attention and saturates the screen very easily.



The layer of the beams and the light will be separated and tintable in a single spritesheet. Probably the yellow rounded light also. It will be available for any modder to make a modified beacon just by changing the RGB values.

There are many things I didn't say about this process of redesign, but I had to keep them out because this post is already very long. I hope it was interesting to you.In future releases, very soon, you’ll be able to play with it.