[2.0.62] Build order affects belt throughput of direct-to-splitter mining

[HeliGungir]

Factorio Screenshot 2025.08.03 - 00.24.14.01.png (1.27 MiB) Viewed 1442 times

Save:

Mining to splitter build order bug.zip

(1.39 MiB) Downloaded 73 times

Context:

At high mining productivity, mining directly into a splitter is one way to increase the drill's output. The splitter must be oriented perpendicular to the miner for this to work.

Expectation:

The left copy of each mining drill is outputting a full belt, which is the expected behavior. This happens when the splitter is built after the belts, or during the same tick as the belts if I pause the game via the editor.

Bug:

The right copy of each mining drill is not outputting a full belt, which is undesired behavior. This happens when the splitter is built before the belts.
All variations of rotating, flipping, and using copy/paste/undo seems to be consistent with the above observations.

Related:

Inserters also drop items more quickly to splitters than to belts. The throughput of this was lower when 2.0 came out, and when this was reported as a bug, the old 1.1 behavior was not considered sufficiently "expected behavior", so it was not restored to 1.1 speeds. I disagree with that decision (suggestion thread here) and I certainly do not want a similar "fix" to direct-to-splitter mining.

[Magistrat]

I did some testing on 2.0.64. I can confirm that the splitters get faster when you replace them manually.

But when the belt flow stops once and continues later, the splitter is slower again. Wich would be the same as building the splitter first and belt connections after, as in the bug report. There was time for the ore to build up on the splitter parts.

[Rseding91]

Thanks for the report however I don't consider this to be a bug. This is a simple belt-update-order observation where *some* transport line will be first to update and when splitters/side-loading are involved there's no perfect update order the game can determine. As things flow/move/go-active/go-inactive that order may change.

In the same way that there is no guaranteed update order when it comes to inserters, there is no guaranteed update order when it comes to belts. The engine *tries* to "update the front-most belt first" otherwise they would have issues in many many places, but when it comes to setups involving side-loading, and splitters, and circular belts, there is no perfect "front" belt.

[Zettroke]

Also encountered it.
I could easily live with that if it was just build order.
But the fact that it reverts back to being slow after belt backs up once, makes this tech (sideloading a splitter) kinda useless
It's not that hard to get miner to output >0.5 of stacked belt, especially on Fulgora

[Yodo]

when it comes to setups involving side-loading, and splitters, and circular belts, there is no perfect "front" belt.

I don't quite see how side-loading and splitters preclude having a natural update order, but I agree that there's no way to fix looped belts. From what I understand, the lanes are updated individually, so the update order for a splitter should update for the left lane after the left lanes of both outputs have been updated, and for the right lane after the output of both right lanes have been updated. For side-loading onto a belt, the lane that loads onto the belt further downstream should update first, and the lane that loads upstream after that.

There could be engine/other reasons why this update order doesn't work, but I don't know of any.

Edit: Splitters need to update the lanes together for some animation reason (see Technical Factorio Discord), in that case they should update after all output lanes have updated.

In this image you can see the suggested update order labelled in red.

lane_update_order_suggestion.png (389.92 KiB) Viewed 91 times

Edit: I forgot that transport lines existed when I wrote this post, image that the max transport line length was set to 1 tile for the image, instead of 200.
Transport lines can also sleep, I guess that could complicate yhe update order.

I include update numbers for the miner, loader and infinity chest for completeness.

In terms of workarounds:
- make sure there is enough buffer space/underproduction that belts don't back up
- add an alarm that activates if the throughput is not full
- mine directly into wagons for (potentially) even more throughput

And maybe deactivating and reactivating the splitters or miners with circuits can change the update order?

[computeraddict]

If you don't sideload the other half of the splitter back to the other side does it work consistently? If so, isn't the workaround to just point two miners into the same splitter and get two full belts?