Simple way to prevent asteroid collector from overfilling

[mmmPI]

You probably have noticed that space is filled with lots of asteroids, way much more than what you can consume with your spaceship x).

This often leads to throwing asteroid overboard, but when doing this it means asteroid collector was inefficient in its grabbing. This is particularly painful in late game when you want to grab promethium chunk as fast as you can and you don't want your collectors to grab some ice or iron which you have wayyyyyy too much of.

Another thing that lead me to this build was the observation that asteroid grabbers have quite the inventory space, particularly as their quality increases.

I then decided to make it so that asteroid collector would fill in from every ore, but not overfill, and would leave room to collect the most precious ones at all time :

limited collector.png (122.22 KiB) Viewed 3156 times

0eNq1VE1v2zAM/SuerpOL+atNDPS42zAU2DHzDNlmY6Ky5MlS2iDwfx/lJHab5rBhWw6BLJHvPYqPOrBKOugNKsvyA2tgqA32FrViOfvqugrMEKAKbAtBrdVghbLBMxgIdGUFKmiCRqPaBvGPJAqz7+rB6A5si64LnJL4BFOqpj8CEpSntA0kdmgp9QPjDD0syzcHNuBWCellKNEB8YvBgtHYhLWWEmqrDRspQTXwwvJoLDgDZdEiHPOnj32pJtUUwM84Z+GE01WohAfirNcDHgs9MMJL4puMsz3Lw+wmI5oGDVFO51HMPYY1WpYVtGKHBEBZwzFgeLsmJWeJnD2ipBoud0+66KKElFiHS6GtU0+k7acTkmqhGKVNR5fiBXS9MJP2nN1PG843LY7Su3SV3KbJyGeOeKldmEqr/8GRzBz6BRv49wTpTNDPpvorlskyW6NdT/sbcmB3/95iRfDt4TMbi3H0Ui48tdzrFW++t1R6tlR6aan0uqNqNLVDWw5gy9k61jjg85EB0ZQ+l6SdDgnawOCkDVHtaFsb4lROyisVLF0TBm1L10re+L25SN+WsLpewgLrVTY4T8gjmoEqm4fc7nsvY4fGuqltJ13HiBBE3fpxp8EimPI8wyz/xJnugdp7fKQ+UqZ2tnd/jE0/8sMzVeTncxPxiCc8KvgmnlbJtIppFRcU5+1CCMtzyZkUFRAd+3J6zl5bYUetmwRmt/E6Xa+zNL5L4lU0jr8APJXZiA==

Copy blueprint


This works using overflow, the constant combinator holds value for the 3 common chunks that are just 5 under the largest number possible to represent with circuits. This can be obtained in game easily by writing 2^31-X as value for the different signals. ( with X = 5 in the example )

The asteroid collector is set to "read content" and "set filter", but it won't set filter based on its own content if you do not forward the signal with an arithmetic combinator.

The content of the collector and the very large value in the constant are summed, and then those sums are used to "set filter".

This means when the collector has more than X of a asteroid chunks, the sum 2^31-X+[current count] will overflow and instead of being a large number it will be a negative number, which will disable the filter.

This means with only 1 arithmetic combinator and 1 constant combinator per asteroid collector, you can have a nice inventory filter to limit intake.

Now you could refine it to make it even more efficient and only use a single constant combinator in the whole ship for all collector, and only a single arithmetic per asteroid collector. But that require more wiring and is left as an exercice for the reader

It works well with an inserter that output onto a wired belt which read & hold the value for all belts which can use the same trick to limit the number of asteroid chunks on it.

[MBas]

My solution to this problem is this



As you can see from the input red signal, the constant combinator has a value of one for each type of item to ensure it functions correctly for that category. Now, everything will be collected until the limit reaches 13. A benefit of this approach is that you can adjust the values in the constant combinator to "simulate" inventory space for each item type if you want to allocate more room for certain items.

The number 13 is just an example, which fills the common collector up to this amount for basic asteroids. If set to 15, more frequent items will be stored in greater quantities, and so on. If you need to store an item in a higher quantity based on criteria other than frequency, you can tweak the constant combinator values to achieve precisely what you want.

Note: Inserters are not part of this setup; they serve as an additional level of filtering to prevent overfilled belts. I never throw anything back into space.

0eNqtV21y2jAQvYt+yxks2RA805NkGEbYomgqS64k0zCMD9B79GQ9SVfGmJAQEmc7/MD62Pfe7lvJcCQb3crGKRNIcSSqtMaT4ulIvPpuhI5zRtSSFET4IJ1VVVJarWUZrCMdJcpU8pkUaUdvhMjnxknvk+CE8Y11IdlIHV6EsW5FiTRBBSVPtP3gsDZtvZEOcOkdekoa6yHUmsgJcMnsIafkAA/p/CEHGsgmOKvXG7kTewUhsK9UrmxVWHsZ1lulARWYg2slHZecFNU6xoKaYRHAIJVWh0SZPUxbBzSm1Tom/ko0G0VXslSVdKC53igjbotOB8lZL7lSDrLrl7PbCQygUWDVA/k+rRcjqONWOQ85jo6EQxMF7ZULLcyMCk87EinKHTkVzAcReyHlcVQ3wvWyC/L39x8S7bJtaNrwukk+jd8cQHhroPbO1mtlAIsUW6G97FZdd6OanH7QTm8rysY24G9qeoMhm87ApzHkI8O5wPdb4pIA+2RT+NO6v34Gi84HlJKx2a9mB121DEJrVSaXc7ZrzQ/Q9hP8hFxgj7Gu7r296otv/UTb90xM/Xy0LykLt7HmP0JfOsI+w0lA4q7e6bv59K6YTeuKxXSGdBrD42SGiQTLyQR3awTXyy8Yxx59SmlKGeUr+hS/4QNPDOZymq5gX1B6eGW8OTwD/qK73EKNKGXSaBG20BDJFryvRB8Tc3rvQv4qwAwr4JzBHJvBHJnBlwVkA0D+VQCOBWBYgBQJMEPGY/lHDzKsBxnWgwzrQYb0IEN6kGE94FgPONYDjvWAIz3gSA841gOG9YBhPWBYDxjSA4b04HPx8HZWQdaw6fLfkpI9/PbsEfM5W2bLZZ6xBWePadf9AwLi4d4=

Copy blueprint

[mmmPI]

A benefit of this approach is that you can adjust the values in the constant combinator to "simulate" inventory space for each item type if you want to allocate more room for certain items.

The number 13 is just an example, which fills the common collector up to this amount for basic asteroids. If set to 15, more frequent items will be stored in greater quantities, and so on. If you need to store an item in a higher quantity based on criteria other than frequency, you can tweak the constant combinator values to achieve precisely what you want.

I don't see how it is a benefit, as there is no difference with my setup where you can modify the number that you remove from 2^31 for each type of chunk, like 13 or 15 or 5 to achieve the same result.

However, the fact that the constant 13 is stored on a decided combinator on your approach doesn't allow to change it with logistic group, which would require editing all of the decider if you were to increase the quality of collectors.

I tried something like this at first, but i went to refined it to make it easier to use.

[T-nm]

You can set the value on the decider combinator with another variable from the same constant combinator so that it could be centralized elsewhere. With MBas' solution it is also simpler to understand what the logic does, in my opinion. Both solutions achieve the same result except yours allows individual values.

[Barn]

Screenshot 2024-11-01 171932.png (1.73 MiB) Viewed 2960 times

This is the setup I've been using; very similar to MBas's except it allows you to set individual counts for each chunk type by comparing each red value (from the grabber inventory) against each green value (configured in the constant combinator).

The red/green filters might be my favorite thing about the 2.0 combinator changes.

0eNqtVNtu2zAM/RVDz3JQO5cuBvaylz3tC4rAkGU6ESpLni5pg8D/Pkqu7SwJihQbAiMyTR4e8pA6k0p66IxQjhRnUoPlRnROaEUK8ouhGR+bMJUIdQTltDklukn4watXNNuEa9WIvTdQo0fiDoCWthKKoeuCUCLQwZLi5Uys2CsmQxbFWkB4Zh0YLeqUaymBYwDpMUDV8E6KrKd3QgKYY8qlc5KLmLzfUYIkhRMw5Iwvp1L5tgKDoHQEqoGLGswlDiWdtmIo/UwQLn2m5IR/+WKNOWphkGP8muU0MHFGy7KCAzsKDI/di6AlfqsjkA3Wyzek1AhjXTlX5k5dIHQUxnm0TAwHjxQYP4QSLQScr8ddpisVuDdtXiMtVIwUznigZG8AsKyGSQvXqW5jotsUFBD60I62YwbKD1ZM1SSIob3rvLvW/0HqXHcn7KVXrmyMbkuhEGvK/wivftf3YY6uxiCnn83T7RysF+svToIdHOzfZ2zCON1BGInjf2394NWCY1IKns47EjYOuf3GjmEt6KO0aWP3ht5H7gX5Hg0+rHP2FGofd2OumZlKq/+JvZyw9TsuwL8Bb1C0+7LNae7cHLeqbUbVnh5VjQvDvcBtAZy4UZ5hRcZPBlgd9tshNztNvwHrpUunK5IUyksZFuANswaNXzKa0SXNdhRPefjF0wpt+Q79hIMWC5svY0okqwDXhfzwTQMm+WlYFdpAyRF5xTrWm3y72m7Xq/x5mX/L+v4PcoIAMQ==

Copy blueprint

[mmmPI]

You can set the value on the decider combinator with another variable from the same constant combinator so that it could be centralized elsewhere. With MBas' solution it is also simpler to understand what the logic does, in my opinion. Both solutions achieve the same result except yours allows individual values.

I understand what you mean by setting "13" in the constant instead under another signal. That would work i think.

But you could already go for individual values with MBas' solution i think too, if you change the value in the constant combinator then on the red wire there will not be 1 but 2 or 3 or 4, and that means removing those from the 13 before the filter disappear. But that means if you want to keep 7 chunks you need to write 13 in the constant as the limit for the other chunks and - 6 to create an offset for one chunk. Whereas with the arithmetic and overflow thing you write 2^31-7 if you want 7 chunk, or 2^31-5 if you want 5 or 2^31-9 for 9 chunks, there is no subtraction to do in your head for writing the value.

This is the setup I've been using; very similar to MBas's except it allows you to set individual counts for each chunk type by comparing each red value (from the grabber inventory) against each green value (configured in the constant combinator).

I like this, i think it makes it easier to set the individual values for each chunk type, but i don't think that was impossible in MBas' setup either !

The red/green filters might be my favorite thing about the 2.0 combinator changes.

That is sure a powerful feature, but it's not necessary to use there strictly speaking as i wanted to show The other feature that i use is the fact that you can now write "2^31-5" in a combinator field to mean "a number to which adding 5 would turn into negative" which is a very useful trick to know.


Also it should feature a way to collect promethium at all time for demonstration purposes of having the collector unrestricted for some chunks !