I have to admit that the Factorio development is slowed down these days, but it is not stopped because it just can't stop. Or is it because we can't stop? I guess that we have come too far to give up who we are.

0.11.8 is less broken than 0.11.7 but still not recommandable

There is the the parallel saving/loading of the map in 0.11.7+. The dangerous thing about it is, that it is the first time when we save the game in one thread and render it in the other. It almost works in 0.11.8 but there are still some corner cases where it can corrupt the save or crash the game. Most of the trouble in 0.11.8 is based on the fact, that we use the same flag for entities already saved and for entities already contained in the result of area search. We just thought it will never be used at the same time and it is exactly what is happening now. This is a good lesson for us, that the the view of the game should really never ever change anything in the game state, not even temporarily.
The 0.11.9 will be released on monday and I hope to have all these kind of problems covered by then.

The plans for 0.12 (Part III)

We would like to do something like the floors mod. It shouldn't be so hard to do, and it adds a lot to the variability and personification of the factories. In the start, the floors will have mainly aesthetic effect, and they will affect the running/driving speed. Especially things like pathways through the forest, will be both nice and practical. We might relate some other mechanics to it, but we need to discuss it more, maybe you can give us your ideas in the comments.

The update time reduction

We had a bug report claiming that the game is broken, as the performance is very low. I inspected the savegame just to find out, it is one of the biggest factories I have seen, so It quite makes sense that it runs slowly. But I couldn't stop myself from finishing one of the key optimisations we had planned to make it run faster. The problem with inserters is, that they are the most cpu intensive piece of the factory (not anymore in the next update).

The problem can be explained on this situation:

These inserters that are putting stuff from the transport belt to the chest are doing nothing, as the chests are full. But in the game logic, they are doing a lot:

• Get me the list of all the items on the tile in front of me
• For every item, check whether I can put it into the chest
• For every check, go through all the stacks of the chest and check that it really can't be put there.

Imagine that thousands of inserters are doing this boring job 60 times per second. This is obviously far from optimal.

The next picture demonstrates the change I prepared for the 0.11.9

(The red circles are the debug view indicating the deactivated entities.)

From now on, the inserter tries to do all the logic as before, but once it finds out that there is nothing to do, it will go to sleep. It will also tell the chest and the transport belt to wake it up when something is moved away from the chest, or new items come on the belt, but until then, the inserter is deactivated so it is not using any cpu. You can notice that also some of the belts have red circles on them. They are deactivated as well, because all of the items on them can't move as they are blocked. Once the item that is blocking their front items will be moved again, they will get notified and activated again.

This system of deactivation of entities is very effective as most of the entities are just waiting for something. Empty station waiting for another train to arrive. Fast inserter waiting 30 seconds for the assembling machine to craft another complicated item etc. etc. In the mentioned save 6/7 of inserters are deactivated now, so the overall updates per second is almost doubled. The next thing we will have to take a look at are the transport belts, as they are the most CPU drainers now, but it will have to wait until 0.12.

The fascinating aesthetics of typical PM inspired us to change the graphics direction entirely.

The regular comment thread at our forums is ready.