Read this post on our website.

It's been over 4 years since we planned the infamous GUI update. If all goes well, next week the game will get the last big GUI update for 1.0. While the state of the GUI is not close to our crazy plans we recently had for the GUI, it's above what we initially planned 4 years ago.

The update you will see next week includes:

• A visual update to over 100 game GUIs
• New high resolution icons for all game items (visible both in GUI and in the world)
• New GUI sounds for most interactions

A bit more than a year ago Albert had posted twice (FFF-290 and FFF-291) about our thoughts, experiments, and plans of creating high resolution icons.

Factorio has a ridiculous amount of items and things that need icons, which by itself means it’s a lot of work to redo them. I did not work on the new icons non-stop for a year as there were other more pressing tasks to be done sometimes, but they still took a large amount of time to make.

As Albert mentioned earlier, we also wanted to create multiple mipmaps per icon to control scaling better than letting the engine rescale icons by crazy amounts, but it could multiply the amount of required images to astronomic numbers...


Since we were very well aware of the amount of work that the icons would require, we tried to set up an efficient workflow first, and it paid off big time.



A rather simple Blender startup scene to standardize output paths and basic starting settings was a good start, but the part that saved my sanity was a python script which automatically creates mipmaps from given input images, and downscales images from nearest available higher resolution if an input is missing. And automatically puts the mipmap into the game, assuming the file names are correct.



This is huge because it means I could create the highest resolution image first and immediately put it in the game, and see if conceptually the icon is working.Once I would consider the highest resolution good enough, I could just downscale each of the resolutions manually in Photoshop and paint the extra necessary edits they would require.



The best part is that the mipmaps were not really extra work, they were actually a lifesaver. Creating a high resolution icon that is trying to be readable, look good, represent what it should and do all of it in any scaling level, can make iteration really difficult, as by changing a pixel in the image can introduce problems in completely unknown zoom levels.

It feels rewarding for "trying to do things right" when a solution that we initially thought is more proper looking but potentially more work, is actually more proper looking and less work in the end.






Some icons have been around for years and the entities they represented have changed, but the icons have not. Because of this and many other reasons, some icons will take some getting used to as they look different now. As a benefit of working on the icons on and off for more than a year, I also got to play the game with them over the year and I have gotten used to them already.

Click to view full resolution

Since we have updated our GUI to draw in high resolution with GUI scales like 200%, the item icons suddenly have too low resolution, so we needed to update the icons. That’s what I was thinking at first, but as I started seeing high resolution icons in the game (on belts, assembling machines, cargo wagons, in the map markers, and everywhere else...) I realized how much impact the new icons actually have.

Please do try to get used to the more revolutionary icons first, but do let us know about problematic cases - reworking all icons is a gargantuan project, but redoing individual icons can be very quick and done silently without breaking any mods. That’s what we’ve been doing in almost every major release after all.
​

As mentioned in FFF-338, the plan was to 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. While it didn]
In game you will notice that some layouts (such as logistic containers) were improved, broken layouts (such as the car/tank inventory) were fixed, plus about a hundred small things like better tilesets, better margins and paddings, proper centering of some elements, etc. Here are some examples of what you will see.



About the fact that we took 4 years, it's partly because (as is probably quite common in game dev) we underestimated the complexity of the GUI. Add on top of that some disorganisation and a constantly expanding and changing scope and you get a project that never finishes. So finally I decided to put my foot down, call it good enough and say no to the constant stream of changes.

That means it's not all good news. It doesn't look like the Blueprint Library will be getting an update before 1.0, currently making it a very low hanging fruit as far as the GUI is concerned.

Such a big update comes with some mod breaking changes, mostly related to changed Lua styles. In order to help modders in fixing the mods as soon as possible and also improving their styles to make them look closer to the base game, I made a long post in the . We initially intended to remove the old ]After it's released, let us know what you think in the release post, or report any bugs you find on the [url]bug forum.
​

In the meantime, Ondra worked on some improvements to the equipment grid. As part of the icon update, this also includes some new graphics for the equipment sprites themselves.




As I mentioned in a recent post (FFF-341), I have been mostly working on UI sounds. My approach has been to get across the tactile feel of the buttons, plus the appropriate feedback for a particular action. But sometimes you don't really know until the rest of the team have heard them.

https://cdn.factorio.com/assets/img/blog/fff-348-gui-sounds.mp4

After prototyping ghost building for example, I thought I had a set of sounds that worked, however Vaclav gave me the valuable feedback that they were too much like 'in world' SFX and needed to be more electronic. This makes sense, as building with ghosts is really sending an instruction to the robots. We also have sounds for rotating entities, which is something you asked for. It provides a bit of useful and fun feedback which could be helpful if you hit the 'R' key by mistake when you meant to open your inventory.

https://cdn.factorio.com/assets/img/blog/fff-348-ui-sounds.mp4

In the case of night vision equipment, I started by making a subtle whoosh type sound but Klonan suggested something more like the 'wind up' sound in Splinter Cell, so I made a kind of a homage to that using a mixture of a rising synth sound and an electrical contact effect.

https://cdn.factorio.com/assets/img/blog/fff-348-nightvision.mp4

I asked Posila if we could play a different building sound for landfill. Once this was done I spent a whole day creating and play testing a variety of sounds, being careful to balance the levels between the impacts and the subtle water splash behind it. I felt they work so well that when Vaclav asked me to look into changing the concrete tile sounds, I used a similar approach and that mechanic also feels much more satisfying now.

https://cdn.factorio.com/assets/img/blog/fff-348-landfill.mp4

Val has been working on more variety for the different sizes of enemies, plus some new sounds for walking on rails. From now on it will be mostly final mix adjustments, including final music mastering and making the whole soundtrack uniformly a bit louder.


Back in FFF-303, we talked about our thoughts on the grey market websites and more specifically about G2As vow to pay back 10x the money lost to chargebacks.

Well its been a long time, but we're happy to say we have reached the conclusion of the story. You can read the press release from G2A here and the interview with GamesIndustry.biz here.

In short, G2A has confirmed that 198 of the ~300 Steam keys we had recorded from fraudulent purchases were sold on the G2A platform, and they have kept their promise and have sent us 10x the chargeback fees (which was roundabout $20 an order).

That is pretty much it. G2A were quite open during the discussions, and we don't doubt the results they have provided. We still don't recommend purchasing Factorio from any unofficial sources, and there is no ongoing relationship or agreement with G2A after this.

I'd like to thank the team members at G2A who put in the effort to try to close this topic, even though there are more pressing concerns at the moment for all of us.

• Added new tutorial campaign levels 04 and 05. (more)
  

• Added a search bar to the mod settings GUI.
  

• Fixed a crash when building entity ghosts that immediately get invalidated through script.
  
• Fixed that the choose-elem-button elem_type "signal" didn't show special signals. more
  
• Fixed that furnaces required module slots to be effected by beacons. more
  
• Fixed that some select-a-thing GUIs didn't have search bars. more
  
• Fixed that LuaEntity::revive({raise_revive=false}) would still raise the revive event.
  
• Fixed a crash when trying to iterate game.forces with the maximum number of forces created. more
  
• Fixed a desync related to fast-replacing modded beacons. more
  
• Fixed performance issue with initializing huge Lua arrays, that could cause loading of some modded saves take forever. more
  

• Added item prototype flag "draw-logistic-overlay".
  
• Added support to play a sound when a robot deconstructs something through utility-constants "deconstruct_robot".
  

• Added on_force_reset event called when LuaForce::reset() is run.
  
• Added remove_colliding_entities and remove_colliding_decoratives parameters to LuaSurface::set_tiles().
  
• Added LuaSurface::get_script_area, edit_script_area, add_script_area, remove_script_area, get_script_position, edit_script_position, add_script_position, remove_script_position.
  
• Added 'elem_filters' onto choose-elem-button LuaGuiElements to control what options appear in the picker GUI.
  
• Added 'crafting-category' filter to EntityPrototypeFilters.
  
• Added 'has-ingredient-fluid', 'has-ingredient-item', 'has-product-fluid', 'has-product-item' filters to RecipePrototypeFilters which can accept a nested set of FluidPrototypeFilters or ItemPrototypeFilters.
  
• Added 'place-result', 'burnt-result', 'place-as-tile', 'placed-as-equipment-result' filters to EntityPrototypeFilters which can each accept a nested set filters.
  
• Added 'name' filter to EntityPrototypeFilters, FluidPrototypeFilters, and ItemPrototypeFilters which accepts either a single name or a list of names to accept, similar to LuaSurface::find_entities_filtered.
  

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.

A few weeks ago we discussed the changes to the demo and tutorial in the game (FFF-342). One piece of feedback we received after publishing the news was about the old 'New hope' campaign levels, and specifically the 'Abandoned rail base/Broken rail map'.

It seems a lot of you in the community really really enjoyed the new hope campaign levels, and several of the team here share the same feelings. After we scrapped the plans for a new campaign and reverted to the old demo, we had initially dismissed the idea to revive the New hope campaign...

However due to popular demand... we have decided to bring back the favourites, the first 2 levels of the new hope campaign. This time though, they will also be included in the demo version of the game. This represents a very significant increase in scope for the demo, increasing the demo content to include research, red science, green science, trains, and much more.

These levels should be ready for release within a week (but no promises).

This mission is a continuation of demo mission 03 where you build radars to scan the surrounding areas. You start with a small factory already operational. The radar detects a distress beacon and you must build a car to get there in time before the signal dissipates. This level introduces the labs and science packs, as well as providing the first taste of real automation.



At the end of the level, you pack your supplies in the car, and drive off to locate the distress beacon, before it fades out for good.
This level starts with you pulling up to the base, however you arrived too late and the base is already destroyed. Your goal is to re-establish the science production and rebuild the rail network.



After rebuilding the railway and the mining outposts, you must produce a large number of materials to finish the level. At the end of the level, there is a notice that this is the end, and we would recommend playing Freeplay next.
The main work over the last weeks has been bringing the ancient maps up to date with modern Factorio. For instance now that we have more specific remnants, the ruined bases really look much nicer.



Also we have made a big effort to update the tile and map generation to make use of the new terrains, cliifs, and decoratives, most effectively...

The original Abandoned rail base level was nice, but it aged with all the changes to terrain generation that happened since.



The goal is to recreate the gameplay of the original level, but replace the terrain with modern one, including decoratives and cliffs.

The most gameplay-defining elements are entities and water on the map. Cliffs would be as well, but those didn’t exist when this level was introduced.

Tiles and decoratives we’ll just replace, and trees we’re going to try to get close enough. Of course, a lot of things like pollution absorption numbers have changed since the level was introduced so it won’t be absolutely the same regardless.



The first step I took was finding the random map seed that I want to use for the level. I do this by generating a random map in Freeplay, and I run a take_screenshot command, with two requirements:

• The name of the output image is the seed of the map so I can reproduce the image just by reading the image name.
  
• The resolution to 1 pixel = 1 tile so I can easily align it in Photoshop and read the coordinates (even though Photoshop uses a different coordinate system, at least staying in the same units helps).

I take the same resolution screenshots from the original mission with and without tiles, and put the random seed images on top.

Having the visual preview with being able to move the image allows me to find the desired seed and offset quite quickly and position it really precisely.

Now of course we can’t just paste the entities from the original level to this random surface as there are some conflicting areas, like the huge lake in the middle of the map.



So we have to remove unwanted lakes and resource patches.This is done by generating multiple maps with the same seed, but one without water (starting area only) and resources, and transferring areas between them.

Next up we can add water from the original level.



This step is quite special, in the original mission I replaced water by concrete, and created a blueprint from it. There’s better ways I could have done this, but for some reason I didn’t want to deal with offsets in this piece of script, and I’ve already used this method in some other place earlier so this solution came to my mind first.




Another script replaces all the concrete with real water. The bigger issue is that the original level had water all the way to the edge of the map (you can for example see the sharp edge on the right) and the water generation changed as well so manual edits are in order.



When we have water, it’s finally time to clone in the original entities.



To avoid conflicts, I use the clone_area tool which also removes entities in the destination surface. I’ve been able to go through this whole process in a single working day thanks to all the map editor features Rseding added and Lua commands we’ve created when working on the now cancelled campaign. Tools, experience and knowledge are hard to cancel. :)



And then we draw the rest of the owl. Fix places where the automated cloning hasn’t been good enough, add more ruins to be explored, tweak the gameplay and we will have a finished scenario.

Recently we made some improvements to the cliff explosive effects. However one thing we missed was that the bots needed to be updated separately, due to them using different logic to create the explosion. While it was an easy fix (copy paste some Lua definitions), it feels like it is treating the symptom rather than treating the cause. It isn't good to have the same thing defined in two separate places.

So never one to pass up a nice opportunity to have some fun, Rseding changed the way the 'Blow up cliff' job works, so it will always use the correct effect:

https://cdn.factorio.com/assets/img/blog/fff-347-robot-throw.mp4

Now instead of the robot hovering over the cliff, it will throw the same cliff explosive projectile as the player would. Not only this fixed the issue for good, but it looks a lot cooler.

• Added player footprints and footstep visual effects.
  
• Added car and tank dust and particle trail visual effects.
  

• Construction robots throw cliff explosives from afar the same as players do, instead of dropping them at the cliff.
  
• Changed rail segment visualisation colors to be more different from rail signal colors (red/green).
  
• Clicking a GUI now brings it to the front. Most noticeable when using the map editor or debug GUIs where they overlap.
  

• Fixed that Fast splitters were missing a piece visually in East rotation top_patch more
  
• Fixed that inserters could insert modules for recipes into module slots in some rare cases. more
  
• Fixed that robots blowing up cliffs was different than manually blowing up cliffs. more
  
• Fixed limiting cargo wagon to 0 slots would break progress visualization for full cargo and empty cargo train conditions. more
  
• Fixed teleporting player between surfaces while the player was in a map view would not invalidate tile renderer cache. more
  
• Fixed that the "use different settings per save" setting didn't work for single player games. more
  
• Fixed crash due to use-after-delete when single unit builds a base in position that does not collide with the unit. more
  

• Added the Prototypes GUI (ctrl + shift + E).
  
• Added the Prototype Explorer GUI (mouse over most anything + ctrl + shift + F).
  
• Added support to play different sounds for entity ghosts depending on the size of the entity in the ghost through build_sound (for small), medium_build_sound and large_build_sound on the entity ghost prototype.
  
• Added support to play a sound when switching weapons defined through utility-sounds 'switch_gun'.
  
• Added support to play a sound when picking up items (F key) through utility-sounds 'picked_up_item'.
  
• Added optional 'turn_speed' to projectile prototypes.
  

• Added "include_fuel" field to LuaItemStack::create_blueprint.
  
• Changed LuaSurface::create_entity so it places resource entities to center of a tile as map generator would. This can be overridden by optional snap_to_tile_center parameter. more
  

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.

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.