We have already pointed out, that we are trying to make a new campaign (FFF-245), and part of it is the core beginning, the NPE/tutorial.

The tutorial is one of the very critical parts of the game, as if the first 15 minutes of a game feels shitty, there is big chance, that the player will not play any further. I had this experience in many games myself.

So the challenge could be articulated like this: "The current tutorial is okay, but can we make it great?"
The approach in the current tutorial is to feed the player with the basic knowledge of how to control the basics of the game (the first mission and the start of the second mission) in the fastest way possible.



The player is even given descriptive info like this, to diminish the chance of not understanding how the basic entities work.



After few steps in the 2nd level, the player can start exploring his first self-feeding loop (make iron to make more iron).



The tools used to this is mainly:

• The message dialog that stops the game and explains the player various things.
• Minimization of the amount of things the player can interact with to absolute minimum, so he can't start doing other things before the basics are clear.

The possible drawbacks:

• The constant interruptions can get really annoying (typically around 22 message dialogs before the player starts to play relatively freely in the 2nd level).
• The possibility, that the player will mindlessly follow the step-by step tasks without understanding it, so he can become really lost later on, and the tutorial basically wouldn't help him to understand things.

So the question is: Can we make a tutorial that makes these problems go away?, and alternatively, How big are these problems actually?

The current direction of the new tutorial attempt is to never use the message dialogs, so the player can learn the game more fluently, and to leave way more things to explore, as learning things yourself has a better chance of success than force-feeding generally.

We made a few tests of the new approach with a few people, the main takeaway, is that nothing is for free, and this approach created new drawbacks.

• If the player doesn't figure out something basic, it can be very frustrating for him to figure out what is going on when not moving forward for a long time.
• It might be possible, that some things are just not fun to learn by exploration, and it is more comfortable if they are force fed to you. I would compare this to a friend explaining you how to play a game for 5 minutes compared to 2 hours of trial and error.

There are more possible outcomes from this, and we shall see how different tweaks of both strategies work in the testings. It might be interesting if you mentioned your experience with the tutorial in the comment section as well.

Regardless of the final tutorial approach we choose, we made some generic improvements that should help to avoid some of the pitfalls.
Interaction error messages

People sometimes struggled (in the beginning), to figure out why they can't interact with an object (open/mine/build, connect wires etc.) when it is too far away. We still keep the Beep Boop error sound and the different (yellowish) color, but we added a short flying text explaining the problem.

https://cdn.factorio.com/assets/img/blog/fff-261-not-reach.mp4
https://cdn.factorio.com/assets/img/blog/fff-261-not-reach.webm

https://cdn.factorio.com/assets/img/blog/fff-261-not-wire.mp4
https://cdn.factorio.com/assets/img/blog/fff-261-not-wire.webm

This also includes GUI related stuff like this:

https://cdn.factorio.com/assets/img/blog/fff-261-not-ingredients.mp4
https://cdn.factorio.com/assets/img/blog/fff-261-not-ingredients.webm

https://cdn.factorio.com/assets/img/blog/fff-261-not-hand.mp4
https://cdn.factorio.com/assets/img/blog/fff-261-not-hand.webm

https://cdn.factorio.com/assets/img/blog/fff-261-not-machine.mp4
https://cdn.factorio.com/assets/img/blog/fff-261-not-machine.webm

Some of these error had description messages, but these were in the bottom-left corner in the console, but we observed, that since it might quite far from the mouse and focus of the player, it can be easily missed. Even if it is not missed, it is not that comfortable to look somewhere "far away" for an error.

Highlighting of inserter/miner related entities

When building/hovering an inserter, miner or any entity that inserter/miner can interact with, the corresponding entities are highlighted. This should help to understand the connection, and even for me, it is useful sometimes to see instantly, whether the inserter is one tile off or not when building it.



Sometimes, I wondered why is the performance in Factorio is very unstable. The update runs fine (lets say 5ms) most of the time, and from time to time, it takes much longer (16+), so the frame is skipped, so the game feels choppy. For a long time, I expected, that this is caused by some Factorio tasks that can peak once in a while (train path finding), but the weird realisation came, when I played multiplayer, and I noticed, that other people didn't have the problem, so I started to investigate.
Browser

I realized this long time ago when doing performance tests. Running any browser with modern (dynamic) page, or and browser related applications (slack for example) take more performance than you think. I could measure non-trivial increases in performance when I closed all these.

Windows - performance options
There is a Power options panel in windows (Control Panel → Hardware and Sound → Power options), you can select different power options. It mainly controls things like how long it takes before it goes to sleep, or when are the Hard disks stopped, but it contains more, notably the minimum processor state, which by default (in the default plan, is 5%):

With this settings, I am seeing performance similar to this on my test save
Values are avarage/minimum/maximum in the context of the last 10 seconds.


While the default for high-performance is 100%:

With this, I am getting this result:


You can see, that the average time spent on update is roughly the same, but with the balanced mode, ther are quite big peaks of slowdowns that are happening regularly. You can test this yourself.

The minimum processor state basically allows the system to somehow slow down or turn off some parts of the processor. Factorio works in a way, that it does a lot of work in the update steps (the 5ms time), and then, the update thread has to wait until the time of the next update.
My theory is that when the thread is waiting for the next update, the system thinks that it doesn't need that much CPU power suddenly, so it slows down, but it doesn't switch back to full power fast enough when it is needed again in the next update.

I would be careful with this, as I can imagine that having this option all the time might not be that a good idea, mainly for laptops, but if your game starts to be choppy because of performance, it is worth a try to set this option for the time when you play Factorio at least.

The new forum theme caused quite some debate on the forum and in the office this week, specifically about the limited content width, and the result is that we added a slightly modified theme to scale the forum to the whole screen width. I would like to know your opinion, whether you prefer a limited content width, or prefer the content to fill your whole browser window, there will be a poll to vote in the forum post for this FFF.

As is standard, you can leave us your thoughts and feedback on our forum.

Hi Factorians,
This is Dominik, and my first FFF post ever! I will use this opportunity to talk to you about the exciting subject of pipes. Yeah, I know, right?

Spring came and with it Twinsen, saying "Pipes suck. Two people already tried to fix it and failed, who wants to be next?", and I’m like "Hey, that’s just pipes, you just make a simple simulation, simple AF. I’m in."
The conditions were even quite lenient:

• Fluids get where they should.
• They should act in a predictable manner, with reasonable splitting/joining in junctions.
• Fluids can travel instantly, if need be.
• Respect the pipe throughput limitations.
• Flow can be viewed on the pipes.
• Don’t do f**** up stuff like running in a circle indefinitely, sloshing back and forth endlessly etc.
• Should be faster/more UPS efficient.

I am mostly working on the new GUIs, but still, the fact that summer is over and pipes are not done, kinda shows how simple fixing them is. Very naive I was.

There are couple mishaps in the current pipe system. Good thing is that they work - the fluids do get from A to B, in most cases anyway. It follows a simple elevation model, fluidboxes will try to equalise with their neighbours, which is quite fast to evaluate and solves the simple cases, but it does not address much outside of running through a straight pipe.


(Green column represents volume, Blue represents flow)

The first of three main issues is that in junctions it behaves in a very random fashion. As a result, you might get recipients that are not getting any fluid where they obviously should be.



The second issue players voice is the limited behavior of the elevation functions. Only a fraction of the fluid is moved to its neighbour, so you rarely have a tank that is entirely full or entirely empty, which is a problem when you try to mix that with the integer based circuit network.

The third issue is performance. Even though the formulas are simple, they are calculated for every connection in every fluidbox, which adds up. As a result, nuclear power is unfeasible for megabases. There are other problems too, such as throughput loss over distance, fluids moving faster or slower depending on the entity update order, etc.


(Fluid flows much quicker in the bottom pipe)

The game is not at all practical for testing and debugging pipes, so I built a simple command line pipe simulator to develop the new system in. As I was attacking what I thought to be a simple problem, I started simple, and then had to refactor it several times whenever I realized that the problem is harder than what my simulator can support. I will shortly describe how it works, before going to the model itself.

The pipe layouts are loaded from a text file such as “5 1 \n s p p d 0”, which is 2 dimensions of the system, followed by a 2d layout, in this case just one row source-pipe-pipe-drain-empty. The simulator loads the layout, connects pipes and then updates the system tick by tick on request. I get a very rough overview, as picture below, but most of the time I have to inspect the running code to see what is going on under the hood.



Though now with the new map editor and the ability to step through single ticks, it will be much easier to test in-game too.

Before going to the current, simulation based model, I will shortly discuss other approaches that we have rejected.

Optimizing the current system
This is something Harkonnen tried a long time ago, to reduce indirection in the update of the fluidboxes. Essentially, instead of each entity updating their own fluidbox, all fluidboxes in a segment would be kept in a singular part of memory, and then the simulation could be updated much faster. Initial experiments showed a performance increase of 30-50% updating all fluidboxes. However this would not address any of the other issues, and would add a significant amount of complexity to the currently quite simple handling of the fluidboxes, which we decided isn't worth the price.

Flow model
Since we are doing flow here, flow algorithms look like a candidate. The most naive Ford–Fulkerson method, although theoretically infinite, could work super fast in our case. Problem is that it only finds the maximum flow - the top limit of what we can push through. We could then divide this max fluid flow between the consumers and kinda get a working results. But the behaviour on the way would be ridiculous with full flow through one pipe and 0 through next, 0 to dead ends etc. In other words, the junction behavior would be entirely broken. Better balanced flow algorithms exist but these also don’t do exactly what we need and the complexity quickly jumps to astronomical realms.

Electric network model
Another proposal was modelling like an electric network. Fluid flow is a popular analogy to their workings, and they do have a lot in common. The great thing about them is that they precisely model the flow branching and it could work out of the box. What it does not allow though is to limit the flow - one wire can, theoretically, run any current, but not so for the pipes, and we don’t want one pipe to be enough to supply whole factory. The limitations could be added, but that would, again, kill it with complexity.

A simplified version of this is what we consider the 'nuclear option'. In short, fluid network and pipes would work like the current electric network, instant transmission from production to consumption. This would increase performance by orders of magnitude, and remove the unintuitive flow of the current system, all consumers would get an equal split of the production, and storage tanks would act like accumulators.

However we have decided not to pursue this, for a few reasons.

• There would be no visualisation or indication of the flow of fluid.
• There would be unlimited throughput, one water pipe could supply all boiler and reactor setups.
• It abstracts away part of the realism and charm of the game. (While this is subjective at best, it does mean something to us.)

Merging fluidboxes
This would mean merging all the similar pipes in a segment into only a single fluidbox that needs updating. This would solve the performance issues, and the throughput loss over distance, however on its own, it would not solve the issues with update order, unintuitive flow direction/splitting etc.

Physics
When it comes to the basic physics model, I ended up with something that is not at all realistic, but works well in practice. At the beginning, I tried to do almost realistic physics - as a proof of concept, with momentums and all that. But quickly I became cluttered with complicated formulas and it did not work at all. The system is so heavily discrete that physics are not really applicable.

In Factorio, a full content of a ~meter long pipe moves into the next pipe in one tick and instead of mixing single molecules in a junction all in real time (infinitely little steps) we have to mix/split huge blocks in one shot. It’s more like moving Lego blocks than running fluids. For a long time I was playing with pressure but I dropped even that in favour of just two variables - volume and speed, where the speed kinda models the pressure as well. Volume is the amount of fluid in the segment, speed affects how much of it wants to move on in a tick - as speed x volume. Just this is enough to provide a pretty decent simulation.

Junction model
Most difficulties come from modelling the junctions. The general problem is that when anything does not behave entirely correctly, there exists a situation where it creates a total breakdown, such as no flow into some pipe.

There are colliding forces in play. We can only evaluate one pipe connection (one inlet/outlet) at a time, but the behavior needs to be symmetrical and fair towards pipes that are to be evaluated later (currently it is not). What is the right order of evaluation and how to make it symmetrical without super complex look-ahead?
Well, another big consideration is accuracy vs. complexity.

Over many iterations I kept developing models, followed by counterexamples that killed them.

The evaluation model I have arrived to works with two passes through the pipes in one tick. The formulas are more complex than the current one so it should be slower, but there will be one improvement to counterbalance it. The rough algorithm in one tick is as follows (I omit many necessary but boring details):

• (Done at the end of previous step) Every pipe states how much fluid it intends to send to neighbours (called flow reservation) using a simple heuristic.
• Perform topological sorting by direction of reservations from 0.
• Evaluate pipes in the opposite direction, i.e. from end to start, against the expected flow.
• Update a pipe in two stages:
  • Move fluid in it to neighbours proportionally to the space in them, space allocation they gave to the current pipe (providing they were already evaluated), and previous tick flow.
  • Allocate the resulting free space to neighbours that are yet to be evaluated to ensure they get fair share of it.
• Go through the pipes again and do clean-up and calculate reservations for the next tick.

So in this algorithm, we go from the last pipe, always moving fluid and making space for the next one. The reservations/allocations system ensures good behavior in the junctions. Essentially at every junction, the fluid will try to be split evenly between all the possible connections, which makes things very intuitive.

It works nicely, but unfortunately this system is even more computationally demanding. Here comes in the key improvement which is taking every straight pipe (every segment that has max two connections) and connect it into one piece. No matter how long it is, it will be evaluated in one calculation. Naturally, this loses some realism, but it is insignificant as it is the junctions that matter and those will remain unaffected. So as long as you don’t do crazy stuff like making pipe grids and keep your pipes straight, they will have zero effect on UPS.

To put it more simply, updates will only be run on junctions and segments. At each junction, fluid will be split evenly among the neighbouring segments and junctions, any excess from one neighbour will spill evenly to the others. A segment is just a section of pipe without any splits, and fluid will transfer instantly through segments, but with a limited throughput.



So in the setup above, we would go from updating 32 individual pipes with the 'old' system, to updating 3 junctions (blue) and 8 segments. Since a segment can be any length, overall we expect a big performance increase. It could also lead to more UPS efficient designs, trying to minimize the number of splits in your pipe network, we know some players really enjoy trying to optimize for different metrics.

A last convenience improvement are some rounding mechanisms to fill or move away those 0.0001 fluids, draining the last drops from the pipe system if the sources are disconnected, and filling all the way up if production is greater than consumption. Another point left to consider is how to solve accidentally connecting pipes and tainting your whole oil system with water.

All this is nice and already working, but still in the stage of the simulator.
What I still need to do to get it to 0.17:

• Figure out good model for storage tanks, and how they fit in.
• Perhaps refactor it from floats to integers, which would make it work more cleanly, but would also make some calculations more complicated. TBD.
• Finish the algorithm for correctly drawing the flow direction in the connected straight pipes (not that simple).
• Move it all into the game code.
• Write tests for it (I am probably overreacting but I feel that this will take as long as all the work up to this point).

So to sum up, we have had this on our minds for a long time now, and performance was not the only issue we have considered. The new system will hopefully address all the issues we mentioned at the start.

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

Actually, speaking of the forum, you might notice that it underwent some changes this week. Sanqui has updated our forum from phpBB version 3.0 to 3.2, which is a bigger jump than it sounds. It brings us more in line modern web features, the forums are now usable on phones, it heightens security, and paves the way for future extensions. Some style changes are final, but if you have any particular gripes, please say so and we will try to accommodate everybody.

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