While migrating from Allegro to SDL, HanziQ and Jiri replaced the keystroke handling from using key-codes to scan-codes. Before you start jumping with joy, you’ll probably wonder: What is that and why should I care?

Well, funny you should ask. You probably won’t care, unless you live outside of USA and/or you use a non-US keyboard layout. In short, key-code is a key identifier dependant on the symbol the key will output when pressed, scan-code is a key identifier based on the physical location of a key. So for example players with French keyboard layout (AZERTY) have to jump to the control options after launching the game for the first time, and remap movement from WASD to ZQSD, in order to be able to move their character without hurting their hand.



In 0.17, the controls will map to the correct keys by default, regardless of your layout, and stay mapped to those physical keys even if you for some reason change your keyboard layout while the game is running. The disadvantage is, most of the non-US layouts didn’t end up with completely broken controls, so people kept playing with them and got used to them. So they’ll need to get used to the layout the game was originally designed with, or manually configure controls back to what they are used to.

But wait, there is a catch...

A few weeks ago we have announced new construction tools, which are by default bound to quite universal shortcuts (Ctrl+C for copy, Ctrl+X for cut and Ctrl+Z for undo). Bilka pointed out that the German keyboard has Z swapped with Y (as does the Czech one, but developers often don't use it) and undo incorrectly defaults to Ctrl+Y instead. To fix these kind of shortcuts we determine the appropriate default scan-codes at start-up, so that undo is always Ctrl+Z, regardless of your layout, but the action will stay bound to those keys if you change keyboard layout at runtime, which is hopefully a reasonable compromise.

We might do it for other controls too (it feels natural for M to always be the default key to open the map, and T to open the technology screen), but there is another catch. It is completely reasonable for player to walk north, and Ctrl+click some entities. Remember AZERTY keyboard? Player keeps Z pressed down to walk north and presses Ctrl to start control clicking. Well, I tested this and it doesn’t trigger undo, but still stops player from walking. So it is not completely destructive, rather annoying. I am not sure how or if we’ll solve this, perhaps people with these layouts that create these kind of collisions will need resolve them by changing controls options manually.

The new Map Editor is finished, with one of the last things completed being importing surfaces from other save files. Importing surfaces from one save into another turned out to be quite complex, but not for the reasons you might think. The copying of a surface to a new surface is relatively easy, the main problem came from how we store map data in a save file.

Factorio internally makes lists of every entity, item, decorative and so on at startup and generates a mapping of the text name to an integer ID. This is internally called an ID mapping, and provides several benefits both runtime and when it comes to saving/loading the game. The main benefit being: we (and modders) don't need to track and manually assign ids to everything added to the game - the engine does it all automatically. Anyone familiar with modded Minecraft before version 1.7 can attest to how much of a pain manually handling IDs can be and how easily it can break.

Because things can be added and removed due to our internal changes or by adding/removing/changing mods, the ID mapping often changes. Because it can change we have to include it in the save file to know what it was when the save was created. When Factorio saves the map one of the first things that's written to the save file is that ID mapping.

The way it worked before was: at load time - the game would attempt to restore whatever the ID mapping was for the save it's loading. Anything it can't find means that thing doesn't exist any more, and anything new is stuff added. This lead to saves having different ID mappings for the same set of mods depending on the steps taken to make that save file. This worked for the most part but had a few small problems:

• Any time something was removed it was signalled by setting the ID at that location in the mapping to 0.
• The removed IDs couldn't be re-used until the save was fully loaded, saved, and loaded again (leading to gaps in the IDs).
• Different save files could end up using different IDs even when using the same set of mods.

With the new Map Editor wanting to take any save file and import it into your running game the fact that the ID mapping could be different was a problem. To add to the complexity we also have a migration system in place that lets you tell the game "I want to change all entities/items/... named *A* into *B*". This migration system also works when you remove the source otherwise it wouldn't be that useful.

After several false starts (a common theme when it comes to these complex reworkings), I came up with the following simple requirements:

• IDs will get assigned once after loading mods - after that they are never allowed to change for the lifetime of the program
• When a map is loaded instead of restoring the ID mapping it was using it will create a migration from the old ID to the new ID (if it still exists)
• The tracking of what was removed is done through a different system instead of treating a '0' ID as a removed ID.

During this rework I discovered we were doing a bunch of extra work (some of it even causing bugs) just to restore the save file ID mapping, and I was able to simply delete all of it now that the IDs simply migrate to the correct values any time a save file is loaded. I even inadvertently fixed a bug someone reported related to crashing when loading a specific scenario-using save file due to this rework.

Overall the system is simpler now and doesn't have any of the 'quirks' it used to. The new Map Editor can import any save file the game is capable of loading and it all 'just works'.

As you might know already from an earlier post, we are working with Ernestas on the high-res version of the enemies. This is a great excuse for also refining the concept of them. This week we want to show the new look of the worms.



The intention is to keep what we had in the previous version, but to emphasize its personality and behaviour. This new version tries to be more aggressive, powerful and disgusting, while also acting more nervous and agitated. The "fingers" on its head are for digging tunnels, something that wasn't really explained before, and which will also help to express the character of the worm.

Now we are working on the animations, trying to emphasize these concepts, basically the worm is a creature of pure hate and killer instinct. Together with the sound effects, I hope it is going to be a pleasure killing them.

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

One of the things in the large TODO list for 0.17 is giving a final polish to the map generator.

There are quite a few obvious problems now in 0.16, and some less obvious ones. Here are some of the fixes and improvements (some work in progress):

• All combinations of settings should no longer create strange maps such as circles of cliffs.
• Much more predictable starting area resources that don't overlap each-other and are not covered by water.
• The resource generation settings now have a much more dramatic effect (previously they had little to no effect).
• Increased the number of steps (small, medium, big, etc) for each setting from 5 to 9 for even more customization.
• The starting area will always contain water, most often a lake close to the spawn position.
• Since the algorithm for generating ores was pretty much completely rewritten, there are many small improvements.

Now for the less obvious problem: unpredictability. I saw quite a few people complain with vague comments like "the map generator sucks". So I often asked them what the problem is in detail. Some were complaining about the above problems, some did not understand what the settings do, and some had problems finding a "good map". I saw quite a few players click "regenerate" like crazy until they got a map with fat patches in the starting area, big oil patch and also uranium, complaining that it's too hard to find a "good map". Due to the randomness we seem to have set the expectation for "good map" a bit too high. Oil and uranium were never intended to be in the starting area, but due to the randomness of the generator they sometimes were there. Also sometimes maps were so wild that you would start off either swimming in resources or desperately looking for another iron patch.

It would be simple to just say "that's just RNG, deal with it", but blaming poor game experience on RNG is just bad design.
So what we did is:

• The starting area contains only iron, copper, coal and stone, in very predictable amounts. Uranium and oil are explicitly excluded from the starting area.
• Starting area resources are usually in one ore patch each (depending on settings).
• The starting area patches are usually close together.
• The starting area size setting no longer affects resource placement, it just has a fixed size.

Outside the starting area, the regular algorithm "kicks in" so you can still get quite wild results, but they are far enough that it averages out. I believe this is a good balance where you can still have different experiences depending on your luck, but your starting experience is much more predictable and does not leave you with the feeling that you got screwed over by the map generator. We definitely don't want the map generator to be extremely flat and predictable. Opinions on the subject are quite wild too, with people having different expectations of what a good map should look like, so we try to only make changes based on actual problems.

This might seem a bit controversial so we can add an option that disables this whole starting area logic, for purists.

We plan some small tweaks coming to biters also (a tiny bit more biters close to the starting area), small tweaks to terrain, cliffs, water generation and possibly some new features to make the generated trees and decoratives look better.

Most of these problems including the obvious and apparently simple ones were not that easy to solve. It's hard to make random generators do what you want, so TOGoS will explain what it took to actually get it done.

Good day procedural map generation enthusiasts!

The terrain generation in Factorio works by calculating probability and richness for every autoplaceable tile, entity, and decorative at every point on the map. To oversimplify slightly, the thing with the highest probability "wins" and then gets placed (if it's a tile) or has that probability of being placed (for entities and decoratives).

As some of you may recall, one of the features we added in 0.16 was a new terrain generation systemdriven by functional expressions built in Lua code. Mods define a function (not a Lua function, but a data structure representing a function in the mathematical sense)to be applied at every point on the map to calculate those values. This gave us a lot more control over elevation, temperature, humidity, and a few other variables across the map. However, the probability and richness functions for specific objects (notably resources) were controlled by a separate system.

I had wanted to unify these two systems since I started working on terrain generation last summer. Since releasing 0.16, our desire to improve resource placement, combined with my inability to come up with a good way to do it using the existing autoplace system, led me to finally bite the bullet and undertake 'the big autoplace refactoring'.

It was a lot of work.

The result is that existing AutoplaceSpecifications still work (because rewriting them all would have meant even more work), but under the hood they are compiled to expression trees, just like the ones for elevation, temperature, etc. As an alternative to the peak/dimension system, autoplace specifications can be defined in terms of a probability and richness expression directly, allowing a mod author to use the full potential of the programmable noise system.

An advantage of this approach is that we can now add new types of noise expressions without the need to reconcile them with all of the existing autoplace specifications or cram them into the ever-mode-complex monolithic AutoplaceSpecification object.

Specifically to make generation of resource patches more controllable, I added a new noise expression type called "spot noise". The way it works is that the map is divided into regions (large areas whose size is configurable per spot noise expression) and for each region:

• A list of random points is generated.
• Density, quantity, radius, and favorability are calculated for each point, based on noise expressions provided as parameters.
• The total desired quantity for the region is calculated by averaging the density from all points and multiplying by the region's area.
• Points are sorted according to their favorability, highest-to-lowest.
• Points are chosen from the front of that sorted list until the target quantity for the region is reached.

Having generated a list of spots with position, quantity, and radius, the output of the spot noise function is high near the spot centers and zero at a distance equal to their radius, such that the total value in the spot equals the spot's quantity. This value can then be used (for example) as the richness for a resource (such as iron-ore). By itself, this gives us 'conical' spots (if you think of resource patches as being mountains):



This result can have some noise added to it to make the resulting spots non-circular:



I had to be somewhat careful when applying this noise; since there is more area outside the spot where richness can be raised above zero than there is inside to be lowered, any randomization will add a positive bias to the overall quantity. I have been compensating for this by subtracting some constant fraction of the amplitude of the noise, though it's been on my mind that the problem could also be resolved by using differently shaped spots.

This system opens up a lot of possibilities:

• We can use the maximum of two different spot noise expressions to place starting area ores using completely different settings than we do for the rest of the map.
• We can vary quantity per spot and frequency of spots independently, which will allow the sliders on the new map screen to have more predictable effects.
• Spot quantity can depend on the suitability of the location. For example, we could set suitability to correspond to elevation so that spots are not placed underwater. The system would then continue through the list of candidate spots, placing more spots at locations above water to compensate. In the base game we're planning to do this for starting area resources, but not for resources outside of the starting area.
• In general, spot noise allows us to mess around with the placement of resources while keeping overall quantities constant.

Here are some map previews of the same seed, to illustrate spot-placed resource patches being moved to avoid water in the starting area as the water level is raised:





Putting everything together, here's what a typical starting area and surrounding region generated by the new system looks like.We may make a few more tweaks before 0.17 but this is probably pretty close:



All that said, I was perfectly happy when ore placement was unpredictable and sometimes there was no copper in the starting area and really long belts (and walls to defend them) were in order. So if I have my way there will be a "no special starting area resource placement" option.

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

With most of the team away for Gamescom or vacation, I have the pleasure of writing a Friday Facts for you this week.

As you probably know, I've been working on the New Player Experience (NPE, as we call the new demo + tutorial) and the new Campaign. However we don't want to talk about it too in-depth or be too specific about either of these subjects, purely to not spoil it for the FFF readers, but there is some related news to share.

The NPE needs a lot of scripting and design work to make sure the new player does not get stuck anywhere because it is a tutorial, and to make sure that it gives a taste of what the game is about because it is also a demo. Since the NPE was the first thing we started, we already have a working version and we have been testing it with people at the office, and also people who have never played Factorio, to get the necessary feedback to polish it further. From what we gather, it seems that the NPE is in a decent state, the main design seems to work very well and we are just improving details and making the map look nice.

The main campaign design has been completely finished for a while now, we have made a 'geographic' map layout and now we are 'just' implementing it in cooperation with Rseding, who is improving/adding tools for the map editor which makes our work a lot easier and in many cases just makes it possible (love letters, non-genital-shaped candy and other gifts to his address please), just like for any future map creators. It's still going to take quite some time to finish all of this, but the progress is steady and we can't wait to see people play it in 0.17.0.

One of the things we could really use in the campaign was a terrain that the player can't build on, but can walk on, so we are adding shallow water as a new terrain type. So far it's a cheap solution from our side - it's just a new tileset that is combined with decorative entities to make it look like walkable. Currently we don't plan to use this in freeplay, but if we can find its gameplay purpose and make the terrain generator use it properly, it's not impossible, but for now not a priority.



As I already wrote in an earlier FFF, that when working on the design of the NPE and the campaign, it's not rare that we come across something in the game which could work much better just by changing some recipes or technologies.

As I also wrote in that FFF, all science packs will have their own unlocking technology in 0.17 - but I did not show or tell how does this apply to Space science pack since you never unlock it as a recipe - you only need satellite and rocket silo for it.



At the same time when designing the campaign, we feel that the player should get more an idea of what they're progressing to reasonably early in the game and build towards it. On top of that I really don't like the dynamic in freeplay that you need as soon as you research rocket silo, you immediately have to build all the production lines for the rocket parts at the same time.
This results in:

• You no longer win the game by launching a satellite, there is a new "Rocket escape pod" that you launch in a rocket to finish the game. Currently the escape pod has no other use.
• Satellite is unlocked by its own "Space science pack" technology that has rocket silo as a prerequisite.
• Rocket silo technology only unlocks the Rocket silo and the Rocket part item the silo crafts internally.
• Rocket fuel is unlocked by researching its own technology which has Rocketry and Engine as a prerequisite. This means you can get rocket fuel for your vehicles way before the rocket silo.
• Nuclear power is split to Uranium processing and Nuclear power, where Kovarex enrichment process only requires Uranium processing and Rocket fuel so you can get Nuclear fuel for your vehicles without the rocket silo.
• Rocket control unit is unlocked by its own technology which has Production and High tech science pack technologies as a prerequisite. Additionally, Rocket control units are in the recipe for Atomic bomb instead of Processing units.
• Low density structure is unlocked by researching its own technology which has Science pack 3 and Advanced material processing as prerequisites. The Low density structure is also used in multiple advanced personal equipment recipes (mk2 things, Portable fusion reactor, Personal laser defense) instead of steel.

We hope that these tweaks and changes will help to smooth out the experience for new players and veterans alike. If you have any suggestions, feedback or comment, we are always happy to hear it over on our forum.

Hello,
A bunch of us will be travelling to Gamescom next week as visitors, if you see anybody wearing a Factorio t-shirt, it might very well be one of us. We don't have a booth or exhibit this year, as we don't want to take any focus away from the development of the game.

When we first released 0.15, we allowed Kovarex enrichment to use productivity modules. It very quickly became clear this doesn't work, as when the extra products were produced, it would output an additional 41 U-235, even though 40 of them were used as ingredients. An additional problem is that the 40 U-235 used as ingredients was shown as consumed in the production stats, and 41 as produced, even though really only 1 U-235 is produced. We added a fix for the production stats, but had more pressing concerns so we moved on.

However one of our source access members, Nexela, saw the potential, and decided to develop the concept more fully. With his work and some final integration tweaks from kovarex, we now have a proper catalyst system for the recipes in the game. What this means is that productivity will only apply on the count of produced items which are not also ingredients, with the enrichment process example, the bonus production will only give 1 U-235, not 41. This also means that Coal Liquefaction has been somewhat nerfed, so we might take a look at rebalancing it.

For modders: Catalyst ingredients are automatically calculated when the recipes are loaded, or can be manually assigned by putting `catalyst_amount = ...` in the ingredient and/or product definition.

We've all had the situation, where you are swapping out your armor and you accidentally spill your inventory all over the place. It is often not so hard to clean up, you can just use a filtered deconstruction planner to select the items on the ground. However if the items drop onto belts, the clean-up can be significantly more troublesome, as the items are swept away into the heart of the factory.

https://cdn.factorio.com/assets/img/blog/fff-256-drop-on-belts.mp4
https://cdn.factorio.com/assets/img/blog/fff-256-drop-on-belts.webm

It's not the biggest and most pressing issue in the world, but the result of this one misclick can result in a large amount of unfair annoyance. So just as a small tweak to the spill logic, in 0.17 if you do end up spilling your beans, they won't land on your spaghetti:

https://cdn.factorio.com/assets/img/blog/fff-256-no-drop-on-belts.mp4
https://cdn.factorio.com/assets/img/blog/fff-256-no-drop-on-belts.webm

We have all had the notion, that once we have a good and powerful network of Roboports and Construction robots set up, we would very much like to start paving the whole world with concrete. This is generally a slow process, but since it is automated, who cares about that.

However there was an issue, when you placed down a blueprint for something actually important, the bots would be too busy processing the tile orders to notice. This is due to the way we internally structure the construction orders, essentially we just put all the ghosts in a big list, and work through it to check if we can build the ghost. The problem is that for performance reasons, we only process a small number of these orders each tick, and with a list that is quite large, it can take quite some time to process the new blueprint you just placed down.

In 0.17, we have split this list into two, one for tile ghosts, and one for entity ghosts. This doesn't solve all the cases where blueprints will have quite some delay before building, but it solves the most typical case we see. We did a similar improvement a while back with the personal Roboports, where they independently check for nearby ghosts, outside of the global (per force) construction queue.

In the later game there is often an annoyance when trying to work around your overgrown belt jungle. It especially just leads to misclicks and a lot of hassle for something that doesn't really add much value to the gameplay at that stage. So the simple solution, in 0.17, there is a piece of armor equipment you can equip, that will make your character immune to belts.



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

Hello,
we had a small Factorio 0.17 LAN party this weekend. The purpose was to try and test some of the new features and play the game properly as I haven't had time for that for quite a while. I used this opportunity to think about all the smaller or bigger decisions, features or change of plans in the context of playing the game for many hours.

One of the most praised new features we had available was the copy paste (and cut paste) functionality. As you know already, everything is more complicated than expected... but this feature was the exception from the rule, as it took only something like 1-2 hours to make the copy paste fully functional, as it was just about connecting all the tools we already have (generic selection tools, blueprints, deconstruction planner, easy to add key shortcuts etc.).

This is how it works: You press Ctrl+C, and you activate the copy-paste selection tool, which is similar to selecting a blueprint: Once you have made your selection, you can build immediately:

https://cdn.factorio.com/assets/img/blog/fff-255-copy-paste.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-copy-paste.webm

When you press Q, the paste just goes away, but pressing Ctrl+V re-activates it any time in the future.

The cut paste is similar. Ctrl+X also allows you to select an area, but as a bonus, it also marks it for deconstruction. This is especially useful, when you need to just move some setup from one place to another.

https://cdn.factorio.com/assets/img/blog/fff-255-cut-paste.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-cut-paste.webm

Our plan is to have a special UI button for the copy, cut and paste tools on the main screen. The paste tool button can be used (apart the obvious use of clicking it to activate it), to edit the clipboard the same way blueprints can be altered, and maybe even access the history of the clipboard.

Upgrade planner has existed as a mod for some time already, and it is one of the most popular mods with over 250,000 downloads (It is made by Klonan by the way).

Since the feature is so useful, we decided that it is important enough to integrate it into Factorio natively. This gives us some advantages over the mod implementation:

• The main advantage is that it uses fast-replace functionality with construction robots, so upgrading chests keep the inventory, upgrading belts doesn't require all the items to be picked up etc.
• The tool can be stored in the blueprint library.
• The tool will also support upgrading tiles.
• The (arguable) advantage is, that it can no longer upgrade instantly from the player inventory, so it is more balanced and consistent with the other construction tools.

We also tested it in our playthrough and it was definitely a big quality of life improvement.

https://cdn.factorio.com/assets/img/blog/fff-255-upgrade-planner-1.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-upgrade-planner-1.webm

https://cdn.factorio.com/assets/img/blog/fff-255-upgrade-planner-2.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-upgrade-planner-2.webm

One of the features we would like to add before 0.17 is to allow the upgrade planner to work also inside a blueprint, so you can upgrade the whole blueprint by it, or just select part of it to be changed.

You might have experienced the situation as well. You build/deconstruct something and it ends up not being the thing you really wanted for some reason, so you instinctively press Ctrl+Z to undo it. When this happened to me I was always like "ha ha, I'm pressing Ctrl+Z, but I'm playing Factorio". We realized, that it might actually not be such a stupid idea to actually make it work in the game, at least partially.

The undo functionality is fully dependent on the construction robots being available, as doing anything else then construction orders would feel like cheating. Our prototype of the feature supports just 2 actions, building and removing, but it is already enough to make it useful at times.

When you build a blueprint of something, pressing Ctrl+Z cancels all the ghost entities, and if some of them were constructed already, they are marked for deconstruction.

https://cdn.factorio.com/assets/img/blog/fff-255-blueprint-undo.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-blueprint-undo.webm

The same works for manual placement:

https://cdn.factorio.com/assets/img/blog/fff-255-manual-build-undo.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-manual-build-undo.webm

When you deconstruct something, pressing Ctrl+Z cancels the deconstruction, and for entities that have been removed already, it places a ghosts so they will be rebuilt again:

https://cdn.factorio.com/assets/img/blog/fff-255-undo-deconstruction.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-undo-deconstruction.webm

The same works for manual mining:

https://cdn.factorio.com/assets/img/blog/fff-255-manual-mine-undo.mp4
https://cdn.factorio.com/assets/img/blog/fff-255-manual-mine-undo.webm

The LAN party also gave us insight, that the research queue is still valuable in some cases, especially in multiplayer, where I can add the research I need after the current one without cancelling the research of someone else. After some discussions, internal voting and more discussions, we decided to go this way:

Research queue is in the game, but it is disabled by default. It can be turned on with an advanced option checkbox, and this option is also turned on automatically once a player finishes the game for the first time. This way, we still ensure that the new players have the experience as wanted, but veterans that play it again and again, and players who are researching infinite technologies, have it available.

As copy-paste solved most of the annoyances with blueprints, the second most annoying thing was, that when I wanted to manually pick a blueprint from a blueprint book to build something, pressing Q didn't put it back in place in the book, but instead, it moved it to my inventory. It was also annoying, that I can't re-assign the blueprint contents of a blueprint in a blueprint book directly. These two things are already solved by the previous plans (FFF-250), but there are other tweaks we realized are needed.

• When the blueprint library has a grid and works similarly to the inventory, the movement from blueprint library to inventory makes a copy instead of moving it. We think making the blueprint library more persistent is a big priority.
• Blueprint library slots are still big and have the space underneath them for the name as it is now. We realized, that the main downside of showing as an inventory is removing the possibility to see the names, which is a main way to identify blueprints for some players.
• The blueprint library window is opened as a side panel, and can exist next to normal active windows. Blueprints can also be built directly from it.
• The shared blueprints feature is still useful, so we decided that it will stay. It will be a tab in the blueprint library, but it will only be visible in games with multiple players. This is important mainly for new players, so they are not overwhelmed by a lot of stuff at the beginning. The shared blueprints won't contain every players own library, only blueprints they explicitly choose to share.
• The last change is about what happens when a player creates a new blueprint and it only exists in the cursor. When he presses Q, where should the blueprint go?. In the current game, it just goes into the inventory, however in the FFF-250 write-up, it is removed. Neither of these options were ideal for us, as it feels like a hidden behavior. This will be changed, so when the player presses Q, it will invoke a small selection popup next to the mouse, so the player can explicitly select what to do:
  • Put it in the blueprint library - clicking it just opens the blueprint library, so it can be put there, if it is already opened, it just flashes.
  • Put it in the inventory - clicking it just opens the character screen with inventory, so it can be put there, if it is already opened, it just flashes.
  • Destroy
  I believe, that this helps the player understand what is going on. This popup can be either used to quickly access the storage for the blueprint, or the popup can be completely avoided if the blueprint is manually put into some storage. Since we have the copy paste now, the need to make a one-time temporary blueprint should be non-existent , so it shouldn't add any extra annoyance in this use-case.

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

Hello, we are really appreciating that the new offices have proper air conditioning...

The research queue was one of the planned and implemented features for 0.17. The player could queue up to 5 technologies so the research would flow better. The weird thing about this feature is, that it sounds much better on paper than in reality.



I was playing with the research queue for the first time when I was testing the new tutorial/campaign and I noticed a weird thing about it. As I just queued all the 5 possible technologies in the first mission, I had no idea what and when was unlocked, so I was not taking advantage of these things for quite some time. Vaclav played a lot of normal (freeplay) games with the queue, and he also supported me that the feature in reality doesn't make the experience better. After that, we started to reconsider the feature. The breakdown is this:

Cons:

• The newly unlocked recipes might be overlooked (It is solvable by some kind of pop-up, but it is far from perfect).
• It removes the joy of looking at the result of the research and of picking a new thing that will be the next one to do.
• It adds to the feeling of just going through a to-do list without having much to say about it.
• The queue has to be changed a lot as the priorities change.

Pros:

• It feels appropriate in some situations, like finishing all remaining green science that I don't care about as I'm not producing blue yet etc.
• It feels okay to queue the repeating upgrade research at times, but as the cost grows quite fast usually, it becomes less and less of a problem.

So the overall decision was to remove this feature, on the condition that I have to say that I kovarex, personally, killed it. I am the one to blame :)

We have another round of Mod Portal updates for you.

There is now a new Trending section where you can browse fresh mods that have have seen a surge in downloads recently. The exact algorithm? Secret sauce, of course.



While browsing and searching for mods, you can now filter by game version, with the latest stable version naturally being the default selection.



The mod portal gives each mod its own little discussion section. However, rather than being a convenient place for mod authors to communicate with their fans, this could also be a source of annoyance, as some mods have other avenues (forum threads, GitHub...) and the mod portal had to be checked separately. This has now been alleviated with the new notification system. Mod authors are automatically subscribed to their mods' discussions, and posters can subscribe to the threads they create or reply to. Email notifications are off by default, but there's nothing easier than enabling them.



To further make the discussions more usable, mod authors and collaborators now have more moderation tools at their hands: they can lock and trash threads, as well as change their titles and category.



I will be shifting my focus from the mod portal for now, but feel free to post feedback and feature requests in the mod portal section on the forums.

As always, the pitchforks and flaming torches can be found over on our forum.

One of the many small tasks for 0.17, was to solve the occasional problem I had when I didn't notice that one of my trains didn't have the refuelling automated. One train out of fuel can halt all the train logistics easily, and sometimes it takes quite a while to notice it. For this reason, we added an alert for trains running out of fuel when in automatic mode.



On Monday we went to the National Library of Technology (NTK). As we mentioned a while ago, they have loaded their library PC's up with Factorio, and they invited us for a tour, and a Factorio LAN party. We got to have a look at their server infrastructure and inner workings of the library, including an automated splitter type machine for sorting which floors returned books go to.

The LAN party went really well, we had nearly 50 players join and help build our factory. Unfortunately we couldn't get to launching a rocket in the 4 hours we had. If you want to check our progress, you can download the save game here. Of course we had to take some time out of automating to build a flashing NTK sign:



Surprisingly, there was quite a lot of local press at the event, and there were a couple of Czech articles published this week: https://www.novinky.cz/internet-a-pc/hry-a-herni-systemy/478591-ceska-budovatelska-hra-factorio-slavi-uspech-i-v-zahranici-a-to-jeste-neni-hotova.html, České noviny.

TOGoS arrived for a visit last week, and quickly dove right into deep discussions with Albert, Twinsen, etc. about the map generation improvements. More on that later... But with him he brought along an incredible package from one of our fans, PeteTheLich:



The big beacon is about 6" (15 cm) tall, and the base is about 6" in diameter, and it functions as a piggy bank, with a slot in the top to put in coins, and a hatch on the bottom to get them out. Everything he sent is really awesome, and we're super grateful for him sending them over (especially with all the customs problems on the first attempt). If you are interested in getting some of these items printed, you can check out the Factorio Thingiverse page.

Fan creations such as this are really inspiring, and gives us great ideas for our own official Factorio products in the future.

Speaking of fan creations...

arrow_in_my_gluteus made an interesting investigation into the exact top speed a player can achieve in the vanilla game:

https://youtu.be/EF99Ym5jXjg

The final result is cheesing the game mechanics a little bit, but to quote kovarex: "It is emergent gameplay", so we can expect to see start seeing more rocket silo highways in factories to come.

Ernestas and Vaclav recently finished off the defensive structures in high resolution. Notably, the walls and gates were completely redesigned, and now have a filler sprite when the wall is several layers thick.



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

Val: Do you remember the smell of the fresh air near the seashore? Can you describe, a forest that rumbles its trees after a summer rain? All that you hear and see goes right into your mind. All of our senses are connected with each other in our memories. When we feel at least one of them, our imagination brings the others. Sometimes, and even often, we can't see the object, but we can hear it! You can't see the wind, but you feel it and hear it! The bird is singing. You can't see it hiding in a bush, but you hear a beautiful song and can define the direction it comes from.

The forest, the sea, the desert... Night and day. Clanking of a loading cannon and snoring of unseen monsters. That is what we are planning to do. To put the unseen colors of sound and add some feeling of life to the planet of Factorio. Even the emptiness has it's own voice...

Albert: As you probably know, we are in a stage of polishing all the possible aspects of the game.

Last week we were cooperating with Val, our new sound designer, and we spent the entire week defining new concepts for environmental sounds and sound effects. Also we were working on the sound of the biter nests and the artillery cannon. This is definitely a huge subject full of details that can really improve the play experience of Factorio. Here I can show you a work in progress of the artillery cannon:

https://cdn.factorio.com/assets/img/blog/fff-252-artillery-cannon.mp4

We have to tweak some behaviour of the entity in order to make it act more mechanical, but overall, the possibilities that sound design can bring to the game are really interesting. Compare the simple shooting of the cannon in the actual version with this proof of concept with all those details in rotation and loading. Of course this level of detail complicates the work a little bit, but I'm convinced it's worth it.

We are also working in parallel with Ernestas, who is improving the look of the enemies. Right now we can show a sneak peek of how the new spawners look in HR. Together with TOGoS, we are working in a more specific map generation in order to improve the composition of the nests. The intention is to generate a special ambience for those areas that makes you feel like you are in enemy territory.



Everything here is a work in progress, let us see how we end up with all those plans. Soon I'd like to show how the nests look with the animations, the ambience, and all the biters and worms around.

Factorio has had a Map Editor since the early stages of development. It was initially used to create the current campaigns and scenarios, and from time to time we would use it to help diagnose desyncs. However, as development continued the Map Editor seemed to have been forgotten.

Inside the Factorio engine, almost every game GUI/action is associated with the player that is looking at the GUI and doing the action. This makes sense because when the game is running everything is done by a specific player, and GUIs need to know stuff about that player. When actions are processed the game applies them to a specific player in the world, and handles stuff like multiplayer syncing of actions done by different players. In the Map Editor there is no "player" - there is just the editor - and this has caused a massive divide in what the editor can do compared to the main game.

Because the Map Editor has no 'player' it can't use any of the action processing logic the normal game uses, and instead uses a large copy-paste of the action processing and attempts to apply it to the map knowing there's no player associated. This 'works' for the most part, but some actions are inherently tied to a player and simply don't work in this disassociated context. Having this split of 'game' and 'editor' means we had to essentially write any action processing logic twice: once for the game, and once for the editor. Most people skipped the second part and so the editor fell behind. From time to time someone would report a problem with it, or ask if we could add some new functionality (or even if it could just do what the normal game could do). The internal joke was always "Nobody uses the Map Editor" to explain-away why it was so lacking.

When 0.17 tasks where being assigned, the topic of the Map Editor was brought up and I (Rseding) indicated I would be interested in working on it. Knowing what the problems where and how I wanted to go about fixing them I started. Several months of work (and several false-starts) later, I now have a 90%-there new Map Editor.

The new Map Editor has several key differences over the old one:

• I removed the separation of 'normal game' and 'map editor'. The Map Editor is built right into the standard game logic. Anything the normal game can do it can do automatically. For those familiar with Factorio's modding: it's a new controller like the 'god controller', called 'editor controller'.
• The standard interaction mechanics of the normal game 'just work' in the Map Editor (Hotkeys, QoL shortcuts, Pipette tool, etc.).
• The Map Editor can be toggled on and off while playing any game. You no longer need to save, exit the game, go to the map editor, convert-save-to-scenario, and then finally load-in-map-editor. You can just be playing the game and switch to the editor (and back).
• The Map Editor is multiplayer compatible: It doesn't make any distinction between singleplayer and multiplayer - it just works for both.
• The Map Editor can pause/unpause the normal entity update but still interact (in multiplayer as well). Non-map-editor players are frozen in place but can still talk, switch to/from the editor, connect, and disconnect from the game.
• The Map Editor is King. Anything you want to do, it lets you do (if I thought of it), at no point during development did I decide "No, you just can't do that with the editor - it would be too powerful". The point of it is to be powerful.

https://cdn.factorio.com/assets/img/blog/fff-252-editor-switch.mp4

After replicating the functionality of the old editor, I started working on new features that have been requested by community and other team members:

• A new cloning tool to copy entities/decoratives/tiles in any combination from one area (and surface) to another. This copies almost everything about the entity - items, recipes, variations and so on:

https://cdn.factorio.com/assets/img/blog/fff-252-copy-paste.mp4

• A paint-bucket tool for painting tiles that would paint-bucket replace all tiles of a specific type under the mouse:

https://cdn.factorio.com/assets/img/blog/fff-252-paint-bucket.mp4

• Extending the force-editor to create/remove/edit forces fully.
• Extending the entity-editor to let you place entities on other forces than the defaults.
• Extending the decorative editor to have more fine-grain control of placing/removing without needing to know the exact decorative you're looking at.
• Controlling the simulation rate and controlling tick execution.

https://cdn.factorio.com/assets/img/blog/fff-252-time-control.mp4

Finally what I see as the ultimate request: "Ability to Copy & Paste an area from 1 map to another, transferring tiles/doodads/biters/trees/entities/items/...". The key part being "from 1 map to another" meaning "let me import stuff from other save files". I have a plan to make this work, but it will be restricted to single-player only. Still, I can see it being incredibly powerful when finished.

In summary: there is still more work to be done but the new Map Editor is coming together amazingly. I'm looking forward to what people will create/do with the new power the new Map Editor will bring. For us it will greatly speed up the work on the new campaign maps.

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

If you are in Prague this summer, and wanting to satiate your Factorio cravings, you can stop in to the National Library of Technology Prague, where Factorio is loaded onto 150 computers for all to play. Entry is free for all visitors Monday to Friday 08:00 - 22:00 until the 31st of August. The PC's are running Linux (Fedora), loaded with a custom build of the game HanziQ put together, and you can host LAN servers and play with your friends.



On the 23rd of July we will be hosting our own Factorio LAN party at the library starting at 16:00 CEST (Prague time), so you can come along and play with us. It is advised to bring your own set of headphones if you are going to attend.

As we started to modernize our rendering backend, the absolute must have was to make it at least as fast as the old one. We had the chance to do things however we wanted, so we were excited about the capabilities newer APIs unlocked for us, and we had lot of ideas how to draw sprites as fast as possible.

But first, there is no need to reinvent the wheel, so let’s see how Allegro makes the magic happen. Allegro utilizes sprite batching, which means it draws multiple sprites that use same texture and rendering state, using a single command sent to the GPU. These draw commands are usually referred to as draw calls. Allegro draws sprites using 6 vertices, and it batches them into a C allocated buffer. Whenever a batch ends, it is passed to the OpenGL or DirectX drawing function that copies it (in order to not stall the CPU) and send the draw call.



That looks pretty reasonable, but we can’t do the exact same thing, because in DirectX 10, there are no functions for drawing from C-arrays directly, and it is mandatory to use vertex buffers. So our first version created vertex buffer to which current batch was always copied for use in a draw call, and we would reallocate a buffer with a larger size if the current batch wouldn’t fit. It was running quite fine, probably not as fast as Allegro version, and it lagged noticeably whenever the vertex buffer would need to be resized.

After reading some articles, for example optimizing rendering in Galactic Civilizations 3 and buffer object streaming on the OpenGL Wiki (which was very helpful), it became clear that the way to go is to have a vertex buffer of fixed size, and keep adding to until it is full. When we finish writing a batch to the buffer, we don't send a draw call right away, we write where this batch starts and ends into a queue, and keep writing into the buffer. When the buffer is full, we unmap it from system memory, and send all the queued draw calls at once. This saves on the expensive operation of mapping and unmapping the vertex buffer for each batch.



As we were trying to figure out how to serve data to the GPU in the most efficient way, we were also experimenting with what kind of data to send to GPU. The less data we send, the better, and Allegro was using 6 vertices per sprite with a total size of 144 bytes. We wanted to do point sprites which would require only 48 bytes per sprite and less overall maths for the CPU to prepare a single sprite. Our first idea was to use instancing, but we quickly changed our mind without even trying, because when researching the method, we stumbled upon this presentation specifically warning against using instancing for objects with low polygon count (like sprites). Out next idea was to implement point sprites using a geometry shader.



We tried it, and it worked great. We got some speedup due CPU needing to prepare less data, but when doing research how different APIs work with geometry shaders, we found out that Metal (and therefore MoltenVK) on macOS doesn’t support geometry shaders at all. After more digging, we found an article called Why Geometry Shaders Are Slow. So we tested using the geometry shader on a range of PCs in the office, and found that while it was faster on PCs with new graphics cards, the older machines took a noticeable performance hit. Due to the lack of support on macOS and the possible slowdown on slower machines, we decided to drop the idea.

It seems the best way to do point sprites is to use a constant buffer or texture buffer to pass point data to a vertex shader, and expand points into quads there. But at this time we already have all the optimizations mentioned in the first part, and the CPU part of rendering is now fast enough that we have put the point sprite idea on ice the for time being. Instead, the CPU will prepare 4 vertices per sprite with a total size of 80 bytes, and we will use a static index buffer to expand them to two triangles.

The following benchmark results are from various computers. The benchmark rendered a single frame at max zoom out (about 25,000 sprites) 600 times as fast as possible without updating the game, and the graph shows the average time to prepare and render the frame. On computers with integrated GPU there was little improvement because those seem to be bottlenecked by the GPU.



We also noticed higher speed-ups on AMD cards compared to nVidia cards. For example in my computer I have a GTX 1060 6GB and Radeon R7 360. In 0.16 rendering was much slower on the Radeon than on the GeForce, but with the new renderer the performance is almost the same (as it should be because GPU finishes its job faster than the CPU can feed it draw commands). Next we need to improve the GPU side of things, mainly excessive usage of video memory (VRAM), but more on that topic in some future Friday Facts...

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

Sanqui has been quite effective these last weeks getting stuck in with the mod portal, so we have some interesting additions to talk about.

Mod deprecation
A modder can mark a mod as deprecated, which indicates they are no longer updating or maintaining it. The typical case is a mod will add something relevant for the current version of the game (E.G, a mod to scan the players starting area), and then an update to the base game makes the mod obsolete. Just deleting the mod could potentially cause problems for people playing an older version, people might ask what has happened to it etc.



Marking as deprecated will keep the mod up on the portal, but it will be hidden from any public searches. This way people downloading using 'Sync mods with save' feature can keep playing, while new players won't stumble upon a mod that is no longer useful or up to date. It also preserves the downloads and discussions in case the author wants to revive it later.

Collaborators
It is often the case, that a mod author will want someone else to help them maintain and manage their mod, for instance if they are going on holiday when a major release is coming out. The way it has worked in the past, another modder would have to come and upload an updated version of the mod under their own name. Now a modder can set another player as a 'collaborator', which means they can help out will all the maintenance of the mod. Collaborators can do everything the author can do, except add or remove collaborators.



You might also spot the other feature, transferring mod ownership. This lets the author give the mod completely to a collaborator, in the case that they are no longer interested in working on the mod at all.

Discussions notice
Mod authors can now display a notice above their mod page discussions, informing the users of any useful information. For example, an author might prefer you to report bugs on their GitHub page, so the notice will inform users of where they should go. An additional option allows the author to disable the discussions completely, in the case they have their own forum/thread somewhere for discussions.



If you have any ideas for an improvement to the mod portal, please let us know on our Mod portal discussion subforum.

I feel that none of the propositions in the previous Friday Facts were really that great. We spent some more time thinking about the blueprints and the blueprint library while going through the player feedback, and we are now agreeing on what I like to call Proposal Zero, because it was the first idea and the first mockup I ever made related to this subject. Put simply, blueprints stay as items, and the blueprint library becomes a regular inventory, like a chest (that is of course accessible across all your saves).

The idea goes together well with the "quickbar is an action bar" idea explained in the FFF-191. The details and mockups for the action bar are taking shape, so expect more about it in a future FFF.

When working on GUIs, I like to create design documents where I try to explain how something works as objectively and as complete as possible. It ends up sounding like a boring legal document, but it helps force me to think of all the corner cases and possibly find problems. I will use this opportunity to also tell you how we usually work on the GUI. Here is what I have written so far:Blueprints and blueprint library Proposition Zero:

• In the text below, Blueprinting Tool = Blueprint, Blueprint book or deconstruction planner. Library = Blueprint Library. Book = Blueprint Book.
• Blueprinting Tools stay as items, they interact consistently throughout the game.
• The blueprint library: One window with one grid of large (or small?) spaces. The grid expands infinitely on a row-by-row basis (if any item is placed in any slot of the last row, a new row is added). This grid act almost identically as a chest. Items can be manually moved there, or fast transferred using any of the shortcuts that work for normal inventories (see comment below). This inventory grid can only hold blueprints, books or deconstruction planners.
• Special behavior: when picking up a Blueprinting Tool from the blueprint library, it is replaced with a "hand". This means that when pressing Q to drop it, it is not returned to the player inventory, instead, back to that slot in the blueprint library. This is so blueprints can easily be used directly from the library.
• The functionality of automatic blueprint library sharing in multiplayer is removed. The "shared blueprints" panel is removed. Blueprints and blueprint books in multiplayer will be shared by manually trading the items or by linking them in the chat. Blueprints or books linked in the chat can be clicked to pick up a copy that can be used as a normal item.
• Every Blueprinting Tool will have a unique identifier, so every blueprint item is unique, even if it has the same contents.
• The blueprint editing interface (the UI that opens when you right-click a blueprint) will have 2 new buttons:
  • Reassign: assign new contents to this blueprint. This is helpful when you want to update a blueprint and leave it in the same place in the player inventory, blueprint library or action bar.
  • Duplicate: create a new blueprint with a different unique identifier, but the same contents, and place it in the player cursor. This can be useful when players want to take a copy of a blueprint from the library to edit, experiment with or remove buildings from, without changing the original blueprint.
• Shortcuts to Blueprinting Tools can be created from the player inventory or from the blueprint library to the action bar:
  • Right clicking a shortcut to a Blueprinting Tool will open the blueprint editing interface, as if it was right clicked in its original location.
  • If a Blueprinting Tool is moved between the library and the player inventory, the shortcut in the action bar remains valid and unchanged.
  • If the Blueprinting Tool is moved outside any of these inventories (e.g., placed in a chest, or given to another player), the shortcut will become greyed out and cannot be interacted with, only cleared. If the Blueprinting Tool is placed back in the player inventory or blueprint library, the shortcut becomes valid again.
  • If the Blueprinting Tool is removed (or destroyed) from the library, and a different game is loaded that had a shortcut to that Blueprinting Tool, the shortcut will become greyed out forever, and it can only be cleared. This is to give feedback that there used to be a Blueprinting Tool there.
  • If a Blueprinting Tool is explicitly destroyed using the trash button, the shortcut will become greyed out forever and it can only be cleared. This is to keep consistency with the two rules above.
• Blueprint books will work very similarly to the library: it will be an inventory which can hold only blueprints (maybe also deconstruction planners?).
• Blueprint books will have the same sparse grid where you can arrange the contents as you like. 'Shift + Mouse Wheel' will move to the next/previous non-empty slot.
• Blueprint books will not have any special behavior or interactions while in the library, right clicking them will open the book in a separate window, possibly closing the Library. Clicking them will pick them up to the cursor.
• Blueprinting Tools are created using buttons in the Library. Blueprint string importing will also be there.
• Quick Copy pasting will be done using new copy-paste functions that work almost identically to blueprints. Pressing 'Ctrl + C' will place a copy tool, similar to a blueprint in the cursor. You can use this select a number of entities to copy. Pressing 'Ctrl + V' will place a quick paste tool in the cursor, similar to a blueprint with items. You can use this to place as many copies of the things you copied as you like.
• The quick copy and quick paste tools are not items. Pressing Q will simply clear the cursor and not return anything to the inventory.
• The quick copy and quick paste buttons will also be shown in the main GUI, next to the action bar. Hovering over the paste button will show a tooltip of the blueprint that is currently in the 'clipboard'.

Comments:

• Being able to use all the fast transfer shortcuts in the blueprint library makes it very consistent with a chest, but can lead to very nasty situations where one accidental click can transfer all the blueprints and books to your inventory, completely screwing the order and organization you had in the grid. At the same time "transfer everything" can be something some players might use often if they don't have many books.

Other:

• The blueprint editor GUI should allow you to zoom and pan around to better inspect it. You can add buildings while holding an item or ghost item from the action bar; for convenience a small interface will give you the possibility to place any ghost item in the cursor. This is intended for quick corrections. Things like connecting cables or changing entity settings will not be possible; for bigger changes use the Reassign button.
• The blueprint library button will be disabled until bots are researched or until any item is added to the library for the first time. This means less GUIs for new players to get lost in, also less of an invitation to use the controversial string importing at the beginning for the game.

Usually I create a very crude and simplified MS Paint mockup of any changed GUIs.


I use all this, the design document and mockup, to present the idea to the other devs, make some changes, and if we all mostly agree with it, all this goes to Albert so he can more thoroughly design the look and arrange all the GUI elements. There is usually a lot of back end forth between us so we can properly tie UI and UX together. After the mockup is finished, one of the programmers, usually Oxyd, Dominik or I(Twinsen) start putting it in game, with the help of kovarex who makes sure AGUI has all the new functionality we need in the back-end. After we have the interaction in the game and we are able to play with it, there is of course further tweaking.

Well, the process I wrote about is the ideal case, in reality every different part of the UI is done slightly differently, especially since we are still at the beginning and we are still trying to figure out the concepts of the GUI, but I hope we will be able to use this pipeline to go though the GUI like butter.

Let us know what you think of the proposed changes to blueprint on our Forum.