Since 2.1.12 released earlier today, the link to the changelog for it has disappeared. Not much else to add but I suppose I can attach a screenshot:

Did you try passing --start-server (or --create) with the name of a save file? The --load-game might just be an outdated error message that was overlooked.

This sounds the same as the issue I reported earlier: 134255

Yeah I noticed that the internal buffers of machines that have fluid passthrough are now part of the pipeline itself. Not sure if that's intended or not.

I can also add to this issue, it's messing up any setup I have that uses 2 legendary stack inserters to fill a belt lane. It seems like the timings are a bit off so the inserter ends up leaving gaps where it doesn't swing over the belt in time. They do seem ever so slightly slower visually as well ...

Shattered planet works differently; if you don't add any conditions to it the platform will instantly go to the next stop in the list. This is so you can automate flying only partially towards it before turning around. I didn't check the save yet, but since you say your stops are only solar system ...

My suspicious was correct, this issue is somehow caused by the new tiles not being populated in the autoplace_settings. The following console command will fix the problem on a migrated 2.0 save:

/c local mgs = game.surfaces.fulgora.map_gen_settings
mgs.autoplace_settings.tile.settings["oil ...

My suspicious was correct, this issue is somehow caused by the new tiles not being populated in the autoplace_settings. The following console command will fix the problem on a migrated 2.0 save:

/c local mgs = game.surfaces.fulgora.map_gen_settings
mgs.autoplace_settings.tile.settings["oil-ocean ...

planet-map-gen.lua was modified for Version 2.1.7 to include the new "oil-ocean-shallow-2" and "oil-ocean-deep-2" tiles to the autoplace_settings - as well as the new decorative entities.

It makes sense that these new tile types would alter new-chunk generation, leading to the not-smooth ...

This is a really weird issue to even describe. My lab blueprint exhibits a strange behavior when building it over top an existing instance of itself, where all the belts get flipped across, thereby swapping their lanes. I've provided this blueprint book to reproduce the issue, which is more or less ...

You use it like an actual tripwire. Connect a whole chain of mines in series with a single wire, put a constant combinator at one end and read the signal at the opposite end. When a mine goes off the wire will be broken causing the signal to go away.

Linux users are also seeing this exact same problem.


Ah, very interesting then. The apparent window focus behavior just made me think it was a Windows thing, since Windows does have a system for prioritizing the focused task over others. Still Factorio isn't really in control of which cores it ...

Yeah this just sounds like Windows scheduler fuckery. One of the reasons Linux is known to be better for Factorio.

Klonan wrote: Tue Jun 23, 2026 6:06 pm Duplicate of this 134141

Whoops my bad! I forgot to check the subforums. Thanks and looking forward to 2.1.8!

I assume all turrets are affected, but I only checked gun turrets on space platforms, as that's where this issue is most problematic. They seem to lock on to targets just outside their range, and will not choose a different target until the current one is either destroyed or goes outside the ...

I wonder if 2.1 inserter flipping also flips the pickup lane...

Most of your math checks out, with the notable exception of the 200 prom chunks per second for each cryo plant. It's not really possible to get more than 120 per second, as it takes 8 legendary inserters to consume a whole turbo belt (60/s) of chunks, due to the lack of stacking. A cryo plant has 20 ...

Inserter throughput when picking from “non-perpendicular” belts is always lower because the arm has to “reach” farther to grab items as they go around the corner.

Good Luck!


Right, but the issue is that even when the items are on both lanes, the throughput is affected by which direction the ...

I'm curious, how difficult will it be to update a 2.0 planet mod for 2.1 compatibility? Specifically in regards to the background planet parameters and textures. Do we have to define that stuff? Or can we omit it and the mod will work fine just without a background planet, in order to just get the ...

KoBOLTA wrote: Sun Jun 07, 2026 5:19 am i figured out that i have near maximum usage of memory by factorio (all 32+ Gb), my bad that i didn't checked that

Yeah I wasn't sure how all the memory use could be from Factorio, so I thought maybe it was a driver misbehaving or something.