UPS Optimization - the full belt myth

[mmmPI]

It is surprisingly difficult to fill a belt without some inequalities. if anyone got a good system, please share.

I am not sure if it is appropriate for this task, but after using /editor command, you get access to an additionnal crafting menu that provide loader and infinity chest that provide a full belt. From that full belt you can use a self resetting timer couting to say 10, and allow a control belt to be active only when the timer is under 8, or 5, or 2 to choose the load. That may be not precise enough with those numbers as they are not multiple of belt speed so it create repeating pattern.

0eNqlVNtOwzAM/Rc/t4h1bIyKz+ANoSptvM1Sm1SOO1FN/XeSho2ywabBSyvfTo6PneyhrDtsmYxAvgeqrHGQv+7B0caoOvikbxFyIMEGEjCqCRa+t4zOpcLKuNaypCXWAkMCZDS+Qz4bkqsgGivSyGllm5KMEssTgGx4SwCNkBBGSqPRF6ZrSmR/wiWcBFrrfKk14fQA95BAD3l6f7fwZ2hirGJ0mYBvWtjWRYlbtSNf7Us+MQsf0yOOC941sZPirK0dsXTec2QUM9KX0E+QVFTQd3YfrKZVPHLM4dlX2E7a7gZM3CH3siWzieBt7zl2Roo126Yg48EgF+5wiGeb2OhIfxY+G0Y0U0FJj2r79OxCPPlmz33+MPEdhpId6R7avjyVxd3itrmsqRbkX3b0yhy6cQiTFX27RSJfWBFXHUk0TxQ5CWe/CDS/doXONZp/anQmUfazRAcax9X9/+auzhZ3+GoXjSprLDS58I/L9xVlVLrYKqMDH/FquNOMgz+mNlbjqO6fJxOl96/H+NrkkxcugVp5kb3vZctWpMawk/5Cuajnavbw+JQ9Lp9Wy/lyNQwf3/jEXg==

Copy blueprint


I have measured the belts throughput in the test to be around 33%, or 15 item per second, outside of the more dense area where it is around 23 item per second or 50 % throughput for that blue belt. Yet the UPS are not showing better results by the same magnitude, the not full belt may be 38% faster to update, it is carrying 66% or 50% less item.

Seeing this, i am suspecting that an empty belt would have better UPS that could be the control test .

I have use this contraption to measure the throughput and % but i've seen better ones :

0eNrtV8uOmzAU/RVkqZsKpoEkJEGdVbddVLNtR8iBm+Sqxka2GU0U8QH9i35bv6Q2KOQFZEhfs+gmEdg+Pr7n3HvNjixZAblErkm0IymoRGKuUXASkQdcb7STCwbOvYNScCdnVIOD3GFUaSccORqTr+oL/wirZuIbZ4WMQUpcgongikSfd0ThmlNmt9DbHAw2asjMDE4z+6QEo9LLKQdGSrOOp/BMIr90r66E51yCUp6WlKtcSO0tgekjkKB8dAlwjRqh5lI9bGNeZEuQZpdWFi7JhcI6EDticMbh3dQlWxJ507tpaZmd4QQNTgYpFpkHDBItMfFsYFoAJ3vAsQF0iYkVNwuwCtmO+PZnLQH4MWlMSTQzc1EmBerq0RzQ0CEcjFpLUUh7yOljC8FxQzCFBFOQXiKyJXKqhew779igpyhrbiSaVFS1FCxewoY+oVldWafCjM1Yis0pViiVji80fEKpC8qODFDN8B5IHQilqTVkOLJPWU5lxTEi92aFKHReDMCEJ5BbvUG+rsHzreFYcB2vpMhi5AaMRFoWUHaIII2XzyRYnErgW4+1arW41MolQae0/ugCuGzz2mSYlLNXKOX7G6R8+H0KTs6FcU+Gw4NQ1xf7Z4sX/cMvFXk6tKDMbywo54TaKkrQVlHChuFe6H4fNgSDiuCRE8N2J5pOokF2tJArLims7fyjZvJ4szu6FJo1W1OJepOBaYf9EWhqvl+2n/gA9LL0O+2Gtkl7VZO2MVBgIeJDEk7M5iIHk4J1g393Qw5+ImU5xFzzYRUw6Aj1fHCop/801P5odBrrtz2x7kYufzWP+2I9e5nLFzc2G//1NJsf377fFP6/1G3Gf+g6caURja/0qS5DWJ/ddJP874huR3RJfpnUvSIOv2G6feX6fHjaZQn/2hdZd6EYnV8GgnZf7HkBp0sGcYrK/pNoRZmCA20JNI03tK7G2vBUtTiHGfv39dRMpAZkNKTQtqRhaQWsbBMdfVK7hFFzevPugzUM2OwwnyOqPubcn8wWwSxczMNxOC/LnzoPVgA=

Copy blueprint

[mrvn]

Shouldn't you be testing e.g. a full red belt vs. a blue belt with the same amount of items?

A full blue belt and a partial blue belt is a meaningless comparison. In your megafactory you would need 2 partial (or 1 faster) belts to replace a full belt so the same amount of items arrives at the assemblers. Otherwise you are just showing that a smaller factory takes fewer UPS.

[disentius]

that is a good idea, mrvn. But this topic is about full blue belts vs partially filled blue belts. So far, partially filled belts are lighter on ups load in my tests.

[Belter]

that is a good idea, mrvn. But this topic is about full blue belts vs partially filled blue belts. So far, partially filled belts are lighter on ups load in my tests.

Yes.. but. I think the problem with tests are the U turns. For the almost full belt much-much more items slips because of the turns, and I think that's why the UPS penalty 8%->38%. But w/o U turns we would add other components which would have bigger UPS impact than the optimized belts.

[FuryoftheStars]

Doesn't the game have to still track every item on the belts? Thus, a partially full blue belt vs a fully loaded blue belt would have fewer items to track, and thus the UPS gain you're seeing?

[mrvn]

Doesn't the game have to still track every item on the belts? Thus, a partially full blue belt vs a fully loaded blue belt would have fewer items to track, and thus the UPS gain you're seeing?

No. The way the devs described it the game tracks spans of identical items without gaps. They optimized it explicitly so they don't have to track each item every tick. You can turn on the spans and gaps of items on a belt in the debug settings to see how it groups stuff.

The thing is that spans of items aren't infinite and items have to cross boundaries. So my feeling is that with a full belt that's just going in a circle all the UPS time is spend on items crossing boundaries and a full belt simply has more items. With inserters taking items off or putting items on the cost might be totally different.

Has anyone compared the time per item for the belts? Because that would be a useful number I think. Comparing a belt loop with 1000 items v.s 800 items makes imho no sense.

[mmmPI]

To me if you want to know the difference of ups between a full belt and a non-full belt, you have to measure a full belt, and a non full belt there's no way around it.

If you want to be more precise, you need to then divide the difference by the number of items so that the UPS becomes "per item".

If you don't measure the difference between 800 item loop and 1000 item loop, how can you get the " the time per item for the belts ?"

The question is about full belt vs not full belt which one is the most efficient in terms of raw UPS. In order to avoid the 0 item belt winning because that is not a helpful result, you need to account for the difference in number of item in the 2 belts measured, to answer the question : is it really better to use fully compressed belt as much as possible ?

In such case, the fact that one loop has 0 or 400 or 800 item does matter, because if your tested non-full belt has 40% or 80% of the item, you would need to use 2.5 times more of them or 25% more of them to achieve the same result of "x item moved". Hence potentially reducing the "ups gain for the total number of item carried".