Design Challange: Smart Asteroid Processing!

[h.q.droid]

This is incorrect, as you can use asteroid reprocessing, albeit it wasn't part of the "challenge", this receipe will reduce the amount of asteroid no matter the crushing productivity.

Reprocessing can give you 3 chunks back at 0 productivity. It's 3 independent rolls, not a single roll.

Doesn't change the fact that the recipe isn't affected by crushing productivity and that you will not clog your machine with it eventually no matter how hard you try to generate extra asteroid with it.

You need space for that. If you start with clogged storage, there's a good chance that your reprocessing crusher clogging itself up instead of cleaning things up. Even though the expected change is negative, as a random process the maximum fluctuation is the true eventuality.

[mmmPI]

You need space for that. If you start with clogged storage, there's a good chance that your reprocessing crusher clogging itself up instead of cleaning things up. Even though the expected change is negative, as a random process the maximum fluctuation is the true eventuality.

No the chance is low initially and it becomes worse very fast to the point of statistical impossibility.

There's (1−0.4)×(1−0.2)×(1−0.2)=0.6×0.8×0.8=0.384(1−0.4)×(1−0.2)×(1−0.2)=0.6×0.8×0.8=0.384 chances of loosing a chunk
Then
First roll positive, others negative: 0.4×0.8×0.8=0.256
Second roll positive, others negative: 0.6×0.2×0.8=0.096
Third roll positive, others negative: 0.6×0.8×0.2=0.096
So, total probability for exactly one positive roll is: 0.256+0.096+0.096=0.448 chances of just transforming the input into another thing
also
First and second rolls positive, third negative: 0.4×0.2×0.8=0.064
First and third rolls positive, second negative: 0.4×0.8×0.2=0.064
Second and third rolls positive, first negative: 0.6×0.2×0.2=0.024
So, total probability for exactly two positive rolls is: 0.064+0.064+0.024=0.152 chances of +1 chunk

And
All 3 positive , 0.4×0.2×0.2=0.016 chances of +2 chunk

Those won't change over the game, since no asteroid prod on this recipe. You can run simulation many times, you don't need much space to guarantee no problem ever occur.

[h.q.droid]

You need space for that. If you start with clogged storage, there's a good chance that your reprocessing crusher clogging itself up instead of cleaning things up. Even though the expected change is negative, as a random process the maximum fluctuation is the true eventuality.

No the chance is low initially and it becomes worse very fast to the point of statistical impossibility.

There's (1−0.4)×(1−0.2)×(1−0.2)=0.6×0.8×0.8=0.384(1−0.4)×(1−0.2)×(1−0.2)=0.6×0.8×0.8=0.384 chances of loosing a chunk
Then
First roll positive, others negative: 0.4×0.8×0.8=0.256
Second roll positive, others negative: 0.6×0.2×0.8=0.096
Third roll positive, others negative: 0.6×0.8×0.2=0.096
So, total probability for exactly one positive roll is: 0.256+0.096+0.096=0.448 chances of just transforming the input into another thing
also
First and second rolls positive, third negative: 0.4×0.2×0.8=0.064
First and third rolls positive, second negative: 0.4×0.8×0.2=0.064
Second and third rolls positive, first negative: 0.6×0.2×0.2=0.024
So, total probability for exactly two positive rolls is: 0.064+0.064+0.024=0.152 chances of +1 chunk

And
All 3 positive , 0.4×0.2×0.2=0.016 chances of +2 chunk

Those won't change over the game, since no asteroid prod on this recipe. You can run simulation many times, you don't need much space to guarantee no problem ever occur.

I agree with your probabilities.

I ran 10k simulations. On average it takes 750 cycles to jam a 2-belt buffer (8 asteroids) and ~40k cycles to jam a 4-belt buffer (16 asteroids), both reachable in realistic play times. I think 6 belts are jammable too. Guess the lesson is we need a bigger cache.

[mmmPI]

I agree with your probabilities.
I ran 10k simulations. On average it takes 750 cycles to jam a 2-belt buffer (8 asteroids) and ~40k cycles to jam a 4-belt buffer (16 asteroids), both reachable in realistic play times. I think 6 belts are jammable too. Guess the lesson is we need a bigger cache.

I think this is wrong for at least 2 reasons,

1) you can fit 16 asteroids in a 2 belt buffer not 8.

2) it makes no sense to think you are going to do 40K cycle of crusher without touching at all the products and let them pile up "realistically."

[Tesse11ation]

Here's my solution.

12-20-2024, 03-22-10.png (891.08 KiB) Viewed 384 times

0eNrFnF1v2zYUhv+KoIthG2RXoj4sGSiG3vR6wAbsIg0MWqYjrrKkklTaIMh/35HkrzhyIunNUBRoHYl8SR4+hx/nuHm013ktKiULYy8f7Y3QqZKVkWVhL+2/M2FxbYQq5cZKyzwXqSmVJbVVFtYXWwtjbWVO7/UX29qVGzG3PlG5QhteGPqwW8uCNzWopLa4Rc+NTC0lvtVCU116I3iaHduYW/9korB4cWqVKyXvRdugod7IoqqNtRZ5V5tbqap1JpTTVlLSZDvRNHHWthJ8o9vKbTVe0FB4kYq8e9gNwKoLI/NTKRqi2FXmYf6l+FKQGUrVyPI8f3CoEL39LvPcKsQ9Vf2X76xfeW6ysr7LWgld8VR0o6V+Z/W6K06lC1M3Ik2rOT00GXVPl7VKhf6tbeszb0wsS+tzqeqdtnJZfLVM2TWaZlRZFHdiaWXGVHr54cO2LTbf7qvNaeAf7qX4bspKpvMqq/7Yfox/MR89L4nD2HZs2cyPvbx5tLW8K3jezHrBd4Km+2D02XGq7SeqUGzED3vpPTl9VY4mn51MflaLPd06No1aGim6VtsfHlZFvVsLRbLOK607dlVq2cH4aJPcLJiHjv1AHzx/HlIzNBijyny1Fhm/l1SFyqVSpbU0K1HwdS429tKoWjjHx1Rlc9TcSqXN6jQs81A1fbmXqpko+9i5rsRMkVzXaou4vXSbH3YVV+24l/bH9vW+JaJ+tfePrhP07hvJ0vipqOJKUAM0/3VuZrJo4CgVvSnqPG+MfWEpduzMoflzk780FTuairWm2khFVm0LeKzfcroroJ9/pkk7MODYx/E8e7rvGIFAgBILp7nM6uKrfT7solS71rIXdmse1I1JW9AO+JzGzNW6LN5R2j9Klz/kRoC6t/TnqWfSTq2YmgYwM4oXuiqVmTXLzKuAu5ezFvToB2P1/XH64VF/SwYiSrVQZKdXhT0S7pGKnNcXjR6CzwQH8XsSPnm5nuDmzabUODL5AMmsTu4+I9bLSii+3yB/p6plbWhPGiveS8ti7Gx642YzHqnvjpNPRsqzcfKeO1J/JOueN1L/FV+N+/TZ5MUg7ncpb/ryklxRvFxQdEWLYL/Hn03fhXEP28TZQQHZGp6OTkbnVDrldNunvMuaEbYnwpcv+sY2fDFj54Z/PrH/4xbYnJVqLS7PDC8HEk1eJ5Ke8bx2hmoOz6uMd4ugoX7onuNU+7wr2lwCmlNfX68Xw9Fyx6CFHA3eC614MFruZLSgcQ5FKxk8EO+NxYm5U3ebnwgp8wZD6o1hdPIZ850AZWzovHqT+Zw+xoFwMn/oINy32AymHlV+JpuD9y/21vCjqSedZMhBhy2myseD5OPJp57oij2SyYqLfkX/cvGryVvUnaL74ubNq1nUd9/Z3yq6xaDPxf2znaILil2/UkU9FPdEJlJZXTnTNA3I4u5YavXCy/t6yN7uoTulgz0747QO+qNnbdCktet0b4PB2xaZNGWXa/E0c4RT/XgxxI/9yatQj6379E/L0LrOvw46ywRX3DkeLOW+JZUMlWJvKAWnNUaXOVezihci7+lSeBDqAoEX1PQpe8OUxwuzkV12hwqfPLcNvs+qnJstkT3L6vW1VaY5t+1zEaezx5XI5/OgJKcS99TYludaNMeXo4wqd6t1vd2ex3wPL3dSa3LCLp6k6raV1Y5Tu5J0rh57gmDcbAy2WThyMvyhwtG4Dg/WPTk0T9N6V+dXAod+KztQNB4o6o0RTYaJjtEM3WGa1wdPnH6nNbMB+8ZzPIc53q1zQ387kePTp4g+eVH7sPnHoRtcW8BtPgf0mQSMzPeJnEv7RPvbUPB0zRW3zT7ahU6b8b3ADBUIUIHDEHx0CD46hMkC/nv1gKE9mCzAUIFjIgK1gYfawENtMFnAAwVcsD7aPmoAdAZgBM6DQxCELgqhi0LoohC6IIQuCKELQuiCELoghC4IYQIymIAIJiCBCQhggvGXYPglGH0JBl+CsZeA6MUgejGIXgyiF4PoxRh6MYZejKEXY+jFGHoxiN4CRG8BorcA0VuA6C0w9BYYegsMvQWG3gJDbwGiF4HoRSB6EYheBKIXYehFGHoRhl6EoRdh6EUgeiGIXgiiF4LohSB6IYZeiKEXYuiFGHohht5k0y/2eQow7oZGDtHAYQCiH4DoByD6AYZ+gKEfYOgHGPoBhv7U6iB5KPh7x/NBx0Pj3WiwGY12+6Dj+aDj+Zjj+Zjj+Zjj+Zjj+Zjj+Zjj+Zjj+aDjMdDx0BQHAx0PTfKgOR4GOh7DHI9hjscwx2OY4zHM8RjmeAxzPAY6noemeNG0DprVQZM6aE4HTemAGR0woQPmc8B0DpjNwRzPwxzPwxzPxfwOTGSBuVQwkwrmUcEsKpZDxTKoWP4Uy55iuVMXcjYX8jUXczVwiwN3OHCDA/c3cHsDdzdsc8P2Nmxrw3Y2bGPD9jVsWwN3NfAaB97iwEsceIcDr3DgDQ67wGH3N+z6ht3esMsbdnfDrm7gzQ0MVYKRSjBQCcYpwTAlGKXEgpRYjBILUWIRSixAicUnsfAkGJ0E03FgNg5MxoG5ODAVB2bisEQclofD0nBYFg5LwmE5OCwFB9IKfmkC/M4E+JUJ7BsT2BcmsO9LYF+XGFb71rGlEbvmv2sef1GiY+d8LXJ69teOK2N9Ovy2wj9VmQqtS2Xd/E3/Cs9rVW6pxr1Quu1BGLEkSJIwSFgcBe7T03/H2IFu

Copy blueprint

The asteroid collector is on "set filters" mode. A constant combinator sets a static request for each asteroid. When an asteroid arrives on the input belt for a crusher, an arithmetic combinator reads the belt and cancels the filter until the belt is empty.

Theoretically, this will never jam (although the space station hub will eventually fill with resources).

[Tesse11ation]

Also I think it's worth mentioning that OP didn't challenge us to design the smartest, most efficient full stack asteroid crusher. He simply gave us a design challenge with some constraints, which is fun. There's no point to taking part in the challenge if all you're going to do is complain about the Inefficiencies of said challenge.

That being said, I think a more practical challenge would be the following:

You must create a full stack asteroid processing pipeline with the following constraints:
* The machine may not jam at any time (i.e. any and all crushers must be able to work and process asteroids continuously).
* You must have at least one asteroid collector, and at least one crusher. Belts are optional.

Bonus design considerations:
* Asteroid reprocessing, dynamic recipe setting on crushers, and dynamic filters on collectors are encouraged.
* Dumping asteroid chunks into space is allowed, but should only be done to prevent jamming in order to minimize waste.
* Try to collect as many asteroids as you can and only use filters on collectors to prevent jamming. Reprocessing is preferred over filtering.

The winner is scored on the following factors:
* Footprint - how much space does your asteroid processing take up on your platform? (Smaller is better)
* Throughput - what is the sheer volume of asteroids that can be processed at once? (Higher is better)
* Control logic - how many combinators worth of overhead is required for your design to work? (Less is more)

Footprint and throughput are in direct opposition to each other, so we'll fix this problem by scoring them together as a function which is footprint in tiles (F) divided by throughput of asteroids per second (T) for optimal processing (O), or F / T = O.

[Tertius]

There is no best or most efficient solution in general, because results vary according to the game stage and available items/recipes. Do you just want the fastest/smallest setup, no matter the energy cost (speedup) or item availability (quality)? Such solutions are not practical except in the latest game stages.

The challenge definition changes solution designs vastly. What is the intended use for the output? Just fuel production? Or also science production? What recipes are allowed, just the simple crushing recipes or a complete factory with advanced asteroid processing? How's the energy availability? All this defines the required/possible output throughput and output material ratio.

If just fuel production is the goal, asteroid reprocessing just isn't needed, because there's enough asteroids already. If you need very high throughput for a big ship, you might need a completely different concept with advanced recipes and speed boosters instead of the simple recipes.
Also recipe switching. With recipe switching, you reduce the number of crushers, but you need space for the combinators, and you need to make sure the remaining crusher(s) are fast enough to keep up throughput. I once made a nice recipe switching build with just one crusher. On paper, this was optimal by footprint, but actually it wasn't fast enough to keep up throughput. Challenge submissions should be practical and should be usable as driver for a real platform.

In my opinion, if you want a challenge, you should define multiple categories: early space game (just simple recipes for fuel, gun ammo and space science production, no quality), mid space game (what you need for fuel and ammo in a self containing ship to Aquilo, undecided how much quality to allow), end game (all recipes, all quality, focus output volume).

Take this example:

combinator_16245621_416x480.png (444.86 KiB) Viewed 352 times

0eNrtm9tu4zgMht/F187A8ikH7O6LFEGg2EoijC1nZCudbpF3X0p2HDeHNu3fwxRYoBdyLFI0+YkiBfTRWxZGbLVUjTd79GRWqdqb3T16tVwrXtjfFC+FN/PqLc/EaFvwZlXpcrQxS2/ve1Ll4rc3Y/u57wnVyEaKVt49PCyUKZdC0wT/oIfXjdCVzEdZVRQiayrt+d62qkm0UnY9UjeKfyS+90CDyY+EViGrGl0Vi6XY8J0kCZqWSZ0Z2Sxq0SxWsiCltHCjjfD7V1rwfGFlyZjuJSnTojZFM5JqRz9XmlZRpij2/pnNYW9zpk29EZcMDVsz06tmWvO0yORWDAxoH73qt8zF6OgQu4pUa+8wZfHL8IIsoqmKfE7hIIc3omw9LPNBdMRqJTMpVPYwKqvcFGIUuvC0s2myWgw+2Eofn2Lfqxue/fRmgfXCxTcU4D39nTspetlJAeKjjOtlpWT2zd0Uv+wmCKVSNLwovr2bkt5NUtVCN5f33CE5xM5VuaTva99PLqhMe5VFpdajDaeMlY+eUR8d1Cevzz00v392bmmzY2/ChTBtjPpJVlwITlaVW665zZAz72+v9aZTOMhM59vjLQqPu/g0J92ujU4AU4tTf5zFY3xLiIPrIX4+Ii7l2xif5P3joeBeummEtrAsXjBycouR7KmRz5klFF8WIj+1hUTyXuVK6pqQOj13ZSa8VjttHntKx+MT3//l3r+vA6Y3OIB9cZBYcIORwacEqd2GXxAnxm7wQfg5oOpKjSr9FbSyY0LM6azLhabqslxKxS+Xl0nvkCvu6LQcv9sde8Onu3M/NA/uKN5J3RiXIQ+Vs5sxEjzb2G+vhdXzerknXvzH85+sv1Ciua/0T2enPgZwrYWgz17xohana5/LuGm9kEvgNq1Xptma5rQvuNns7QP50Sg6KnVVUuFAug4WURlwKZyDorID6cZ4hs8UT1kfx+P4yRn9YSe3/cHYzcCidz/EL+t+h/N8qHh+LVDxKwMVf5dAfWCcPipM16OUvC47xv9nx0/LjrcYdi2sx87mwt3MlS48uBLS7oTdUcPo0vTBkOHvTTXoO38ZUQ+anyt79ek24jRjJ/rcP1BjD4alWa2GjdThZSnr2i7vMow2bpVFyWldSXq66aSszjbC9qqtBUVFRFR2PfvM0sGE9nuzSudd0Bre+oncaXayJt/d82HR005rCROLLrJUl9DE7sF2xu0h5zbky8US/Sw4harka/6vVCdFE0uCM6K7hvlo7M4UGVfmDzA3DG4wd12IJf8mtq5Msa40/3NBmLvMc0+y1qQ75oc+1cDx3L9L7TBxw4kdBn54GCZuaH/xqW1wYyeYtmMa+VR5sXbcK6QznllZNqcVG3nYX6eHRtoeGdP9taS0IqfkrYOts89KOFA+BuU7+yeg/RPQ/jfLR6B8CMozTD7AxMHV0Y/v4BmD8IxBeMYgPGMQnjEIzxiDZ4zBM8bgGYPwpCA8KQhPCsKTgvCkIDwpBk+KwZNi8KQgPAkITwLCk4DwJCA8CQhPgsGTYPAkGDwJCE8MwhOD8MQgPDEITwzCE2PwxBg8MQbPW8VR33fsRSB7EcheBLIXgexFIHsRxl6EsRdh7EUYexHIXgiyF4LshSB7IcheCLIXYuyFGHshxl6IsReC7DGQPQayx0D2GMgeA9ljGHsMY49h7DGMPYaxF2DoBRh5AQZegHEXYNgFEHUBBF0AMRdAyAUYcWCyA3MdmOrATAcmOizPYWkOy3JYkgNzHFjagZUdWNiBdR1Y1mFVHVbUYTUdVtKBFR3YyIJ9LNjGgl0s2MRiPSzWwmIdLNbAgv0reG0H3tqBl3bgnR14ZYfd2GEXdth9HXZdd5v0vP1PD5p0/N8w39sJXTt9SRpO4+k0iafhJI2D/f4/b5WBug==

Copy blueprint

This is optimal in terms of space footprint and actual platform use, but only for the early game and inner planets: It doesn't use any belt and the minimum possible number of inserters. The three tiles used for the long handed inserter filter creator can be replaced by 2 additional inserters moving asteroids from the collector to the hub, using just 2 instead of 3 tiles. But this would make the whole setup not practical any more for real platform use. The given setup can be easily extended with more collectors without much more space footprint and just 1 tile consumed of the precious space around the hub.

But as soon as you unlock the advanced recipes everything changes, because suddenly fuel is quasi unlimited but ammo not, so you need to design a completely different asteroid processing setup.

[Tesse11ation]

With recipe switching, you reduce the number of crushers, but you need space for the combinators, and you need to make sure the remaining crusher(s) are fast enough to keep up throughput. I once made a nice recipe switching build with just one crusher. On paper, this was optimal by footprint, but actually it wasn't fast enough to keep up throughput.

Why not both? Have multiple crushers that set recipe based on which asteroids are the most abundant, thereby increasing throughput.

[Khazul]

Also I think it's worth mentioning that OP didn't challenge us to design the smartest, most efficient full stack asteroid crusher. He simply gave us a design challenge with some constraints, which is fun. There's no point to taking part in the challenge if all you're going to do is complain about the Inefficiencies of said challenge.

That being said, I think a more practical challenge would be the following:

You must create a full stack asteroid processing pipeline with the following constraints:
* The machine may not jam at any time (i.e. any and all crushers must be able to work and process asteroids continuously).
* You must have at least one asteroid collector, and at least one crusher. Belts are optional.

Bonus design considerations:
* Asteroid reprocessing, dynamic recipe setting on crushers, and dynamic filters on collectors are encouraged.
* Dumping asteroid chunks into space is allowed, but should only be done to prevent jamming in order to minimize waste.
* Try to collect as many asteroids as you can and only use filters on collectors to prevent jamming. Reprocessing is preferred over filtering.

The winner is scored on the following factors:
* Footprint - how much space does your asteroid processing take up on your platform? (Smaller is better)
* Throughput - what is the sheer volume of asteroids that can be processed at once? (Higher is better)
* Control logic - how many combinators worth of overhead is required for your design to work? (Less is more)

Footprint and throughput are in direct opposition to each other, so we'll fix this problem by scoring them together as a function which is footprint in tiles (F) divided by throughput of asteroids per second (T) for optimal processing (O), or F / T = O.

I have never had to dump asteroid chunk into space. Why is footprint and throughput considered as being in opposition? Very high throughput may need more control especially on a route with an uneven selection of asteroid types (aqillo comes to mind with excess ice). My end game legendary science vessel has a huge control and belting/routing section on it for various reasons. My simplest first ship into space type thing just has the bare bones of the same patterns.

Dynamic recipe selection works great in some scenarios but not others (excluding reprocessing which should always be dynamic IMHO).

The throughput that really matters is on the other side of crushers - ie are all of you chemlabs, foundries etc getting the resources they need the instant they need them, or at least at a rate to satisfy whatever is downstream from them?

Are there circumstances for the ship that demand much higher throughput from collector to storage to minimise the time spent out there? (for eg high collection rate promethium science ships).

In cases where the throughput demands on the product side are very high, how do you ensure that crushers can satisfy that demand for eg when the demand is basically one or more stacked green belts).

How to deal with dual product recipes - for eg copper + iron when the demand for either does not match the output ratio of the crusher while also minimising what gets dumped overboard - ie dont dump something when doing so could possibly starve production somewhere?

Do you apply filtering to collector and their inserter? Do they operate off the same filter control/quotas? Why and under what circumstances might they be different?

The broad pattern I most use for my ships would likely fail badly on your measurements and yet works really well across my ships from early game first ship to late game high asteroid chunk and product throughput legendary promethium science ships. Not all element are present on all ships of course due to size constraints, and needs (throughput etc) and researched tech.

[mmmPI]

Why is footprint and throughput considered as being in opposition?

That seem fairly obvious to consider that a bigger platform can have larger throughput because there is more room to process things on it x)

[Khazul]

Why is footprint and throughput considered as being in opposition?

That seem fairly obvious to consider that a bigger platform can have larger throughput because there is more room to process things on it x)

If you want the highest throughput in general, then you probably want direct insert rather than belts being involved.

[Shulmeister]

Why is footprint and throughput considered as being in opposition?

That seem fairly obvious to consider that a bigger platform can have larger throughput because there is more room to process things on it x)

If you want the highest throughput in general, then you probably want direct insert rather than belts being involved.

Correct me if i'm wrong but this isn't related to the size of the platform, any platform can use direct insertion, big or small.

The large platform will have a higher potential throughput because more asteroids will be generated during the travel.

[mmmPI]

Correct me if i'm wrong but this isn't related to the size of the platform, any platform can use direct insertion, big or small.

The large platform will have a higher potential throughput because more asteroids will be generated during the travel.

I don't think it's wrong to say that any platform can use direct insertion, big or small. I think it's fairly obvious that direct insertion builds can have more throughput in the same footprint as less dense build. But i think it's irrelevant in this context because having 2 or 3 or 4 builds with direct insertion stacked together can only increase throughput. Thus quite obviously allowing larger platform to have larger throughput.

More asteroids are generated during the travel for "wider platform" with similar speed. But it doesn't necessarily mean the player will harvest them all with asteroid collector, and it doesn't mean that harvested asteroid won't be thrown overboard later, or even worse processed and then the result is dumped in space. Although i do agree it's another obvious illustration of the relation between footprint and throughput.

[Shulmeister]

I don't think it's wrong to say that any platform can use direct insertion, big or small. I think it's fairly obvious that direct insertion builds can have more throughput in the same footprint as less dense build. But i think it's irrelevant in this context because having 2 or 3 or 4 builds with direct insertion stacked together can only increase throughput. Thus quite obviously allowing larger platform to have larger throughput.

Ok, that seem fair.

[adam_bise]

I like to keep a buffer of each asteroid type in the collectors.

I have to put a decider at each collector with each < 9 out each to collector filter, and a const with each type going across all the inputs. Then i set filters on the inserter that grabs out asteroids.

Nothing gets thrown over and asteroid shortage on the asteroid sushi is bumped back up quickly by the collector buffer.

The downside is 1x2 tile cost x number of collectors for the deciders. I havent personally found a better setup for the collectors themselves.

Its worth noting that the 1x2 decider footprint would have held less asteroids if it were a belt instead.