Read this post on our website.

In the recent patch notes, there was a line "Fixed landfill spawning under player when building landfill elsewhere. More" and some people on Reddit were wondering how did this bug happen in the first place, and asked for the long version and even suggested we could even use it for Friday Facts, and I thought: "Yeah, if I am going to spend time writing this, we should consider using it in FFF so someone else doesn't have to spend time writing something else." ... but I am going to stretch it out.

https://cdn.factorio.com/assets/img/blog/fff-346-landfill-bug.mp4
The landfill bug reported after the release of 0.18.21.

Disclaimer: I have not been around during the ancient parts of this story (speaking of which, it's my 5 year anniversary at Wube, yay!), and changes I have been around for, or even done myself, I might not remember correctly. So this might not be accurate. In fact, let's say the story is purely fictional and any resemblance to real world events and people is just a coincidence.
For the first couple of years of Factorio development, water drew a transition over ground tiles. The graphics for the transition tiles was taking too much space from the ground tile, so it was not possible to draw a single tile of ground surrounded by water... nor 1 tile wide tile bridge going through water. In addition to that, the transition graphics was tileable only with grass terrain. To enforce these constraints, the map generator was enhanced by tile correction step, the purpose of which was to make sure, that the terrain is possible to draw without any graphical artifacts. (If you wonder why the game didn't use Wang tiles instead, I know they were considered, but why they were not used I don't know. Based on the original water transitions it looks to me like things started with the intention to use them, but they ended up not working well with noise-based map generation. That's just my speculation though).

Of course, the tile correction was executed also when tiles were changed by means other than the map generator. From script for example. Mods that allowed players to place tiles emerged. One of them was Landfill, which was adopted into the base game eventually, and as far as I remember, the major trigger for that were reports from people who happened spawn on large island, and after 20 hours of playing the map, they found out they could not continue it. Adding landfill to the game solved those issues but created a new one. When placing landfill, the tile correction logic could decide to "correct" the tiles the player was standing on - trapping player in the water (bug report).

https://cdn.factorio.com/assets/img/blog/fff-346-correction-bug.mp4
Bug report from 2016 - Placing landfill traps the player

As the team working on the game grew, it was decided to do another pass on the terrain graphics, put much more time into it, and change things around. As you probably already know (since we keep talking about it in past weeks), the ground draws shore transitions over water tile now, and shores are not limited to grass terrain any more. This made tile correction mostly obsolete, but it is still used to enforce some soft tile placement rules during map generation. For example that deep water should not be adjacent to ground tiles. Since we were leaving the logic in anyway, the possibility to define new tiles such that they would not be allowed in just 1 tile wide remained also.

Again, as you probably remember from 2 weeks ago, the new transition graphics and newly possible 1 tile wide creeks made it feel like player is getting stuck on invisible walls, or is unable to step over a really narrow gap in the ground. In addition, we already had the character slide a little bit around entity corners, and the new corner tile transitions that were visually diagonal, made me miss this behavior when colliding with tiles. So I started reworking how player character collided with tiles and how those collisions got resolved. What I found worked well, was to ignore the bounding box of the character and just test the terrain directly at player's position. If the tile type at that position is walkable, the player doesn't collide, if it is not walkable, we figure out shape of the transition on that tile and make the character to collide only on some parts of the tile. (note: this assumes walkable tiles draw transitions over non-walkable ones, in case you are thinking of creating a mod with new terrain type that player won't be able to walk on.)

https://cdn.factorio.com/assets/img/blog/fff-346-character-movement-no-transitions.mp4
Character movement when not considering tile transitions

My goal was to make player movement not be frustrating around water, and intended the rest of the collisions to work as they used to, despite for example enemies not being able to always chase after player. The map generator didn't create maps on which this would happen often, and I didn't mind players using landfill to create passages that could not be crossed by enemies. It just didn't seem to be worth further fuelling this chain reaction of solution to previous problem creating more new problem, because changing player collision was not without it's own issues either (have you noticed anything unusual about walls placed next to water? hint hint).

Anyhow, what I wanted to do, was to make a special collision function for the player character, but I soon learned, we have several collision functions for different situations, and I didn't want to make special version of each of them, so I decided to add a flag to character's collision mask, that would modify the collision detection method. Naturally, I wanted to make it is possible for modders to change the collision mask of the character entity, so I exposed the flag to prototype definitions.

Mods ended up using the flag on non-character entities, and after Oxyd reworked the pathfinder, the flag started to cause crashes... Oxyd fixed it, but he changed my special logic to consider the entire bounding box again, instead of just the entity position, which made the feeling of player movement worse. This time I decided to solve it by adding optional parameter to the collision functions (instead of yet-another flag), that would indicate that the collision is being calculated for a player controllable entity, to determine if the old behavior should be used or not.

And that's how the bug was introduced. Remember that landfill bug with tile correction creating water under player? Well, the fix for that was to add a piece of code to the end of "build terrain" routine that would check the player who built the tiles is not colliding with water, and if they do, just place the ground underneath them to correct the result of tile correction. The special player collision logic allows characters to get so close to water tile that its bounding box collides with the water, and when I added the extra parameter to the collision functions, I didn't adjust this code, so it was using "consider the entire bounding box" collision behavior and falsely detected the character entity as colliding with the tiles and tried to save the character by placing ground under its feet.

https://cdn.factorio.com/assets/img/blog/fff-346-bug-reveal.mp4
Landfill bug

And here comes the revelation. The big confession. When the first post reporting this bug came in, I immediately knew what the problem was. It wasn't the first time I've seen it. The same issue happened to me when I was making the special player collision logic the first time around. Back than I caught it and fixed it even before the entire tile transition rework was merged to the main code base. But I didn't make a test. I did not... make a... test.

So that's how bug like that happens. The short version would have been something like... the bug was the result of long forgotten pieces of code, that are supposed to solve an edge case problems that were usually created by solutions to other edge case problems, interacting in an unintended way after changes that were made to solve yet another edge case problem.

In Czech we have a saying for which I have not found English equivalent. "He who does nothing, breaks nothing." It is a kind of reassurance when something unintentionally breaks during an activity, resulting in inconvenience. The only way to make it a certainty that nothing would have broke would have been to do nothing. At times the proverb sounds like an advice... if I can't figure out all the problems a new feature, change, or bug fix will cause, or just the number of potential issues that will need to be solve to do the change seems overwhelming, doing nothing starts to feel like an option with the best possible outcome. But, that's just analysis paralysis creeping in, and what I need to do is to remind myself the intended meaning of the proverb, and stop worrying about potential problems that may not even be real in the end, and if they are, they will be just inconveniences that will be eventually solved too.

This week we're happy to show the latest in visual effects that Dom has been working on. Carrying on the topic of improving the way the terrain and environment feels and reacts to the player, Dom and posila have spent quite some time working on movement effects for the character and vehicles.

As you walk around, on certain terrains, the character will kick up some dust and dirt.

https://cdn.factorio.com/assets/img/blog/fff-346-character-walk.mp4

The effect actually makes a really big difference to how it 'feels' to walk around, which the GIF might not show that well. Especially with some exoskeletons equipped, you really feel like your zooming around in a real place.

Waking around will also leave some subtle footprints in the ground, which helps connect the character to the terrain.

https://cdn.factorio.com/assets/img/blog/fff-346-vehicle-trails.mp4

The vehicles also kick up the dust and dirt as you drive around. This feature actually is not simple as it would first seem from the result, but there are quite a few new features under the hood to make it possible.

Read this post on our website.

Last weekend, a bug report came in on our forum. The issue was that the groups of biters were trying to path over the water, but the bugs can't swim.



It seemed like something quite typical of a mod being funky. I looked into it, and it seems the Hovercraft mod was playing monkey business with water collision masks to make his vehicles ride over water. One thing involved setting water tiles to be walkable, and then adding an additional collision layer to all players and biters.

What this modder didn't realise though, is that unit groups have a fixed collision mask. It used to be hardcoded, but a while ago it was added to the utility constants. So we just say "hey its a mod problem, here's a quarter, call someone who cares"... right?

Well it didn't sit right with me, because deep inside I knew that the unit groups shouldn't have a fixed collision mask, it doesn't make sense really. Lets say you add flying units to the game. If you give individual commands to the flyers to go attack the base, they will happily fly over the water and attack without issue. However if you put them in a group together, a group of flying units, the group will path around the water, because the unit group still has a fixed ground collision mask.

So this week I decided to fix it once and for all. It turns out it wasn't so hard in the end. As we mentioned somewhat in FFF-340, unit groups already have logic in place to recalculate their properties based on their members. I hooked into that logic to also make them recalculate their collision mask.

The way that made sense to me, is that they should add the masks together, so that they only path where all of the units can path.

https://cdn.factorio.com/assets/img/blog/fff-345-small-biters.mp4
A group of only small biters, they can't walk on water, so they walk around it.

https://cdn.factorio.com/assets/img/blog/fff-345-water-biters.mp4
A group of 'water biters'. They can walk right over water, so they go straight through.

https://cdn.factorio.com/assets/img/blog/fff-345-mixed-biters.mp4
A mixed group of small biters and water biters. They add their masks together, so only go where all the units can go.

You can imagine it quite intuitively I think, the group will try to stick together, and that will mean the group can only path to places that all the members can reach.

It feels quite nice to make fixes like this, as they are relatively small in scope and risk, but cleanup a lot of potential problems, and open a lot of interesting possibilities.

Another nice small finishing touch for you all this week. Adding a shell being ejected from the Artillery cannons was suggested back when we showed the new sounds integrated into the game (FFF-341). While we can't get too fancy with it, we think the relatively straightforward effect that we've added fills in the detail nicely.

https://cdn.factorio.com/assets/img/blog/fff-345-artillery-shell.mp4

It is just a particle with a nice spritesheet that Dom rendered from the original shell models. With a bit of engine tweaking here and there, we had it ready in quite short order. Just another small bit of polishing that characterises this stage of development.

• Added shell particle effect for the artillery shooting.
  
• Added tinted scorch marks for explosion effects. Explosions on different tile types will result in scorch marks of different colors.
  

• Pressing escape/close GUI when a search field is focused only closes the search field instead of the entire GUI.
  
• Updated GUI styles for PvP configuration GUI.
  
• Unit groups will determine their collision mask based on the collision masks of their members. more
  

• Fixed landfill spawning under player when building landfill elsewhere. more
  
• Fixed a crash when a train recalculating path during movement is unable to reserve rail signal within movement distance. more
  
• Fixed production statistics corruption when recipe returns some but not all catalyst. more
  
• Fixed a pathfinding crash related to changing tiles in a way that affected neighbouring tiles' transitions. more
  
• Fixed that malformed data in data.raw wouldn't show the minimal-mode failure GUI. more
  

• Fixed that writing to mod settings would silently ignore bad values.
  
• Added "allowed_effects" support to the lab.
  
• Added "creation_distance_orientation", "use_source_position", "height" and "vertical_speed" to particle creation parameters (related to shooting effect shell particles).
  
• Added "scorch_mark_color" to TilePrototype.
  
• Added util.remove_tile_references for easier compatibility maintenance with future game updates when removing base game tiles.
  
• Removed migration for CustomInputPrototype consuming types that were removed in 0.15.24.
  

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.

We first mentioned a change to our tile transition logic back in FFF-199, and not long after in FFF-214. These two posts focused more on the visual side, and how it makes the game terrain look so much better.

In short, the tile transition logic overlays an additional sprite over adjacent tiles, so that where the two tiles meet has a much more natural look.


Tile transitions on.

Tile transitions off.

So while the looks were taken care of, we also had to deal with the 'feel' of the tiles. The easiest example of this is the 1x1 landfill 'stepping stones'. It really looks like you should be able to walk/drive across the 1 tile of water. So we added in an additional layer of collision checks, which will consider the transitions when performing the logic of what can go where.

https://cdn.factorio.com/assets/img/blog/fff-344-stepping-stones.mp4

Now some of the cheesier among you will know that biters don't know how to get across these 1 tile gaps. That is because simply we never enabled the biters to use this collision check logic. One reason is that more checks means more UPS usage for the biter pathfinding, another is that we didn't think it was necessary. However it was available in the engine, and any mod could enable it if they want. That is exactly what I did with my Mining drones mod. Initially this seemed to work, and I thought it might make them walk around lakes a bit more naturally (like the player character does).

However quickly I noticed that people were reporting on the forum that the game was crashing with the mod installed. I quickly reverted the change to my mod and we started looking into it. It turns out that the new abstract pathfinder we added for better unit pathfinding (FFF-317) was not set up to consider units using this tile transition collision logic. This same crash was happening sometimes without any mods installed, but the case was more difficult to reproduce, so this is a nice situation where mods help us work on issues in the base game.

Recently I have been working on another unit heavy mod, Transport drones, and the principle design behind the mod heavily relies on the tile collision logic (the units don't even collide with entities). It turned out to be a really nice test of our new pathfinder, but also highlighted some of the issues that not considering the tile transitions can bring.

https://cdn.factorio.com/assets/img/blog/fff-344-drone-zig-before.mp4
By not considering the tile transitions, the drone takes an awkward path along the diagonal road.

This week Oxyd finished his work on an upgrade to the pathfinder, so we can enable the tile transition collision logic with units. The change is immediately noticeable with the above example.

https://cdn.factorio.com/assets/img/blog/fff-344-drone-zig-after.mp4
By considering the tile transitions, the drones path much more naturally.

With the logic now in place, we are debating whether to enable it for biters or not. We probably won't, it is only a minor change and would have a non-zero performance impact (a rough test puts the worst case at about 5%), but then again it is a fun way to surprise those who thought the 1 tile of water would stop the biters attacking, and it kinda makes sense they can walk over it just as the player can. Well we will see if there are any issues with it in the modded cases before any further consideration.

As a bonus fact (this is Factorio facts after all), I spent a bit of time benchmarking some late game Transport drone based factories (screenshot), and found a few nice performance gains.

This Wednesday, Team Steelaxe set a new Any% multiplayer speedrun world record at 1 hour, 15 minutes and 21 seconds. This is the fastest anyone has ever launched a rocket in an unmodded Factorio game.



I am part of Team Steelaxe, so I want to take the opportunity to explain how we managed to beat the game this quickly. In general, it is all about planning and preparation, we estimate that we have put a combined 200 hours into planning just for this speedrun. The Any% speedrunning category allows to change all map generation settings, including disabling enemies. Multiplayer subcategories allow for up to eight players. Planning begins with picking a map seed. Since there are many possible maps to choose from, we let a script generate maps and automatically filter out the ones without enough ore in the starting area, and then handpick from there. With the map picked, it is possible to start planning the base. This begins with setting a target time to finish the game and calculating the amount of science and number of assemblers required from there. We then come together and arrange a base on the chosen map, which will serve as a reference for the factory built in the actual run. It should be noted that the category rules do not allow blueprint imports, so instead we usually have the planning save file open in another window or use screenshots during the run.


Part of the spreadsheet that contains every player’s responsibilities.

Another big part of the planning is also to create a spreadsheet of everyone’s tasks and when they should be done. We distribute the tasks so that two players build smelting, two build mining, one player builds the power plant and only three people build the factory itself. This strict divide means people only ever take and craft the material that they need, so ideally we don’t have to fight over resources. Furthermore, the task list allows us to optimize by shuffling tasks around, so that no time is wasted by anyone. One example of this is that only two people ever chop wood for power poles, the rest get the wood from them and do not have to waste time on finding trees. The task distribution also means that every player has a very different perspective of the speedrun, so here are some more:

• Zulan is doing mining.
• I (Bilka) am doing smelting.
• AntiElitz is another base builder.

With the complete plan prepared, we do runs and iterate on the planning, taking into account what worked well and what did not. The speedrun above is the result of a few of those planning iterations combined with some improvisation to compensate for mistakes in execution. It may not always sound like it during the run, but we are all friends and when someone makes a mistake, others jump in to help out, so the linked run is the result of good teamwork. Without everyone working together like that, we would not have been able to reach our target time of 1 hour and 15 minutes.

In the future, we hope to be able to launch a rocket in less than an hour, you can watch our next attempts on Sunday at 20:30 CEST on {LINK REMOVED}Twitch. You can find over 20 active speedrunners, resources such as save games and replays, or even try running yourself, at https://www.speedrun.com/factorio.

• Added new environmental trigger effects for grenade, artillery and nuke explosions. more
  
• Added 3 level 'First steps' tutorial Campaign. more
  
• Mini-tutorial improvements.
  

• Moved Compilatron and Compilatron speech-bubble entities from demo to base game files.
  
• Removed Introduction Campaign.
  
• Removed Compilatron chest, Compilatron roboport, Compilatron logistic chest.
  
• Removed Tutorial/Campaign Lualib (base/lualib).
  
• Removed other campaign-only prototypes, such as styles, sprites, sounds.
  

• Fixed that thumbnails wouldn't show in the update-mods tab of the mods GUI. more
  
• Fixed that LuaSurface::spill_item_stacks return value didn't work correctly. more
  
• Fixed that the research progress of the current tier showed for next queued tier in the technology GUI. more
  
• Fixed that the game didn't validate modded rail-planner item type values and would crash in some cases. more
  
• Fixed that modded units with consider-tile-transitions in their collision mask would cause the pathfinder to crash. more
  

• Empty layers in sprite or animation definition will yield an error now. more
  
• Added support for playing a sound when using smart-pipette.
  
• Added support for playing activate/deactivate sounds for night vision.
  
• Added support for playing a sound while an resource-style is being mined through mining_sound.
  
• Added mod-setting value "hidden" to hide mod settings from the GUI.
  
• Added 'invoke-tile-trigger' and 'destroy-decoratives' trigger effects.
  
• Added 'rotate-offsets' to the create-particle trigger effect.
  
• Added 'trigger_effect' to tiles. It is called with the 'invoke-tile-trigger' trigger effect.
  
• Added 'trigger_effect' to decoratives. It is called when the decorative is destroyed with the 'destroy-decorative' trigger effect.
  

• Added on_pre_script_inventory_resized and on_script_inventory_resized events.
  
• Added 'allow_paths_through_own_entities' and 'no_break' path finding flags.
  
• Added LuaModSettingPrototype::hidden read.
  
• Added 'to_be_deconstructed' to the options for LuaSurface::find_entities_filtered. more
  
• Added LuaGuiElement::badge_text read/write.
  

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

• Fixed a crash when loading saves from 0.18.12 and older while re-spawning and having personal logistics researched. more
  
• Fixed offshore pump selection box to match the new graphics. more
  
• Fixed possible performance issue related to animated trees in OpenGL rendering backend. more
  
• Fixed opening the character GUI through hotkey when the logistic tab isn't visible. more
  
• Fixed that curved rail ghosts selection didn't work quite right. more
  
• Fixed that the offshore pump would play sounds even when it wasn't doing anything. more
  
• Fixed wrong Lua docs for LuaCommandProcessor::add_command. more
  
• Fixed a desync when personal logistics is researched while a player is disconnected from the server with personal logistics disabled. more
  
• Fixed a crash when moving armors around in other players inventories in multiplayer. more
  
• Fixed a regression issue with the select-a-signal GUI related to group ordering. more
  
• Fixed that trying to load a save created from a scenario in a now disabled/removed mod would crash the game. more
  
• Fixed a crash when trying to join games through Steam when the Steam API fails to initialize.
  
• Fixed that the character corpse wasn't included in the post-player-died event 'corpses' parameter. more
  
• Fixed that trains pathfinder could create non contiguous path in case of single segment cycle with a single train stop. more
  

• Added warning for empty layers in sprite or animation definition. In next release, this will become an error. more
  
• Added a check to make sure placeable_by.count isn't larger than the placeable_by.item.stack_size. more
  
• Added support to play sounds when left clicking radio buttons and checkboxes.
  
• Added ParticlePrototype::fade_away_duration and vertical_acceleration.
  
• Rolling stock entities can no longer have next_upgrade set.
  
• Added support for rotated_sound on entity prototypes.
  

• Fixed that LuaEntityPrototype::fluidbox_prototypes didn't include fluid energy source fluidbox prototypes.
  
• Added LuaEntity::productivity_bonus, pollution_bonus, speed_bonus, and consumption_bonus read.
  
• Added LuaGameScript::create_inventory() and get_script_inventories().
  
• Added LuaInventory::destroy() and resize().
  
• Added LuaInventory::mod_owner read.
  
• Added LuaEntityPrototype::adjacent_tile_collision_box, adjacent_tile_collision_mask, adjacent_tile_collision_test, center_collision_mask read to access new offshore pump prototype properties.
  
• Added "final-health" to the entity-damaged event.
  
• Added "final-health" to the entity-damaged event filter.
  
• Added LuaGameScript::max_force_distraction_distance, max_force_distraction_chunk_distance, max_electric_pole_supply_area_distance, max_electric_pole_connection_distance, max_beacon_supply_area_distance, max_gate_activation_distance, max_inserter_reach_distance, max_pipe_to_ground_distance, max_underground_belt_distance read.
  
• Added LuaEntity::deplete().
  

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.

Since the particle optimization we did for 0.18 (FFF-322) and the introduction of new explosions (FFF-325), we were able to push our vision even more.

It always bothered me that the grenade and other explosions would emit the same type of particles regardless of the context. In most cases it isn't that bad, and somewhat okay, but when you throw a grenade into water, it will still emit stone particles, which breaks the illusion.

Another problem is that we have the nice decoratives on the ground, but they don't really 'interact' with anything that goes on, and can feel like fake flat stickers instead of something 'real'. You would expect that when there is a massive explosion 2ft away, the bushes might have some reaction to that.

https://cdn.factorio.com/assets/img/blog/fff-343-grenade-old.mp4
The explosion effect currently in 0.18

One thing we wanted was some way for tiles to respond to the explosions in different ways. The way Posila decided to add this capability, is through the 'Invoke tile effect trigger'. Tiles can define an effect that happens, and the explosion will tell the tile to create that action. After the implementation of this feature, it was smooth sailing from there. I was able to design the explosions like I wanted them, to be emitting specific particles based on their tiles. For example besides the visual improvement of the stone emissions in water, I was able to make the hazard concrete emit dark grey and yellow particles.

https://cdn.factorio.com/assets/img/blog/fff-343-mosaic.mp4

We kept in mind that people might want to tint all the new particles for mods, so we kept everything as tint-able as possible. So a modder can just use our particle definitions and tweak the tints, for instance, if they want to add purple terrain. It's worth mentioning that the same goes for almost all the new particles (metal/stone/vegetation/blood/glass etc). Using the same sprites with different tints also helps us save some VRAM, as the game applies the tint during the render phase.

Posila also added the engine changes required to remove decoratives on impact, and for the decoratives themselves to create some particles on their destruction. This makes it feel much better when you see the explosion, because you see the decoratives reacting as if they were real, and it does not break the immersion in the game. It also helps to make the explosions feel a bit more powerful, at least powerful enough to blow over a bush.

https://cdn.factorio.com/assets/img/blog/fff-343-grenade-new.mp4
The new grenade explosion, showing the new tile effect and decorative effects.

The reactions are also based on the individual decoratives. So each individual decorative will emit a different set of particles, bushes will emit grassy vegetation particles, stones will emit stone particles, etc. We also use the same tinting system here, so a brown bush and green bush will have the same particle sprites, just tinted accordingly.

There is of course the nice benefit of this to a lot of players, now that grenades can clear the decoratives, you can do some explosive cleaning of your precious prestine factory floors.

https://cdn.factorio.com/assets/img/blog/fff-343-clearing-decoratives.mp4
A player clearing decoratives off their precious pathway

Bilka has spent quite some time in the last month working on a new 'mod' for the game. Well its more of a mod that allows the removal of the 'Base' mod.

It has always been technically possible to run Factorio without the Base mod enabled, but anytime you would try you'd be hit by a bunch of missing prototype messages. Basically the game needs to have some minimum amount of prototypes defined to be able to launch properly.

So Bilka's work will act as a foundation for other mods to build on, to help modders make true 'total conversion' mods, or just have fun with the raw Factorio engine. Of course enabling this mod and starting the game isn't very fun on its own.


Factorio, but there is no content

For more details, please check out the detailed forum post by Bilka, and you can find the project repository here.

Read this post on our website.


As stated in previous FFF's we will be making some changes to the demo and tutorial content in the game. I wanted to clarify exactly what is being removed and what it is being replaced with, as this content is almost ready for release. If you would like to catch up on the topic, you can read Kovarex's piece in FFF-327, but I will also summarize it here.

Right now the NPE/Introduction is the scenario that is used as the demo (0.17) and as the tutorial in the full game (0.17 stable, 0.18 experimental). If anyone has played the tutorial in the last 12 months, this is probably what you have played.

The First steps campaign was a series of three levels which used to make up the demo and tutorial in 0.16 and earlier. They were introduced in 2014. We have been working on revamping these levels to bring them up to 0.18 standards.

Very soon the NPE/Introduction will be removed and the First Steps campaign will be reinstated, both as the full game tutorial and the demo.

The plan was to change these levels as little as possible while updating them to modern Factorio standards. That is harder than it sounds given these levels were created in 2014.

As stated in FFF-241, there were many things we felt were inconsistent in the First Steps campaign. One of the largest ones was that there were many different and confused channels of information. The newer version has given each channel a purpose and a format.

The most distracting, and the most popular was the character monologues. Some of the messages in each channel were written in the first person, as if the character is talking to themselves. All the instances of this occurring in the Yellow speech bubbles and objective panel are gone or moved to the console. The rule here is that nothing that is actually necessary should come via this channel. To communicate to the player that this is story text, I added a speaker prefix.



The most necessary and most annoying channel was the Yellow speech bubbles. There are situations where it is absolutely necessary to pause the game and tell the player something. Since we have no other technology designed for this purpose, I just resorted to removing as many of them as possible. They only appear where necessary, although I would still like to get rid of more of them.

The final channel is the Objective window. The rule here is, if the player tabbed through all the speech bubbles without looking, and did not read the story text, they should still be able to finish the level. The text should not be in the first person, and we can speak directly to the player.

Due to much more rigorous and dedicated internal testing (Boskid), we caught a lot of corner cases where players can become stuck. The tutorials also now take into account new and updated game features. For example, previously the pickaxe was used to demonstrate crafting, so some extra attention had to be paid to when the player crafts the stone furnace for the first time.

The maps have been updated to look much more like what the random generator creates in freeplay. The new remnants make a great impression here.



Now that the quickbar does not automatically populate, we had to be more careful about when the player has their inventory open. The new standard for new players is: open inventory, take item, close inventory, place item, open inventory, place remaining items, close inventory. Giving new players the option to add quickbar links as early as possible is a challenge because every time you add a new concept, the player must expend some of their attention keeping it in mind. Not only that, but using the quickbar actually removes a perfect opportunity for the new player to practice interacting with the inventory.
Kovarex discussed his reasoning in FFF-327, but a lot of people asked me for more information to help them understand. Post mortems are uncomfortable but necessary so I will try to summarize his point and add one of my own.

The NPE/Introduction was created to widen the audience of Factorio. It takes new players a long time to get into the game and many stop playing before 'getting it'. The strategy was to show new players (both in the demo and tutorial) more of the mid game. After finishing the scenario Kovarex realised that the experience was not in line with his vision for the game.

When he told me how he felt, I think he was surprised that I agreed with his decision to remove it. Vision alignment is very important, especially in a demonstrator product. It isn't something you can just 'fix' when the project is almost finished.

This is not to say that the NPE/Introduction failed in its goals. It did appeal to a wider audience and player feedback at the end of development was overwhelmingly positive. I received a lot of feedback from genuine first time demo players pledging to buy the game immediately and also from story focused, non-sandbox players who were craving more. But as Kovarex said in his FFF, the cost of this was too high.

In light of the full length campaign being cancelled (see V453000s part in FFF-331), this is the biggest reason why I think the NPE/Introduction would have failed as a demo. We would have been offering an experience in the demo which was targeted to a wide audience, but the quest loving players were not going to get any extra content if they buy the game. A literal "It isn't what it says on the tin" situation.

A full post mortem would be much longer than this, and I would have liked to discuss much more about the things that went right. On the up side, a lot was learned from this project and that can only make the game better in the future.
The new old First steps tutorial is almost ready for release, we are still doing some general polishing and internal testing, and if all goes to plan, it will be released within the next few weeks. However that doesn't mean the work is necessarily finished, as no doubt we will need to tweak, polish and fix a lot more things as player feedback starts rolling in.

Alongside this addition, we will also be removing the NPE, and doing a general cleanup of the now unneeded data changes. This may affect some mods which have dependencies on some new campaign assets. We might leave some assets in if they are significant enough (for instance the Compilatron), so if you are a modder and something in the NPE is of special interest to you, please let us know.

• 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
  

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

• Added confirmation box for deleting blueprint book.
  

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

• 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
  

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

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

Read this post on our website.

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.

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 <tt>working_sound</tt> in combination with the <tt>max_sounds_per_type</tt> 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 <tt>max_sounds_per_type</tt> and added a <tt>audible_distance_modifier</tt> 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.