Mk. 4 Belt cannot accomplish 450items/min when using mergers/splitters

Question

So a user (Eila) on the discord reported this in the #math & meta channel, and then I was able to reproduce it in my own factory.

Essentially, when you produce high speed connectors at a rate to use exactly 450 quickwire per minute, you experience a slowdown, even though productivity should stay at 100% (theoretically).

If you have 5 quickwire assemblers all creating 90 quickwire/min, using a simple line of mergers, and then the last merger should be outputting 450 quickwire/min, and then you feed that into a line of splitters going into 4 manufacturers, with the last one overclocked to 150%, this should exactly use 450 quickwire per minute. If you let this run for a while, you will see that the last two assemblers producing quickwire actually get backed up, because not all of their output can get out.

I believe this is because a merger doesn't actually support a full 450 items per minute, it is a few less, and over the course of a few minutes, this lack of speed prevents the 5 assemblers from truly running at full speed, which also prevents the manufacturers from receiving a full 450/min. It's a setup that should work at 100% productivity in theory but there's some sort of game bug preventing it.

Comments

G'day Sir, Mam,

And all this will cause shipping delays and customer dis-satisfaction. I feel ya!

Did you notify Caterina Parks? Maybe she'll dispatch a tech team.

You must also have noted that each conveyor junction creates a delay acting like a break to each part meeting said junction. A nuisance I tell ya.

At lower level tech, them conveyors still keep up with the cloock as documented in our last quarter report by our synchronisation and timing team, they made quite an extensive excel workbook about these issues, along with power consumption scada discrepencies and combustible enegry release expectancy.

I ordered an Industrial Cooker and pipes for the water in the next patch in order to research and produce industrial glue using them pesky bushy tales hogsies carapaces piling up in our warehouse, accumulating dust and using valuable storage space. This glue should smoothen them conveyor junctions some and make them as smooth as a Lizard doggo's nose, so warm and... glistening to say the least.

Cheers

---

You made my day for some reason and I needed it.

Answer 1

I have an alternate idea about what is going on here. It's just a guess, as only the developers know how the code is actually written.

A factory network is made of a bunch of conveyor segments and machines. Say you set up a loop of 10 conveyor segments.  The game had to simulate each segment one at a time, then move on to the next.  In the example below I did this, filled up the conveyors with items and took one item off the conveyor.

In a real conveyor you would expect the entire conveyor loop to start moving, but you can see below it only moves in segments, one section moving before the next.

I think what is happening is because there is only one empty space, when the sim runs only THAT conveyor can move.  The sim makes a pass over all the conveyors, updating each of them once every simulation tick.  This would work perfectly if all you had was one conveyor and the game could simulate it from beginning to end in order, but factories are way more complicated, and can even have loops.

So what you get here is a belt that is clearly moving WAY slower than 450 items a minute.  It's a worst case scenario, but illustrates what is going on with the 5 merger issue. I think occasionally due to the order belts are updated, a belt is getting stalled, just for a single game simulation tick, but with a full belt those little glitches add up and you get that 1% loss of capacity.

In short, a belt can't move unless there is an empty space it can move an into, and if the machine/belt/joiner a belt is feeding into hasn't been updated yet, it will take an extra tick cycle to move, causing a tiny loss in speed.

Comments

Thank you for this example! I knew there was a difference between my calculations and the ingame performance of my smelter lines!

Answer 2

So, I've got good news and bad news. Good, in that we now understand mergers enough to be able to answer problems like this. Bad, in that we now know that the 5 assembler long alt. Quickwire manifold is impossible (4 should be just fine though). 
<!--
The problem with Eila's mergers is that we aren't merging five 90 ppm inputs, we're actually merging two 450 inputs on a single merger. That kind of merging produces gaps like shown above, which make it impossible for the mergers to output a whole 450 ppm. 

Because 90 parts per minute is the average of the actual value, 12 parts every 7.5 minutes, we will look at that case instead. 

<!--

Because our items are on conveyors and moving, It's naturally easier to express distances in time rather than length, especially because the measurement of distance in of itself is almost impossible in Satisfactory. As well, the best way to express a set of items is by presenting it as a packet of individual frequency(f) in ppm from the conveyor itself, which I consider to have a flux(ϕ), to ease diction.   Because of that, I'll be using the distance Δt to represent the length of a single packet, and ΔT to represent the distance between packets which are produced from the same machine. This problem is simpler in that the flux and frequency are the same, but if we had 900 ppm belts that would be a different story. 
So, pulling out some equations that I've developed (made up) these past couple of days (I can give a more detailed explanation to anybody interested), 
Δt = (n-1)/f    : where n is the number of items in the packet.Two packets on a line right next to each other must have the time length of a single item added in between to account.

ΔT = ΔT_c - Δt : as shown easily enough in the diagram

ΔT_c = 1/f_c    : where f_c is the cycle frequency, this is the number of cycles a machine makes in a minute (7.5 here) 

t = L/ϕ             : an item's length divided by belt speed

starting off with two assemblers, the time it takes for every item to come out of the first assembler is just Δt. I'll call our packets P(t) for semantic simplicity. 

A (t1), the very end of the packet is L/ϕ in front of the merger, which will be the origin of the system. This means that  P1(t1) = L/ϕ

Why L/ϕ in front of the merger? This is because our second packet, from the second assembler, must be able to fit on the output conveyor of the merger.  Any delay between P1 getting to L/ϕ and P2 reaching the merger is parts per minute lost, so we'll call it instantaneous. Because our packets are positioned at the very rear of the set of items, we have to say that P2(t1) = -Δt to keep our positions orderly. 

To find the actual distance time distance between 1 and 2, we can use a simple relation with no great symbolism. 

P2 + T = P1

Which, plugging in the previous relations gives

-Δt + T = L/ϕ

 T = L/ϕ + Δt

 T = L/ϕ + (n-1)/f
In this case, both f and ϕ are 450 ppm, so since n = 12, this simplifies to a tidy 12/450 min. Reconverting from time distance to actual distance, it's a surprisingly manageable number of 12 meters. 

(There are 12 poles in that second picture)

That isn't the whole picture though. If you recall the ΔT from earlier, we can calculate it right now

ΔT = 1/7.5-11/450 = 0.1088 min, this is the time it takes before the second shipment of wire rears its head. 

So going on with that in mind, since we have the ability to merge all of the packets flawlessly without any gaps in between, we can calculate its period. In this case P1 is the first shipment of wire. P2 is the second shipment after 8 more seconds. P1's final position will be dependent on the 4 other packets coming in behind. 

P2 + ΔT = P1 :Following from above

P1(t1) = L/ϕ + 4Δt + 3 L/ϕ +  L/ϕ : 4 other packets + 3 junctions + moving forward until the rear of the last packet is at L/ϕ 

P2 = -Δt      : same reasoning as the last

Plugging in,

-Δt + ΔT = 4Δt + 5L/ϕ

 ΔT = 5Δt + 5L/ϕ = 

5(11)/450 + 5/450 = 

0.1333 min

An unfortunate result, it means that the time it takes for the first shipment to get out of the merger happens to be longer than the time it takes for the second shipment to get to the merger. This is the cause of the buildup Eila was seeing in the last two assemblers. 

So, the problem isn't latency, nor a game bug, nor any other speculation, it's simply an unfortunate situation that arose from the limitations of merging items to begin with.

Comments

Honestly, the hardest thing about this problem was managing the text limit

---

Ah darn, so I see now why the glue won't help after all o.O
Loved your excel btw.
Cheers

---

I can only imagine this getting more weird when you try to merge/split stuff using mk5 and mk6 belts