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 13197 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 13001 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 !

[mmmPI]

Used this trick to control the whole ship buffer with a single constant :

0eNrtnd9uo0gWxl+l5Zu9sUccKKBo7V7sxe5LjKIIOyRBjcHDn57uGeUB5j12X2yeZAvs2CQBu8q/TPdotFJLTWxzqCpOfXU4fN+pXxfrost2dV62i4+/LvJNVTaLjz/+umjyhzIt+s/KdJstPi6aqkjr1S4ts2KxXPzUpUXefjWf12mdLZ6Wi7y8y74sPsrTcurkXbrJVrsibe+rert67NajU/ynm+UiK9u8zbP9xYc/vt6W3Xad1cbm8tnOQ1eu2q6us9a0YVc15pSq7K9jzKzMz772/4VPfRte2fCtbJw1ERxNpE2b1VV+t9pURZFt2qqeaI76ITxY838ITW/v8tr8dPiBmNaYkW7rqrhdZ4/p59xYMKdt8nrT5e1tk7W393lhLmLGo627bHn8qs7Su9v+XNO4w5dPb27HclFnTVe0q7z8bH5X1eabsiuKiU6pY6fWXfHJnNBktbnu1PAe+xO87o+eMBxaG/ZeGJ4wFdma8tyaGNvalUst1E6uccYz1J/GMRLr+3fqjjd051wHhlY+puXrpp76MXw5/Gxb3WU9oEw0Tjzr1vmvWnfBJ8QSbPznOzjZPDu08c7aCKxsnG+H9ewOv8M9PCHEy7XlDfAcp3UytO3N2vPWdGRpOna2bI0Zq+OQaiu/O0FI9mVnZmmz6szyWD/Ulfl/tc6K9tw19u1vv+56A1XX7rp2svmnWW0cal2t2jotm11Vt3NXUC+vMO4F9ZLnz8eeMunGvnd1q9+MvZqyf5rzRVU+rPpWZ3fn7m0wOypmIk5cwH/VAYtbG8x34Xij83LmPvuBE4olk6Ou7CaR8+z0TxM/3Wy6bWfCwqllMnhGJDurkfMY+xZDPD+X/NjRKwM3p9TO/TmDOBYu4woNL+bYVLjsXWswcYyK3hFqAnFsdDiPj1Pmfbs55bwuBYGdYfe1NFDOy3Rkazp0XaatLUejgLzJtusiN7i+TTePeZmtgnMrxuQl+rh5kw8T6N7c4dQ8w27Th/QXY+343e3pnNI85KZ9R/I22+4fafO70eNwdn+fb/Ks3HxdGV/simzlD8/D+1+bH5e3owC9P/v0l7kdTZtuPhng7Ts++Y3MfuPPfhM83TyZfxNjecK5Td01j9NR9njwXgLP/FBuszYtinyzOj009Rcwt+qaQW12mVm0D+MZTOcoXAf4ZsCIi/fuHa4ls8OvLw+/d83ob1KDb+X/R//86CeXR/8q36++5HfZ+wz9rjYjYa752fz8XUflHMDMjJc6LfpZn/6ojX/dd3WZbrIzC/4M5n5DV3PvqDiu5LZLl/JdV3Jry4H7s6uaju2UfdowGJu6GCCp0D2xoxyfTLMyXRfZ3USMeHe8gFnlm/b2TR47r6tyVe19rE+Vt2mfN/c9r/9zu0vr4Unm4+Lvi6fJYYvck6LfsHf7FeHavsXumeQ579LOidlv6QObV7dfrIcocU5kz4xQaJ3/DM6N0DGVPADj/v3N8o2vj7HluBa96O8/Fv0rnK7JXianpxoutg33Lw2B75zbnLMUOD/hBJaQGyrXJxxry6F7fj5wfQ8FZsmbx6SXUybRr1zo99/+Mz1pwgglRoNxYnQ2+RGOnnEOjVyZ5q3zMr3wcs+fTZc3+1FuXh6/mGln59/E09FjV36ymo79B90A36JipYNIhfsQZ//CdfkS8f+Ia5zm1OtIF13gpo/Hpm6g9ZIxPxvUHxs29G+/X02D6VmwfO83LWHiPDj+u6fgrFoaedcnPf35pOd8EjdyDeNt8TlyDuOtLQfj6ftQrdbp18nFajBrlzyPlJXNyMXkKLn3lv0xk8LoTdfZT13WjN5zz8DnS0B7v1DmCDtyBjJdLZnwqPfiXe/Yj3nzwfxrH7M6+9BWH7bpp+xD05k/+nZ+qOoP+2uYH5V/az90ZVGldwZ4lou0f8o3jbhPiybrbR7Hqq62t+vu/n4Uex2/3OZNk5cPtwPu1N0wlLdbA0Z1buzMhmpRZOMTTi4R21h0c1xtGWAlh2lmPcsSu5dUq3hv1spo7JFYxrd7xxu7vsI4XsCONOM7B55TK+23f/SIA+eGOxO33mkZjNUVfuLqJuHVS21wxevFOHKNQSafVs66jQM0WztN7Nrs7xQ5xdoOr5zgKrEDV1ds1fbsrehgOvxOM1GLO3Pjuc3qimmifbJChFYPuzq4doFQVmwXrSyXTrVvtJ3PuMPVMUMc2iGijpxzz1Y5bR07Z333ds+vkZv3XR61c9LVopETL8vfscWWIZqLmyWenc3oaHMKhPY+NsoDHHzvc1633dDlZ1gdfrH65+LJrnXiRkHXhzsV/YkJ6Inlg/IRhGLLVSYJLGFozzOL7YyOHpQfs22+MXfPPNiW7ZnJfIlRYmbyamsQ7MrXv9+TTDLzcjQJHbjL0dS6m0QgAo6slsEkdoEPS/ewBtFobmp+m3AxSZyQRF/Z2m+II8NbOKv5roeuJHZ8b+8Eubt+us7HAjM0SPH8SxbkkoXgkgXvkgV1wcJFA+EFAxf7YEnJf57D1oR8L7YzrJ0N6+tDf5FrktHiJU4uLGLXEwe1TDjbgclQX0ZymfMt3gdMllxuGQloLi6zz2+4D8qV+XW2fay7HutW/Rup/Jeh/38Knts7rrwykg2ts3QzpEPm0GJuxP7grsts1+Uy70rEPgLznT3jvhug46/nFaFrGustAKhJw9HVWcQrMXKkwJpeiV5g8KQFfcFCfNFCcsGCvmRhJGmaWdKPJvw5E2JtIpgz8TI0WbXVan/rzjBUJLBbGfyLQUt8sYfKNvaaNwHSRmLHHZGR8ujiKMq4wTajGFvGXfMjoG0tzHpJYt0/b9ZJJtEj8Kwtx7MDN21ZbFFibtwC33aOz1oY5VkPC8xUxLU3omzD0kA5ZylFvbt2007hG1gq/Q6lG0RZDkFkZ/Zg1XZgY4vbpVzvltNrGesBcHt6P6FO5OgIb57f2SO68pxu3FTO5cZEOybu6wOtfRxWVJtqW/W8iP7vKBz9oLdmelrVd4eaJm26v8jiviseqjo1V/45HXO49r/b56Oz2wPypwMeHf44jMyQtT5D/Lqc8D3PIP79t/8uhil1ri1tvu3Hv803n5r+xbzn7aO/Uz/LtPucN3+pbkah8vY0QHOnfzae3Hfmx2Apy2QpN8vhSE6HYTgc6v5TdTwM9XCowqW/VNHSfz6Owv1x1H+uh+PeQP95//swHh3r0XFyOu7/WyYyOk6ej/1l4g02475lcTx8Phxrb98073Ru/9+yn+nDH/pkqF8Bnr+56YfleSbMlaiInuaYWPf9Wrv3lf4mzBXUudaAB8+n1z+OQEhHIIQjEMIRuLoDz1U91LUGFDXgUwMCDXjwfHr9AJ6P78CxdhH1gasNBNSATw0INODB8+n16QDQO4Bd4FjxijqhT53Qp07oUyf0oRP60Al96IQ+dEIfOuH1N+C5B3K1BcEWPGohoQY0NRBTAyE1oKiBgBrgrgQNUD+i16cDQO8AdQHqgxE8n04iOospjGAgewcs9UclwhieexjPPYrnHsVzj+L51QYiaiCkBhQ1EFAD3BehAeqI9Pp0AOgdoC5AfZBOAjoLKQxQHMJI+A5gfCxoCdeDhC4HCVwNErgYJHAtSOBSkMCVIIELQQLXgQQuAwlcBRK2CCRsDUjYEpCwFSBhC0DC8D9h8J8w9E8Y+CcM+xMI/QlE/oQCv6bArynwawj8GgK/hsCvIfBrCPwaAr+GwK8h8GsI/JoBv2bArxnwawb8mgG/ZsCvGfBrBvyaAb9mwK8h8GsI/JoCf0yBP6bAH0PgjyHwxxD4Ywj8MQT+GAJ/DIE/hsAfQ+CPGfDHDPhjBvwxA/6YAX/MgD9mwB8z4I8Z8McM+GMI/DEE/pgCf0SBP6LAH0HgjyDwRxD4Iwj8EQT+CAJ/BIGf0gspvxLSKyG7MmLAHzHgjxjwRwz4Iwb8EQP+iAF/xIA/gsAfQeCPKPCHFPhDCvwhBP4QAn8IgT+EwE9ZySEE/hACfwiBn9LKIasckspDBvwhA/6QAX/IgD9kwB8y4A8Z8IcM+EMI/CEE/pACv6LAryjwKwj8CgK/gsCvIPBTKQJVoygI/FTMQrUsUMoClSyKAT/UwUAZjGLArxjwKwb8igG/YsCvIPArCPyKAn9AgT+gwB9A4A8g8AcQ+AMI/FT+QyVoVIFGBWhUfwblZ1B9BsVnUHsGpWcBA/6AAX/AgD9gwB8w4A8g8AcQ+AMK/D4Ffp8Cvw+B34fA70Pg9yHw+xD4qeyTqj6p6JNqPqHkEyo+oeAT6j2h3NNnwO8z4PcZ8PsM+H0G/D4Efh8CPxfqYl0XlnVRVRcVdVFNF5V0UUUXFXRRPReVc1E1FxRzQS0XlHJBJRcUckEdF5RxQRUXFHFBDReVcFEFFwR+quelal6o5YVKXqjjhSpeqOGFCl6o34XqXajdZcpdpttlql2m2WWKXabXZWpdptVlSl2m04UqXajRpQpdGtjTuB6G9TCqh0E9jOlhSA8jehjQw3gehvMsmmfBPIvlWSjPInkWyLM4noXxLIpnQTyM4WEITwGaZtxhwh3m22G6HWbbYbId5tphqh1m2mGineXZWZqdZdlZkp3l2FmKnWXYWYKd5ddZeh1m1+lLTUpmgVwWSGWBTBZIZIE8FkhjgSwWSGKBHBZGYWEMFkZgYfwVRl9h7BVGXmHcFUZdYcwVSFyhfEHKE4c0ccgShyRxyBGHFHHIEIcEccgPh/Rwxg5n5HDGDWfUcMYMZ8RwxgtntHDGCmekcMgJhwgHBZBQ/wjlj1D9CMWPUPsIpY9Q+ciEj0z3yGSPTPXIRI9M88gkj0zxyASPUGYNy2vA6hqwuAasrQFLa8DKGrCwBqyrwcpqsKoarKgGq6nBSmqwihqsoAarp8HKacAiPrB4G6zdBku3wcptsHAbrNsGy7bBqm2saBur2cZKtrGKbaxgG6vXxsq1sWptrFgbLBEJSwPDysCwMDCsCwzLAsOqwLAoMKwJzEoCs4rArCAwqwfMygGzasCsGDCrBcxKAbNKwLB8Ody2Au5aATetgHtWwC0r4I4VcMMKuF8F266C7VbBNqtge1WwrSrYThVsowq2TwXbpoLtUgG31qH7rNFt1ugua3STNbrHGt1ije6wRjdYg/urwe3V4O5qcHM1uLca3FoN7qwGN1aD+6rBbdXo9pB0t1+62a9Q0QFVHVDZAdUdUOEBVR5A6QHUHkDxAVQfQPkB1B9AAQJUIEAJAhU6QSK9QCa9QCq9QC69QDK9QDa9QDq9QD69MEK9MEa9MEq9ME69MFK9MFa9MFq9MF69MGK9QPmOQHa5QHq5QH65QIK5QIa5QIq5QI65QJK5MJa5MJq5MJ65MKK5MKa5MKq5MK65MLI5nreQtSyQtiyQtyyQuCyQuSyQuiyMuyyMvCyMvSyMviyMvyyMwCyMwSyMwixQbCCQiyuQjCuQjSuQjiuQjyuQkCuMkSuMkiuMkyuMlCuMlSuMliuQxC6QYCqQYSqQYiqQYyqQZCqQZSqMZiqMZyqMaCqMaSqMaiqMa0pHnpHvLE+/WS7yNtuaH62LLtvVedkulosiXWeF+ezfXfFQ1emHf33Z1VnTmG8+Z3UzXCqM/EQlSaiCQGvRT0//A7XUyFo=

Copy blueprint

[geezer62]

Both of these techniques work fine for me as long as I dedicate a combinator to a single collector. I was hoping instead to maintain global per-type limits across multiple collector storage areas, but it doesn't work. I wonder if anyone can explain WHY it doesn't work.

So for example, this works perfectly:

Constant combinator (CC): 12 metallic, 9 carbonic, 18 oxide (optimal ratios for white science production in Nauvis orbit)
Decider combinator (CC): Condition R * < G *, Output * 1
green wire from CC to DC input
red wire from Collector #1 to DC input
green wire from DC output to Collector #1
Set filters, Read contents, Include hands on Collector #1

Then:

Double the CC values to 24 / 18 / 36 to cover the additional 39 slots of a second collector
red wire from Collector #2 to DC input
green wire from DC output to Collector #2
Set filters, Read contents, Include hands on Collector #1

The Input and Output signals on the DC continue to be correct, but the filters on the two collectors no longer reflect the DC Output signals state. Eventually, both collectors reach Output full states, and the overall totals vary wildly from the values in the CC.

Can anyone explain what happens to the filters when I add Collector #2 as described above?

[mmmPI]

Both of these techniques work fine for me as long as I dedicate a combinator to a single collector. I was hoping instead to maintain global per-type limits across multiple collector storage areas, but it doesn't work. I wonder if anyone can explain WHY it doesn't work.

Can anyone explain what happens to the filters when I add Collector #2 as described above?

I'd be happy to provide some more dedicated help in the gameplay help section, or if you provide a blueprint as i'm not sure i understood the attempt you made.

It should be possible to use a single combinator to keep track of a quantity that would be distributed amongst several collectors, with the quirks that can happen if a collector whose buffer is full grabs an additionnal chunk. That thing is avoided with the original setup, but if you expect 2 collector to hold 39*2 chunk, and one fills up first, you will have an overflowing collector.

And you will potentially have all the chunk of one type in a collector ,and all the chunk of another type in another, depending on the supply chain, it can be risky and backfire !

[geezer62]

I'd be happy to provide some more dedicated help in the gameplay help section, or if you provide a blueprint as i'm not sure i understood the attempt you made.

Thank you for this and for your other comments.

After reading other discussions from last fall - I'm a new player - I realize that there is a fundamental weakness in circuit feature functionality that explains much of the counter-intuitive behavior I have observed and requires excessively complex and clumsy solutions to implement some simple, obvious ideas. This assessment appears to be shared by the development team, and they have expressed interest in delivering a relevant improvement in release 2.1.

So rather than investing lots of effort designing complex circuits that may soon become obsolete, I have decided to wait for 2.1. In the meantime, I'll limit my use of circuits to applications where the simple, intuitive solution is effective.

Some links:
A comment from developer boskid explaining what he did to allow a single collector to be controlled as of 2.0.20. He also explains why the obvious multi-collector solution fails.
A topic discussing the proposed new feature.
A comment within that topic on using a one-way wire solution to control N collectors as a group.
Kovarex's comment indicating interest in implementing the feature for 2.1.

[Tertius]

So rather than investing lots of effort designing complex circuits that may soon become obsolete, I have decided to wait for 2.1.

I wouldn't do this. Although the devs indicated they WANT to implement some change, it's not sure whether they actually DO implement it. If they're unable to do it for whatever reason, you waited for nothing. How long do you want to wait? 1 month? Half a year? 2 years? There are so many examples where game developers really wanted to provide some feature but were unable to deliver it in the end. So evaluate and treat the game you have in your hands as the final game. Don't expect any updates at all. Design your circuits with the current game state. The challenge in this thread can definitely be done with current circuits. No need to wait.
If some change really becomes reality, be happy and simplify your existing stuff. That's the way I do it. It's the chance to revisit old suboptimal stuff, and do more with it than just simplifying it: improve it beyond the simple feature upgrade.

[geezer62]

So rather than investing lots of effort designing complex circuits that may soon become obsolete, I have decided to wait for 2.1.

So evaluate and treat the game you have in your hands as the final game. Don't expect any updates at all. Design your circuits with the current game state.

I agree with you. I do hope 2.1 arrives with the hoped-for functionality, but I'm happy with the game as it is today. But in my view, there are many possible 2.0 circuit designs that are complex and confusing to a degree that drains the fun out of it for me. When I bump into those limitations, I'll employ simpler solutions.

The challenge in this thread can definitely be done with current circuits. No need to wait.

I agree - managing the storage of a single asteroid collector with circuits is straightforward, and I am happily doing so today. It scales pretty well too - one decider or arithmetic combinator per collector and a shared constant combinator for all of them.

Where I ran into trouble was in trying to use one decider or arithmetic combinator and one constant combinator for N collectors - the results were wrong but not obvious to me. I see now that I could implement the idea by using two additional combinators per collector to isolate the signals, but the solution is not pleasing to me.

[Tertius]

Controlling one collector with a filter signal and reading collector content at the same time works, because the collector ignores (subtracts) its own content signal from the "incoming" filter signal, so the filter signal is restored and applied as filter properly.

Your attempt to control multiple collectors with the same filter signal fails, if all collectors are connected to the same wire. They subtract their own content from the wire, so they are able to regenerate the filter signal if they are alone, but not the content from the other collectors, so the filter signal they see is the actual filter signal plus the content of the other collectors. If they all have some chunks, the filter will eventually become all 3 chunk types permanently.

You need to isolate the incoming filter signal from the outgoing signals of other collectors, which requires one combinator per collector. And you need to isolate the outgoing content signal against the other outgoing signals as well with another combinator, otherwise the the content signal from one collector will be seen as filter by all the other collectors. But since you can balance each collector individually with just one combinator per collector already, it makes no sense in my opinion to add even more combinators for some global balancing.

Since the asteroid chunks are statistically evenly distributed over the map, the collectors should be able to collect them evenly, which isn't the case with a global filter, since this allows single combinators becoming full with one or two asteroid chunk types and no space for the 3rd type (usually oxide), so the 3rd type is always missed in the area of that collector as long as the collector is full. It's best statistically if every collector always has space for every chunk type and all collectors becoming full at the same rate, which is achieved best if every collector has its own balanced inventory.

[mmmPI]

I realize that there is a fundamental weakness in circuit feature functionality that explains much of the counter-intuitive behavior I have observed and requires excessively complex and clumsy solutions to implement some simple, obvious ideas.

I don't think that's the case, but i can understand why a new player may have this feeling.

So rather than investing lots of effort designing complex circuits that may soon become obsolete, I have decided to wait for 2.1. In the meantime, I'll limit my use of circuits to applications where the simple, intuitive solution is effective.

Feel free to use the blueprint i posted then

[geezer62]

Thanks for the detailed explanation, Tertius!

[geezer62]

Feel free to use the blueprint i posted then

Actually, that's where I started, mmmPI, with your blueprint. It works perfectly!

[NewcoLux]

Hi everyone,
I found an alternative way to prevent overfill on my spacecrafts:
brief description:

1. Connect green wire to every asteroid collector.
2. Read whole belt loop via green wire.
3. Use a decider combinator to output the "collect X asteroid type" recipe, based on a, via trial and error found, value for your desired threshold.
4. Reminder to enable the option to allow the "set recipe Signal" in the collector.

While it lacks the fanciness of your solutions, it opened the opportunity to use the exact same procedure to control the crushers too.

[mmmPI]

Hi everyone,
I found an alternative way to prevent overfill on my spacecrafts:
brief description:

1. Connect green wire to every asteroid collector.
2. Read whole belt loop via green wire.
3. Use a decider combinator to output the "collect X asteroid type" recipe, based on a, via trial and error found, value for your desired threshold.
4. Reminder to enable the option to allow the "set recipe Signal" in the collector.

While it lacks the fanciness of your solutions, it opened the opportunity to use the exact same procedure to control the crushers too.

If i understand correctly that's a bit different in that you are not using the asteroid collector inner buffer to store the asteroid in a controlled fashion.

This will allow to store a defined amount of asteroid chunks on the belts but the asteroids collectors will be empty and stop collecting when the number is reached.

It does work to prevent overfilling from unwanted chunks though

[gGeorg]

I found an alternative way to prevent overfill
the exact same procedure to control the crushers too.

If i understand correctly that's a bit different in that you are not using the asteroid collector inner buffer to store the asteroid in a controlled fashion.

As long as storage space is expensive in space (ehm) I use both. Balanced collectors plus balanced belt_as_storage. Crushers are crushing as needed. On top, reproccesing is also balanced based on chunks on belt_as_storage. So crushers could do crushing or re-processing based on situation. It might happen that some crushers are crushing meanwhile others reprocess.

I dont use quality ( simply dont like the system ) so my collectors ale always one handed. Side effect is, max efficient usage of resources is a welcome challenge.

[mmmPI]

As long as storage space is expensive in space (ehm) I use both. Balanced collectors plus balanced belt_as_storage.

This topic is only showing a method to keep balanced collectors. This is because many tiny ships do not even use belt storage !

Keeping belt storage balanced, if needed, can be done with a single constant combinator using the overflow trick

I generally don't find it useful to do both "a selection of which chunk to pick up from space" AND "reprocessing" as usually i prevent my ships from collecting too much, and thus no reprocessing is needed.