Asteroid collector blacklist filter or target priorities

[protocol_1903]

TL;DR

The asteroid collector should use the target priorities system that turrets use, or have a blacklist filter option.

What?

Currently, the asteroid collector only has the option of a whitelisted filter. This is not very expansive, especially in the case of mods that might add more than four types of asteroids. It would be nice to be able to use a blacklist instead, or use the target priorities system that turrets currently use. Either one would be a
massive improvement to asteroid collector functionality, especially concerning circuit integration.

Why?

It doesn't make sense for it to only have a whitelist option. It would make more sense for it to have a blacklist filter option, or use the same target priorities system that is implemented with turrets.

[sh4dow]

I'd also really like this.

Currently, it's quite annoying to both limit stack inserters to only grab when there's enough of a type stored, as well as filter what the asteroid collector collects.
You need to both send a positive signal for the chunks you currently want (in case none are stored), as well as sending a very large negative signal for types to stop collecting (since some chunks might be still stored in this or other networked collectors). With a blacklist, you could simply send your target amount to be cached as a negative signal, and the collectors would auto-balance (you'd have a single chunk of each unwanted type in the collector network, but that wouldn't matter in practice).

[Shirasik]

You need to both send a positive signal for the chunks you currently want (in case none are stored), as well as sending a very large negative signal for types to stop collecting (since some chunks might be still stored in this or other networked collectors).

Reading about large negative I assume you reading contents of collectors. If so then its read amounts will loop back into collector's input and pushed into blacklist.

What you really need is extra sub options for circuit connection options: input signals to be read from R/G and output signals to pushed to R/G. E.g. two extra check boxes

Screenshot-41.jpg (50.79 KiB) Viewed 370 times

[protocol_1903]

What you really need is extra sub options for circuit connection options: input signals to be read from R/G and output signals to pushed to R/G. E.g. two extra check boxes
Screenshot-41.jpg

That would be a general suggestion, not relevant to this request.

[Shirasik]

relevant to this request

OK. Let's say you using a "mods that might add more than four types of asteroids". At some point you need to blacklist all types from mods and some SA types. Or all SA types and some types from mods. Both cases goes over five types. With blacklist being limited to five entries will it be more useful than limited to five entries whitelist?

I mean blacklist is equivalent to whitelist in your case. So you better to ask about making whitelist/blacklist array to be expandable dynamically.

[protocol_1903]

relevant to this request

OK. Let's say you using a "mods that might add more than four types of asteroids". At some point you need to blacklist all types from mods and some SA types. Or all SA types and some types from mods. Both cases goes over five types. With blacklist being limited to five entries will it be more useful than limited to five entries whitelist?

I mean blacklist is equivalent to whitelist in your case. So you better to ask about making whitelist/blacklist array to be expandable dynamically.

I have no idea what you are referring to, I was simply commenting that you were making a suggestion that is generally irrelevant to this request and, if desired, should be requested on a separate post.

In regards to making them be 'expandable dynamically' i still don't know what you are referring to. The only reason i mentioned an asteroid number in the post was because it is obtuse to manage more than a few filters, manually or via circuits, regardless of the entity's limits. That is a prototype property and can be adjusted by mods if they so desire. On further inspection this is not modifiable by mods. It makes the request for a blacklist option even more apparent.

[Shirasik]

I have no idea what you are referring to, I was simply commenting that you were making a suggestion that is generally irrelevant to this request and, if desired, should be requested on a separate post.

I quoted the comment I answering to but you can't figure. Amazing.

The only reason i mentioned an asteroid number in the post was because it is obtuse to manage more than a few filters, manually or via circuits, regardless of the entity's limits.

How so? Anyway machines aren't supposed to be smart they are supposed to make work done.

[Shadowhawk]

TL;DR

The asteroid collector should use the target priorities system that turrets use, or have a blacklist filter option.

What?

Currently, the asteroid collector only has the option of a whitelisted filter. This is not very expansive, especially in the case of mods that might add more than four types of asteroids. It would be nice to be able to use a blacklist instead, or use the target priorities system that turrets currently use. Either one would be a
massive improvement to asteroid collector functionality, especially concerning circuit integration.

Why?

It doesn't make sense for it to only have a whitelist option. It would make more sense for it to have a blacklist filter option, or use the same target priorities system that is implemented with turrets.

You can dynamically set the filter so there is basically no real limit to the number of asteroids to filter out. So this is already possible in the game with circuit integration

[protocol_1903]

You can dynamically set the filter so there is basically no real limit to the number of asteroids to filter out. So this is already possible in the game with circuit integration

The point was to not require circuit management for filters. And even if you do use circuits there can only be 5 filters set at a time so you need to cycle them or not have all of them active at a time.