Automatic asteroids balancer

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art :), computers.
Please provide if possible always a blueprint of your creation.
Post Reply
Copy link
User avatar
Puppet
Burner Inserter
Burner Inserter
Posts: 17
Joined: Mon Jan 06, 2025 4:16 pm
Contact:
Contact Puppet

Automatic asteroids balancer

Post by Puppet »

Hello Engineers !

Here's something I've tried to build for about 2 hours, and even if it seems to work I'm not happy with it because it's wonky and also takes a lot of space for what it does.
Reprocessor
Reprocessor
image_2025-07-15_115253739.png (1.17 MiB) Viewed 242 times
Some basic explanations, it gets informations about how many chunks there are in storage or a belt, then with a bunch of conditions it chooses what recipe to use, here's some conditions :
- There's missing some kind of chunk
- There's more iron than carbon chunks or other way around
- Is there enough chunks to allow to process

All of theses can emit signals and the sum of theses is made through the cable, then the selector choose the biggest value (it'll be the one to fulfil most conditions)

And the arithmetic units in the middle work with the combinator beneath to allow the signal to pass, and the machine to work (otherwise it take whatever chunks there is on the belt and crush it).

So I'm asking if some people could help me out or give tips to make this more reliable and smaller.
Here's the blueprint if needed :
Thank you for reading this unwell written post ! By Puppet :3
Top
Tertius
Smart Inserter
Smart Inserter
Posts: 1327
Joined: Fri Mar 19, 2021 5:58 pm
Contact:
Contact Tertius

Re: Automatic asteroids balancer

Post by Tertius »

A classic challenge. Everybody needs this sooner or later.

"If there is asteroid chunk shortage, convert the chunk with the most surplus"

You can do it with 1 decider and 1 constant combinator:
07-15-2025, 13-53-29.png
07-15-2025, 13-53-29.png (1.82 MiB) Viewed 205 times


In the constant combinator, you define the minimum chunk amount (and the recipes are listed, make sure the recipe values have distinct values, and they are also distinct from the minimum chunk amounts).

Conversion takes place, if some chunk type is below minimum.
A conversion recipe is picked, if the corresponding chunk type is above minimum and the corresponding amount is more than the other chunk type amount. Or with other words: if metallic is below minimum AND carbonic is above minimum AND carbonic is more than oxide, then choose carbonic reprocessing. OR if instead oxide is above minimum AND oxide is more than carbonic, then choose oxide reprocessing.

These 2 decisions need to be made for each of the 3 types, together 6 recipe decisions.

You find these 6 recipe decisions as decision blocks in the decider combinator, combined with OR. Each recipe decision is a block of 4 decisions combined with AND.

Each of the 6 blocks has these 4 entries, combined with AND:
  1. check minimum amount of desired item ("this item has shortage?"
  2. check minimum amount of eligible chunk for reprocessing ("can I reprocess this?")
  3. check if eligible chunk is actually more than the other ("is this more than the other surplus item?")
  4. pick the corresponding recipe
What's surprising is probably no. 4. It goes like this:
The EACH checks each signal on red wire. Each signal on red that's equal to the given value is set to true and eligible for the EACH at the output if the other ANDed conditions are true as well. Since all values on red are distinct, this loop will pick one recipe per EACH - the desired recipe that belongs to the corresponding block. This is a poor man's select/case known from programming.
07-15-2025, 14-18-23.png
07-15-2025, 14-18-23.png (192.93 KiB) Viewed 205 times


About inserter wiring: To avoid recipe toggle, it's mandatory to read the hand content of the inserter moving items inside the crusher. Otherwise it's possible the recipe goes away while the inserter swings, because 1 chunk is gone from the belt, so it's possible this item is not max surplus any more. The other inserter reads hand as well to update the chunk amount on the belt a little bit faster. The latter is optional, the former not.

The crusher CANNOT be set to read its content, because this could produce a feedback loop and will end up the crusher crushing due to the chunk signal having priority and not reprocessing. You can avoid this feedback loop by isolating the output of the crusher from the belt content with another combinator, but this is really not necessary. In the given setup you can even add more reprocessing crushers without needing to isolate signals.
Top
User avatar
Puppet
Burner Inserter
Burner Inserter
Posts: 17
Joined: Mon Jan 06, 2025 4:16 pm
Contact:
Contact Puppet

Re: Automatic asteroids balancer

Post by Puppet »

Insane ! Thank you really much @Tertius !
It's really simple and small, and thanks for the explanations I've understood almost everything, just the EACH trick is a bit hazy for me to understand, I'm thinking this acts like a filter to choose the correct recipe ?

Anyways thanks again, i'll make sure to use that for my space platform.
Thank you for reading this unwell written post ! By Puppet :3
Top
Nidan
Filter Inserter
Filter Inserter
Posts: 324
Joined: Sat Nov 21, 2015 1:40 am
Contact:
Contact Nidan

Re: Automatic asteroids balancer

Post by Nidan »

Puppet wrote: Wed Jul 16, 2025 11:01 am Insane ! Thank you really much @Tertius !
It's really simple and small, and thanks for the explanations I've understood almost everything, just the EACH trick is a bit hazy for me to understand, I'm thinking this acts like a filter to choose the correct recipe ?
Picking the correct recipe is the overall goal, yes.
This setup is a neat little trickery with Each that allows merging multiple combinators into one. The conditions using Each are constructed in a way that only one specific reprocessing recipe signal can ever match them, and that match then gets used in the output.
To convert into "classic" logic, each AND group would have to be split into it's own combinator. Then the conditions using Each can be removed and the signal Each was compared with moved input the output section. The blueprint shows this conversion, all three sets of combinators will produce the same result.


You could check 124776 for posts discussing "priority map" for more details, but they're spread throughout the whole topic. Might still be worth a read regardless as it contains an interesting collection of other circuit things that became possible with 2.0.
Top
Post Reply

Return to “Combinator Creations”