Circuit condition to tell if inserter target full on space platform?

[GAMING_Alligator]

On the planet, I could hook up a circuit to a storage chest to see if it's full.

On a platform, I can't use storage chests.

I want to have an inserter that jettisons asteroid chunks into space if the relevant target belt is saturated, so that the collector doesn't clog up. Does anybody know how I do this?

[malogoss]

Screenshots would help.
Else it's the same principle. But instead of reading a chest, you're reading a belt tile, or a whole belt, or the hub, or the collector itself.

[Isenfalk]

What works nice is using a belt. You can read the amount of asteroid chunks on the whole belt and yeet some into space if there are too many on the belt.

You can hook any part of a belt up to a circuit, just make sure it reads 'Hold (all)'.

I'd like to have chests in space as buffer, but this is the next best thing.

[Superguru]

I have a lot of hub extensions and use the hub as the chest. Then reading hub content to jettison when storing too many. Needs at least a belt to and from hub. Best done with underground belts to save space.

[Ghevd]

Use a splitter with a priority side. When the priority side is full have the other side of the splitter lead to a inserter chucking things into space.

[Aestrea]

You are thinking of it the wrong way, each a time a inserter picks up a item, then it is "full" whether it is 1 item or a stack or 11. This will cause your other inserter to activate each and every time if you use this as the condition.

You can't check whether it's blocked if you are checking inserters. You have to define if the belt is blocked if it has more than this many asteroids but if it's a shared belt, that will cause additional problems.

Best way is to know how much your belt can hold and allocate the space allowed for each type of asteroid and reprocess or dump the rest.

[malogoss]

You could, for example, hook the collector to a decider combinator. Have the collector "read" its content, relay that to the combinator. Set the combinator to "each > 10", output "each". Send that to the inserter in charge of emptying the collector, setting the inserter filters according to the signals it receives.

Personally I do it upstream, I'll have collectors set their own filters depending on their content. So they only grab chunks if needed. That way there's no need to throw any chunk in space, at least not from the collectors directly.

[Khagan]

Originally posted by malogoss:

I'll have collectors set their own filters depending on their content.

That's a cute trick. How do you manage it? You only have one circuit connection to the collector. As far as I can see, if you both read the contents and set the filters, then the contents are unavoidably contributing directly to the filter setting with the wrong sign. And unlike inserters, the collector does not have a blacklist option for its filters. What have I missed?

[malogoss]

Originally posted by Khagan:

Originally posted by malogoss:

I'll have collectors set their own filters depending on their content.

That's a cute trick. How do you manage it? You only have one circuit connection to the collector. As far as I can see, if you both read the contents and set the filters, then the contents are unavoidably contributing directly to the filter setting with the wrong sign. And unlike inserters, the collector does not have a blacklist option for its filters. What have I missed?

Maybe my comment was misleading, I need the help of some combinators to achieve it, the collector can't do it all by itself.

I'll have the collector read its content. I'll also have a constant combinator set to something like "-10 metallic chunk, -10 carbonic, -10 oxide". I send both (collector and constant) to a decider set to "each < 0, output each with value 1". Relay that to the collector and set its filters according to signals. That's it. It makes a nice chunk buffer, multiplied for each collector, without using precious hub storage.

For it to work smoothly I also have the inserters that pull from the collectors work only when needed, pretty much in the same way, by reading belts content and adjusting the inserters' filters accordingly, so they don't just empty the collectors for no reason.

[Khagan]

Originally posted by malogoss:

I'll have the collector read its content. I'll also have a constant combinator set to something like "-10 metallic chunk, -10 carbonic, -10 oxide". I send both (collector and constant) to a decider set to "each < 0, output each with value 1". Relay that to the collector and set its filters according to signals.

I'm going to have to try this. It looks to me as though it should be unstable, since both the input and output of the decider are connected to the collector, but maybe the one tick delay means that It Just Works™.

For it to work smoothly I also have the inserters that pull from the collectors work only when needed, pretty much in the same way, by reading belts content and adjusting the inserters' filters accordingly, so they don't just empty the collectors for no reason.

Yes, I'm already doing that.

[malogoss]

Originally posted by Khagan:

I'm going to have to try this. It looks to me as though it should be unstable, since both the input and output of the decider are connected to the collector, but maybe the one tick delay means that It Just Works™.

Nah, it works just fine, fully stable No idea how things like collectors are coded, but unless you loop some wire back to the collector, you can't just simply use its content to set filters. The same way you can't have an assembler directly enable itself based on its own content.

It could be that whatever the collector reads, it secretly "sends" itself an equivalent negative signal, making it equal 0 at all time. But I have no idea about that.

It is not about tic delay either, because at one point, the decider won't have any output while the collector will output at least one signal unless totally empty. And if it did care about that signal to set its filters, it would always fill itself once a chunk were in and stayed in, since a filter would always be active.

0eNqtlN2Om0AMhV+lmuthFdgk2iD1SVYRGsDZWJ0fajzpRhHvXs+EkrRNV5XaOzPYx599Bi6qtREGQs+qvijsgh9V/XpRI755Y9OZNw5UrczIQAH7ogvWQseB1KQV+h7eVV1Oe63AMzLCtT4/nBsfXQskCfoDHa2GMEpp8KmfyBXV6mmj1TlF1dNG+ggXU7BNC0dzQqmRxA6pi8jNCNwc0IqstGaKoJdXBKZvUq3gzC9FjGCMlgv0JzkOJG18tHbSv1FXC3XaCxvPQu1a9OYxdvmyYJd/xB5laMxrvo9lZT92qdUyzU+nM4oDNtZiV9w2eYz+i+B8jcYKvuT4QE7cSwBuMJRxa/U5H8Rk9Uuadpa+m9JQG/x/lH5epMM79vBPumWVLtkbhTgk1CTwyaJDlhQnfuJgMZlWyGWcpgdu3mB66ISGPjazWs1WrrKVPdLVrETy2NlZNl24HheP75/EzwPSKHd2+bz4PCSkExLHPP/MeM0owHRHNaXJQ+Qh8q9f51+VJ9zh3ORFNgcKrkEvWqo+GDtCXpc0+CYTJvnXUpf6WZd7LVEl0VqiKkfVXvKQwUmH249Dq5Pc1ryazbbarXe7zXq73a5322n6Dgrqfj8=

[Khagan]

Originally posted by malogoss:

It could be that whatever the collector reads, it secretly "sends" itself an equivalent negative signal, making it equal 0 at all time.

That's exactly what it looks like to me. My first attempt failed, since I expected that the constant combinator would need to be connected to the collector to cancel the contents signal. But without that it does work: somehow the collector just ignores the contribution to each signal from its own output.

Which raises the question of why we cannot simultaneously read the contents of and set the requests for a requester chest, which would seem to be an analogous situation.