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.

Read this post on our website.

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

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

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

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

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

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

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

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



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

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

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

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

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



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

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

Now this logic has been in the game since unit groups began, but it only became a problem more recently. In versions of Factorio 0.16 and before, a units max speed was always going to be based on its prototype, which does not change after the game is loaded. With version 0.17 we added 2 (really nice) mod capabilities:

• Allowing units to be affected by tiles;
• Allowing scripts to change unit speeds directly.

It didn't come up as a problem initially, as the freeplay base game doesn't really use these capabilities.

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

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

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

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

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

Read this post on our website.

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




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

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

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

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

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



In this early sketch the main concepts are already defined.

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

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

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

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

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

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



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


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

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



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

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



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


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

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

• The production statistics and electric network GUIs now have a new look.
  
• The kills GUI (K keyboard shortcut) has been removed. Kills statistics are now accessible as a tab in the production statistics GUI.
  

• Fixed an issue with nested items in items. more
  
• Fixed Character GUI missing logistics tab due to missing technology migration. more
  
• Fixed Character GUI recipes constantly scrolling up when crafting or when inventory changes. more
  
• Fixed that simple mouse click on double slider button would not set a slider as active. more
  
• Fixed that tabbing out of empty high value textfield of double slider would reset it to 0. more
  

• Removed the defines.gui_type.kills value from defines.gui_type.
  

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

• The character GUI now has a new look.
  
• Personal logistics has been moved to a separate tab. Logistic requests and auto trash have been merged into one panel.
  
• Using quick inventory transfers in the player inventory of the character gui will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.
  
• Updated the look of filter, item and circuit signal selection GUIs.
  

• Personal logistics are now unlocked by a single research. This unlocks personal logistic requests and auto trash(unlimited count), plus 30 character trash slots.
  
• Removed the restriction of not allowing to have two identical blueprints in the blueprint library or blueprint book.
  
• Allowed to delete blueprint/books/upgrade planners/deconstruction planners also when opened in other inventory.
  
• Removed the utility slots (to create blueprint, book etc) from blueprint library as it is now available directly through quick tools menu.
  
• Allowed to edit blueprints in the blueprint library the same way as when it is an item.
  
• Allowed to export blueprint books in blueprint library (it was only possible in inventory before).
  
• Allowed to choose whether train fuel should be included in a blueprint.
  

• Fixed that 3rd last row of 4th sheet of gun turret shooting had duplicate frame. more
  
• Fixed desync when changing recipe that was outputting large amount of fluid per crafting cycle to recipe that outputs low amount of fluid. more
  
• Fixed sprite button would not respect draw_shadow_under_picture style property. more
  

• Added main_menu_background_image_location to utility constants.
  

• Removed LuaStyle::extra_padding_when_activated read/write.
  
• Added LuaStyle::extra_top_padding_when_activated, extra_bottom_padding_when_activated, extra_left_padding_when_activated and extra_right_padding_when_activated read/write.
  

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.

It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots.
​
The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.

https://cdn.factorio.com/assets/img/blog/fff-338-tabs.mp4

Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request.

https://cdn.factorio.com/assets/img/blog/fff-338-setting-filters.mp4

With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science.

Searching now not only searches the recipe GUI, but also the inventory and logistic requests.

https://cdn.factorio.com/assets/img/blog/fff-338-search.mp4

By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots.

https://cdn.factorio.com/assets/img/blog/fff-338-toggle.mp4

Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released.

Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be <s>focusing</s> obsessing that much on the GUI in the future. We will 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.

This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.

Over the past two weeks, an overhaul mod called Krastorio 2 has been going through closed alpha and beta testing. Krastorio 2 is an overhaul mod that aims to provide a vanilla-style experience with an expanded post-rocket game and updated recipes. The mod will be released later today, so I wanted to take the opportunity to spotlight it.


My factory, grown over the two weeks of testing, showing off the custom mod graphics.
Click to view full resolution

The mod changes almost all recipes without introducing many intermediates, making it close to vanilla while still being a new experience. One of the bigger changes is that late-game technologies do not require the starting tech cards (science packs). Combined with the tech cards mostly needing intermediate products, you can reroute the ingredients of the tech cards into other production as the tech cards become obsolete.


Post-rocket tech cards are consumed in the lab area on the left in the image, the pre-rocket tech labs stand disused in the bottom right.

The biggest feature of Krastorio 2 is that it adds a significant amount of content beyond the rocket launch, including a new win condition. After automating rocket launches there are three more tech cards waiting to be researched, two new resources waiting to be harvested, and many more useful items to be crafted. All that production and the win condition take a significant amount of power but thankfully the mod adds an effective power generation option to fulfill the factory's needs.


Fusion power

All in all, the mod can be described as a great mix of updated recipes and fresh mechanics that are kept in line with vanilla. This means that the mod is not as overwhelming as overhauls that really focus on certain mechanics such as many additional resources, fluids or intermediates. Instead Krastorio 2 strikes a great balance between old and new. The mod has many more features that I did not mention here; so if I made you curious, check out the mod for yourself and have fun playing!