Hello, as you could expect this Friday facts is mainly about our fight with the avalanche of bug reports, which is actually not as huge as we expected it to be to be honest.

We released 0.16.7 yesterday, and this will probably be the last update for a while. Most of us now are taking a break, enjoying the festivities, and visiting our friends and family.

Transport belt compression update

Regarding the belt compression discussion opened in the last FFF: We are considering an option where side loading and inserters would compress belts natively. We will make a branch with it to test it how it works, and we will let you know our decision.

Fluid wagon update

We made a decision to completely abolish the mechanics of fluid wagon tank separation. We knew that a lot of players would not like it, but this might just be because they got used to it, and because of the argument "if you don't like it, don't use it".

There are more arguments to destroy.

• Fluid wagon capacity is somewhat too big, which means that the fluid trains have to move around very sporadically compared to the trains with items. Making the wagon fluid capacity smaller (we didn't do it yet) and removing the separation, is similar to making the whole fluid wagon as big as one section.
• It was solving a problem that has quite a trivial solution (use two separate wagons). We try to add mechanics mainly for things that don't have a solution otherwise, or the solution is weird.
• We won't have to keep the code alive, we won't have to update the UI of it (in the upcoming GUI update) and fix the bugs related to it. This argument is the smallest, but is also here, as everything has a cost and it is about priorities.

Requester chest update

The change of the requester chest having priority over buffer chest was not that easy, as I decided to combine it with optimisation I wanted to do for a long time.
In the current version, requesters have just 2 containers internally: "unsatisfied requesters" and "satisfied requesters", every tick, the "unsatisfied requesters" are iterated and it is checked whether supply is available for them. The second bucked with "satisfied requesters" is separated so we don't have to iterate through requesters that don't need anything now.

The problem with this approach is, that once there are more a lot of unsatisfied requester chests for the same thing (lets say iron), and there just isn't iron in the supply at this moment, all the requesters have to be wastefully iterated again and again. So the change is, that every requests of chests are tracked separately for every item, and once the item isn't available, the rest of the requesters don't have to be iterated. I didn't measure, but it might have some minor impact in big bot-based Factories.

The reason why was the optimisation written together with the fix is, that requesters have to have priority over buffer chests independently for each item, and it works quite nicely with it.
TL;DR, this functionality is now merged into our master branch, and you will get it in the next bugfix release.

I also feel, that we should add 2 things to the logistic system in 0.16:

• A checkbox in the requester chest that would allow the player to specify whether it should or shouldn't take from buffer chests, as even with the priorities, it might be annoying if robots took all the stuff from buffer stations to the requesters just because the supply train is going to arrive 10 seconds late, so the buffer chests would be supplied again soon. I would even say that the option might be to not take things from buffer chests by default.
• A filter for the storage chests. Buffer chests somewhat help to sort the storage, it doesn't really replace the need of storage chests to have a single filter for the whole storage chest. This would allow it to be reserved just for something specific, which would solve a lot of different problems

3 major train problems resolved

Thanks to train bugfixes from the user aaargha, there were 3 quite important fixes related to trains done. All of them were in the game for a very long time, more than 3 years, which surprises me a lot.

1. A train decelerating to stop in a station created penalty around 2^32/10 (a lot) on the path it went through. This was sometimes causing trains to do very crazy and huge paths just to avoid this point. It was especially annoying as the penalty was easily enough to force train to go through different stations (that has penalty of 2000) which could cause traffic jams in a lot of systems.
2. The train penalty of 2000 to avoid trains going through stops not on its own path was applied to the destination stop before actually reaching it. This caused the train path-finding to potentially search a huge amount of paths while the destination stop was just ahead of it. It was just a potential performance problem, but as you probably noticed, we need to care about performance.
3. The last bug is related to this example:

The top train arrives later because there is no rail signal just in front of the stop. Sounds weird right? This bug was related to a hacky solution to a problem with extremely fast trains 3 years ago, and it basically caused trains to start slowing down for a station 2 times sooner in many cases.

All of these problems are already fixed in the current 0.16.7.

Steam awards

Factorio has been nominated for one of the Steam awards, 'Haunts My Dreams'. It is a nice mark of recognition for all the work we've put to the game this year. It seems the other nominees are pretty much the giants of the industry, so it is most likely one of these will win. Still, it is nice to be included with the big kids.

The voting for this category opens on the 29th of December, at 10 AM PST, for 24 hours only. So if you are interested in voting for one of the entrants, be sure you can get to a PC on that day.

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