• Added support to load save files directly in the map editor.
  
• Added "Save and play" button to map editor, to allow quick iteration.
  
• Added levels in campaigns to level editor "open" menu.
  

• Requesters requesting from buffer chests (which includes players) have higher priority than other requesters.
  
• Player death messages will be printed to all forces they are friends with.
  
• Player death messages include the player tag.
  

• The left/right switch used in locomotive and splitter can be also switched by clicking the label buttons.
  

• Fixed teleporting pumps would crash the game. more
  
• Fixed dragging in the map preview and technology GUI didn't work correctly. more
  
• Fixed walls wouldn't connect correctly when built through script in some cases. more
  
• Fixed that the equipment grid was too small when using extra-low graphics quality. more
  
• Fixed inserters could get stuck trying to pick up items off the ground in some cases. more
  
• Fixed issues related to splitter priorities. more
  
• Fixed that the "recursive technology prerequisites detected" error message wouldn't print the dependency cycle properly. more
  
• Fixed (and hopefully generally improved) the splitter GUI so invalid states are not possible. more
  
• Fixed that biters would not be able to path find close to cliffs. more
  
• Fixed mod control settings would be wiped out when game entered minimal mod due to mod error on start up. more
  
• Fixed that the tips-and-tricks GUI would open when running a replay. more
  
• Fixed that the blueprint setup GUI wouldn't show in some situations. more
  
• Fixed that the asynchronous saving process could freeze in headless mode. more
  
• Fixed crash in PvP when distance between starting areas was too low. more
  
• Fixed small locale error in resource entity info. more
  
• Fixed crash when player deletes blueprint book from their library while other player has the book opened. more
  
• Fixed that custom scroll panes didn't respect vertical scroll policy correctly. more
  
• Fixed a crash in the technology GUI when using LuaForce::disable_all_prototypes(). more
  
• Adjusted collision boxes of decals to reduce chance a decal will be generated in position colliding with water. more
  
• Fixed that the recipe tooltip "made in" wouldn't show every possible machine when there was a lot of them. more
  
• Fixed ghost of lamp would not connect to logistic network when revived. more
  
• Fixed that the command line --map2scenario option wouldn't convert scenario-created saves correctly. more
  
• Fixed handling of mouse bindings in map view. more
  
• Fixed that you could get stuck after using cliff explosives. more
  
• Fixed biters getting stuck next to a wall in some situations. more
  

• Added optional create_ghost_on_death for entities with health that normally make ghosts on dying.
  
• Added optional always_show_made_in to recipe prototypes.
  

• Added last_research to the on_research_started event.
  
• Added LuaEntityPrototype::energy_per_hit_point read.
  
• Added LuaEntityPrototype::create_ghost_on_death read.
  
• Added CustomMinimap GUI element type.
  
• Added CustomEntityPreview GUI element type.
  
• Added LuaInventory::sort_and_merge().
  
• Added an optional "invert" option to LuaSurface::find/count entities filtered.
  
• Added LuaForce::enable_all_prototypes().
  
• Added LuaRecipePrototype::always_show_made_in read.
  
• Added LuaControl::get_main_inventory().
  
• Added LuaGuiElement::column_count read.
  
• Changed util.merge to always deepcopy nested tables. more
  
• Changed events so they won't fire until every mod has had on_init ran.
  

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

• Added support to load save files directly in the map editor.
  
• Added "Save and play" button to map editor, to allow quick iteration.
  
• Added levels in campaigns to level editor "open" menu.
  

• Requesters requesting from buffer chests (which includes players) have higher priority than other requesters.
  
• Player death messages will be printed to all forces they are friends with.
  
• Player death messages include the player tag.
  

• The left/right switch used in locomotive and splitter can be also switched by clicking the label buttons.
  

• Fixed teleporting pumps would crash the game. more
  
• Fixed dragging in the map preview and technology GUI didn't work correctly. more
  
• Fixed walls wouldn't connect correctly when built through script in some cases. more
  
• Fixed that the equipment grid was too small when using extra-low graphics quality. more
  
• Fixed inserters could get stuck trying to pick up items off the ground in some cases. more
  
• Fixed issues related to splitter priorities. more
  
• Fixed that the "recursive technology prerequisites detected" error message wouldn't print the dependency cycle properly. more
  
• Fixed (and hopefully generally improved) the splitter GUI so invalid states are not possible. more
  
• Fixed that biters would not be able to path find close to cliffs. more
  
• Fixed mod control settings would be wiped out when game entered minimal mod due to mod error on start up. more
  
• Fixed that the tips-and-tricks GUI would open when running a replay. more
  
• Fixed that the blueprint setup GUI wouldn't show in some situations. more
  
• Fixed that the asynchronous saving process could freeze in headless mode. more
  
• Fixed crash in PvP when distance between starting areas was too low. more
  
• Fixed small locale error in resource entity info. more
  
• Fixed crash when player deletes blueprint book from their library while other player has the book opened. more
  
• Fixed that custom scroll panes didn't respect vertical scroll policy correctly. more
  
• Fixed a crash in the technology GUI when using LuaForce::disable_all_prototypes(). more
  
• Adjusted collision boxes of decals to reduce chance a decal will be generated in position colliding with water. more
  
• Fixed that the recipe tooltip "made in" wouldn't show every possible machine when there was a lot of them. more
  
• Fixed ghost of lamp would not connect to logistic network when revived. more
  
• Fixed that the command line --map2scenario option wouldn't convert scenario-created saves correctly. more
  
• Fixed handling of mouse bindings in map view. more
  
• Fixed that you could get stuck after using cliff explosives. more
  
• Fixed biters getting stuck next to a wall in some situations. more
  

• Added optional create_ghost_on_death for entities with health that normally make ghosts on dying.
  
• Added optional always_show_made_in to recipe prototypes.
  

• Added last_research to the on_research_started event.
  
• Added LuaEntityPrototype::energy_per_hit_point read.
  
• Added LuaEntityPrototype::create_ghost_on_death read.
  
• Added CustomMinimap GUI element type.
  
• Added CustomEntityPreview GUI element type.
  
• Added LuaInventory::sort_and_merge().
  
• Added an optional "invert" option to LuaSurface::find/count entities filtered.
  
• Added LuaForce::enable_all_prototypes().
  
• Added LuaRecipePrototype::always_show_made_in read.
  
• Added LuaControl::get_main_inventory().
  
• Added LuaGuiElement::column_count read.
  
• Changed util.merge to always deepcopy nested tables. more
  
• Changed events so they won't fire until every mod has had on_init ran.
  

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

• Fixed another compression problem on belts related to splitters.
  
• Fixed that the cancel craft, import blueprint and blueprint book buttons didn't work.
  
• Fixed biter related desyncs. more
  
• Fixed possible desync related to logistic network.
  

• Renamed render_layers: ground_patch, ground_patch_higher, ground_patch_higher2, and air-entity-info-con to ground-patch, ground-patch-higher, ground-patch-higher2, and air-entity-info-icon.
  

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

• Fixed another compression problem on belts related to splitters.
  
• Fixed that the cancel craft, import blueprint and blueprint book buttons didn't work.
  
• Fixed biter related desyncs. more
  
• Fixed possible desync related to logistic network.
  

• Renamed render_layers: ground_patch, ground_patch_higher, ground_patch_higher2, and air-entity-info-con to ground-patch, ground-patch-higher, ground-patch-higher2, and air-entity-info-icon.
  

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

Hello, another week has passed here, with part of the team still out in Taiwan. They should be back next week, with some news of their great adventure.

With the addition of high resolution sprites we have started pushing memory limits of GPUs much harder than we originally anticipated. Currently the game requires about 2.4 GB of VRAM for sprites alone, and then it can use couple hundred megabytes more for working buffers and minimap data.

While trying to optimize rendering we learned that the issue is quite complicated, as one optimization could improve performance on one PC, and worsen it on another PC even with a similar hardware configuration. For this reason we usually make it possible to turn these optimizations on or off in graphics options.

Since the beginning, Factorio was using so called sprite atlases - which are big textures with lot of individual sprites packed into them. The advantage of using them is that we can batch rendering of sprites that are in the same atlas, and reduce the total CPU overhead of creating many draw commands for the GPU. A disadvantage is that it might be harder for the graphics driver to fit this single large texture into VRAM, as opposed to a lot of small ones.

Since high resolution sprites don’t fit into the single largest supported atlas size any more, we started to sort them into logical atlases - things that are drawn usually together are put into the same atlas. So terrain tiles, shadows, GUI graphics, icons, and recently objects that are drawn under shadows, are all separated into their own atlases. This way we can keep most of the sprite batching intact, while overall enabling us to add a greater number of larger sprites.

Another problem we can solve is related to texture sampling. When you zoom out a lot, an entity which was 256 pixels wide could be only 32 pixels wide, which means only every 8th pixel from the source sprite is drawn. This can have be problem for the GPU’s texture cache, and can cause a significant framerate drop when zooming out. To solve this, we can enable mipmaps, which are pre-downsized versions of textures, from which the GPU will select the size that is the most appropriate for current scaling factor. This is what we did for trees in 0.14 and now for terrain and decoratives in 0.16. The disadvantage is that mipmaps take up extra VRAM, and sprites can’t be as tightly packed in the atlas because they would start to ‘bleed’ into each other in the downscaled versions.

With the ever increasing amount of high-resolution textures, we have some plans to implement some stronger VRAM optimizations later on. We will have some news on these as we develop them, but one way which coincides nicely with the high-resolution update, is the splitting of sprites from their shadows.

Right now trees are kept as single sprites, with the tree and tree shadow combined. We originally thought this would be a benefit, as it would reduce the number of sprites the game has to render by half, but in the case of trees, this leads to a lot of empty space in the sprite image:



The entire orange portion is just empty pixels that the GPU has to waste time sampling, which can be quite wasteful when there are hundreds of trees partially overlapping. A second downside is that they will take a larger amount of space in the sprite atlas, meaning a greater VRAM usage.

Splitting the shadow from the sprite also has some side effects, due to the overlapping shadow sprites all being merged before being rendered. This means there will no longer be the deep black areas where the old tree shadows would layer on each other. There is some further reading on shadow rendering in FFF-42.



This helps the terrain fit more naturally with the trees, and helps keep the darkness of the shadow consistent with the other entities. But has some downsides.



By removing the deep black areas, the resulting scene tends to look more flat, and our eyes see the colors as more washed out, even though they are the same on both sides. We can counter this problem by adding deeper shadows to the sprite itself, but this only works for trees using volumetric leaves, so we are reworking all the trees to work with this new system.



As it turns out, not so many people know that we package quite a few scenarios with the game. Personally I like scenarios because allow us to explore aspects Factorio gameplay in a more focused way. While generally we aim to make a fulfilling freeplay experience, we are always looking for other interesting ideas that work within the game. If you have no idea what I am talking about, look here:



The most interesting to me, is exploring the nature of competitive Factorio. This doesn't necessarily mean fighting killing each other toxic cut-throat competition, but giving that heart-racing high-pace action that you don't really find in the rest of the game.

Already we have two scenarios with a competitive nature:

• Team production - Teams are given a small area to work in, and a random task to fulfil.
• PvP - Allows setting up multiple teams with a wide variety of customizability and setup preferences.

Having written and played both of these quite extensively, I have some experience in what they 'feel' like. Honestly the fact you are working against other players in a meaningful way, really does give something the freeplay doesn't. Team production has the 'hit the floor running' pace that really feels pretty nice, there is this real rush to get the furnaces down and the smelters smelting before the other teams. Since PvP has a lot of setup options and game modes to pick, how it plays can vary a lot, but in general the concept leads to some great player interactions. Perhaps the name is a misnomer in this way, but PvP scenario can also be used to set up allied teams, just playing together with separate bases and technology progression, so it isn't always combat/competitive focused.

Honestly over the last few years of playing, especially on medium to large game servers, I find the freeplay Factorio experience quite calm and relaxing, almost a little boring at some points. I am not saying I have seen it all, but there is not so much thrill to this side of the game to me any longer. For me at least, scenarios let me employ the best parts of the games design, in a way that brings back the challenge and interesting gameplay decisions.

I am also thinking of starting an 'official' Factorio MP server, so we can showcase these scenarios with some planned events. There are a few questions related to this, and scenarios in general, that I would like to put forward:

• Do you have any ideas for new scenarios, or improvements to the current ones?
• What sort of scenarios and events would you like to see and/or take part in?
• Do you think developing a competitive aspect to Factorio will benefit us in the long run?

I recently added a new game mode to the PvP scenario: Production score. The concept is simple enough, you will earn points for the amount of items your factory produces, and teams will compete to earn the most points. In general I think it is quite nice, as teams can compete somewhat indirectly with one another, and victory isn't solely dependant on military power.

Part of the result of this, is that the price generator I developed can be used for other things. It is done in a general way so it will dynamically calculate new prices when mods and other things are considered, and we can use it to make nice graphs such as the following:



Speaking of scenarios, I often see some issue raised that there is no easy way to share and install scenarios. Really that is quite true for stand alone scenarios, as you will need to copy the folder into some other scenario folder which might not exist in the user directory, or you can join a server hosting the scenario already and a copy will be saved locally. These are both quite messy and unviable methods.

Thankfully there is a very easy solution, and that is to pack your scenario into a mod. This essentially solves the problem of scenario distribution, and makes it as simple as adding any other community addition to the game. There is also the system, that mods that include only locale, campaigns and scenarios, are marked as 'non-game changing'. Since it doesn't affect the state of the game, the mod is completely ignored when dealing with mod syncing, and you won't have to worry about having the mod installed or not when joining any servers.

As an example of how it can be done, I have packaged one of my pet projects as a mod, so you can see how easy it is to package scenarios into mods: Factory floor.

As always, let us know what you think on our forum.

Hello, another week has passed here, with part of the team still out in Taiwan. They should be back next week, with some news of their great adventure.

With the addition of high resolution sprites we have started pushing memory limits of GPUs much harder than we originally anticipated. Currently the game requires about 2.4 GB of VRAM for sprites alone, and then it can use couple hundred megabytes more for working buffers and minimap data.

While trying to optimize rendering we learned that the issue is quite complicated, as one optimization could improve performance on one PC, and worsen it on another PC even with a similar hardware configuration. For this reason we usually make it possible to turn these optimizations on or off in graphics options.

Since the beginning, Factorio was using so called sprite atlases - which are big textures with lot of individual sprites packed into them. The advantage of using them is that we can batch rendering of sprites that are in the same atlas, and reduce the total CPU overhead of creating many draw commands for the GPU. A disadvantage is that it might be harder for the graphics driver to fit this single large texture into VRAM, as opposed to a lot of small ones.

Since high resolution sprites don’t fit into the single largest supported atlas size any more, we started to sort them into logical atlases - things that are drawn usually together are put into the same atlas. So terrain tiles, shadows, GUI graphics, icons, and recently objects that are drawn under shadows, are all separated into their own atlases. This way we can keep most of the sprite batching intact, while overall enabling us to add a greater number of larger sprites.

Another problem we can solve is related to texture sampling. When you zoom out a lot, an entity which was 256 pixels wide could be only 32 pixels wide, which means only every 8th pixel from the source sprite is drawn. This can have be problem for the GPU’s texture cache, and can cause a significant framerate drop when zooming out. To solve this, we can enable mipmaps, which are pre-downsized versions of textures, from which the GPU will select the size that is the most appropriate for current scaling factor. This is what we did for trees in 0.14 and now for terrain and decoratives in 0.16. The disadvantage is that mipmaps take up extra VRAM, and sprites can’t be as tightly packed in the atlas because they would start to ‘bleed’ into each other in the downscaled versions.

With the ever increasing amount of high-resolution textures, we have some plans to implement some stronger VRAM optimizations later on. We will have some news on these as we develop them, but one way which coincides nicely with the high-resolution update, is the splitting of sprites from their shadows.

Right now trees are kept as single sprites, with the tree and tree shadow combined. We originally thought this would be a benefit, as it would reduce the number of sprites the game has to render by half, but in the case of trees, this leads to a lot of empty space in the sprite image:



The entire orange portion is just empty pixels that the GPU has to waste time sampling, which can be quite wasteful when there are hundreds of trees partially overlapping. A second downside is that they will take a larger amount of space in the sprite atlas, meaning a greater VRAM usage.

Splitting the shadow from the sprite also has some side effects, due to the overlapping shadow sprites all being merged before being rendered. This means there will no longer be the deep black areas where the old tree shadows would layer on each other. There is some further reading on shadow rendering in FFF-42.



This helps the terrain fit more naturally with the trees, and helps keep the darkness of the shadow consistent with the other entities. But has some downsides.



By removing the deep black areas, the resulting scene tends to look more flat, and our eyes see the colors as more washed out, even though they are the same on both sides. We can counter this problem by adding deeper shadows to the sprite itself, but this only works for trees using volumetric leaves, so we are reworking all the trees to work with this new system.



As it turns out, not so many people know that we package quite a few scenarios with the game. Personally I like scenarios because allow us to explore aspects Factorio gameplay in a more focused way. While generally we aim to make a fulfilling freeplay experience, we are always looking for other interesting ideas that work within the game. If you have no idea what I am talking about, look here:



The most interesting to me, is exploring the nature of competitive Factorio. This doesn't necessarily mean fighting killing each other toxic cut-throat competition, but giving that heart-racing high-pace action that you don't really find in the rest of the game.

Already we have two scenarios with a competitive nature:

• Team production - Teams are given a small area to work in, and a random task to fulfil.
• PvP - Allows setting up multiple teams with a wide variety of customizability and setup preferences.

Having written and played both of these quite extensively, I have some experience in what they 'feel' like. Honestly the fact you are working against other players in a meaningful way, really does give something the freeplay doesn't. Team production has the 'hit the floor running' pace that really feels pretty nice, there is this real rush to get the furnaces down and the smelters smelting before the other teams. Since PvP has a lot of setup options and game modes to pick, how it plays can vary a lot, but in general the concept leads to some great player interactions. Perhaps the name is a misnomer in this way, but PvP scenario can also be used to set up allied teams, just playing together with separate bases and technology progression, so it isn't always combat/competitive focused.

Honestly over the last few years of playing, especially on medium to large game servers, I find the freeplay Factorio experience quite calm and relaxing, almost a little boring at some points. I am not saying I have seen it all, but there is not so much thrill to this side of the game to me any longer. For me at least, scenarios let me employ the best parts of the games design, in a way that brings back the challenge and interesting gameplay decisions.

I am also thinking of starting an 'official' Factorio MP server, so we can showcase these scenarios with some planned events. There are a few questions related to this, and scenarios in general, that I would like to put forward:

• Do you have any ideas for new scenarios, or improvements to the current ones?
• What sort of scenarios and events would you like to see and/or take part in?
• Do you think developing a competitive aspect to Factorio will benefit us in the long run?

I recently added a new game mode to the PvP scenario: Production score. The concept is simple enough, you will earn points for the amount of items your factory produces, and teams will compete to earn the most points. In general I think it is quite nice, as teams can compete somewhat indirectly with one another, and victory isn't solely dependant on military power.

Part of the result of this, is that the price generator I developed can be used for other things. It is done in a general way so it will dynamically calculate new prices when mods and other things are considered, and we can use it to make nice graphs such as the following:



Speaking of scenarios, I often see some issue raised that there is no easy way to share and install scenarios. Really that is quite true for stand alone scenarios, as you will need to copy the folder into some other scenario folder which might not exist in the user directory, or you can join a server hosting the scenario already and a copy will be saved locally. These are both quite messy and unviable methods.

Thankfully there is a very easy solution, and that is to pack your scenario into a mod. This essentially solves the problem of scenario distribution, and makes it as simple as adding any other community addition to the game. There is also the system, that mods that include only locale, campaigns and scenarios, are marked as 'non-game changing'. Since it doesn't affect the state of the game, the mod is completely ignored when dealing with mod syncing, and you won't have to worry about having the mod installed or not when joining any servers.

As an example of how it can be done, I have packaged one of my pet projects as a mod, so you can see how easy it is to package scenarios into mods: Factory floor.

As always, let us know what you think on our forum.

• Added PvP options: Disband team on loss, team area artillery and give artillery remote.
  

• Fixed that the game allowed mining speed modifier less than -1, which resulted in negative mining speeds. more
  
• Fixed that fast-replacing power poles while running would just delete them. more
  
• Fixed that you couldn't exit vehicles with large collision boxes. more
  
• Fixed that LuaPlayer::can_insert and LuaPlayer::insert didn't agree. more
  
• Fixed game state corruption related to ordering deconstruction of entities with enabled connection to logistic network. more
  
• Fixed that teleporting roboports when robots where charging would lead to corrupt saves. more
  
• Fixed that toggle-console wouldn't work with modifier keys. more
  
• Fixed graphical artifacts in terrain when zoomed out. more
  
• Fixed that LuaForce::disable/enable research wouldn't update the GUI correctly. more
  
• Fixed that pumps would ignore fluidbox filter. more
  
• Fixed crash caused by non-ASCII characters in name of custom scenario. more
  
• Fixed that idle biters would ignore the player when approached. more
  

• Added support for setting icon_size per icon layer.
  

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

• Added PvP options: Disband team on loss, team area artillery and give artillery remote.
  

• Fixed that the game allowed mining speed modifier less than -1, which resulted in negative mining speeds. more
  
• Fixed that fast-replacing power poles while running would just delete them. more
  
• Fixed that you couldn't exit vehicles with large collision boxes. more
  
• Fixed that LuaPlayer::can_insert and LuaPlayer::insert didn't agree. more
  
• Fixed game state corruption related to ordering deconstruction of entities with enabled connection to logistic network. more
  
• Fixed that teleporting roboports when robots where charging would lead to corrupt saves. more
  
• Fixed that toggle-console wouldn't work with modifier keys. more
  
• Fixed graphical artifacts in terrain when zoomed out. more
  
• Fixed that LuaForce::disable/enable research wouldn't update the GUI correctly. more
  
• Fixed that pumps would ignore fluidbox filter. more
  
• Fixed crash caused by non-ASCII characters in name of custom scenario. more
  
• Fixed that idle biters would ignore the player when approached. more
  

• Added support for setting icon_size per icon layer.
  

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

• Fixed searching for recipes could add the "no recipe available" message multiple times. more
  
• Fixed a crash related to biters. more
  
• Fixed that setting locked = true on choose-elem-buttons through the mod API would still let the button be cleared. more
  
• Fixed logistic entity highlighting didn't work correctly in some cases. more
  
• Fixed that the map editor could get stuck if you built out-of-map tiles directly in the center of the screen. more
  
• Fixed Linux runtime requirements being dynamically linked. more
  
• Fixed (hopefully) macOS crash on startup due to 10.9 compatibility fix. more
  

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

• Fixed searching for recipes could add the "no recipe available" message multiple times. more
  
• Fixed a crash related to biters. more
  
• Fixed that setting locked = true on choose-elem-buttons through the mod API would still let the button be cleared. more
  
• Fixed logistic entity highlighting didn't work correctly in some cases. more
  
• Fixed that the map editor could get stuck if you built out-of-map tiles directly in the center of the screen. more
  
• Fixed Linux runtime requirements being dynamically linked. more
  
• Fixed (hopefully) macOS crash on startup due to 10.9 compatibility fix. more
  

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