Unexpected behavior involving distributors with blocked active filtered channels

[fluxionary]

This issue seems to affect both the regular and HighPerf distributors.
It is a bit difficult to describe, so bear with me.

How to produce the issue:

1. Set up a distributor with 2 (or 3) active filtered channels, filtering on the same item.
2. Have at least 1 active unfiltered channel.
3. Obstruct the output of one of the filtered channels (with a block or a full inventory), but ensure at least one of the other filtered channels is able to output, as well as the unfiltered channel.
4. Pass several of the filtered item through the distributor.

Confusingly, some of the items will be output through the unfiltered channel, even though a filtered channel is available. I would expect that these items would be output through the filtered channels, unless all such channels were blocked, not just one of them.

---

Possibly relevant postscript: Until about 6 months ago (though I don't remember what version exactly), distributors would never output a filtered item through an unfiltered channel, even when all filtered channels were blocked but unfiltered channels were available. I think I've come to prefer the current behaviour, though, as long as this issue is addressed.

[joe7575]

This was a feature request from BillyS, received as forum PM :)

Re: Tubelib suggestion

Sent: Fri Aug 17, 2018 15:52
by BillyS
I have another feature to request, when you've got time ...
Could you make the highperf distributor (and the normal one, if it doesnt already) send items on a blank open output if the one specified doesn't work? For example, if I have a distributor that outputs cobble on "blue" and everything else on "green", could you make it so that if it couldn't output cobble on "blue" it would output it on "green"?

Thanks,
BillyS

I changed it accordingly...
But I see your point.
The distributor should take the unfiltered channel only in the case, if there is only one filtered channel and this channel is blocked.

[fluxionary]

Oh, that's interesting. I swear that when I first noticed this behaviour and showed him, he insisted it had always been that way ... Perhaps I'm remembering wrong.

I'm not sure the distributor only redirecting "filtered" items to an unfiltered channel in the case of a single filtered channel is correct. To me the correct behaviour should be, that a filtered item should be output on an unfiltered channel in exactly the case that all possible outputs that filter on that item are blocked.

I'm find it tricky to word this clearly, maybe an example will help. If there are two active outputs that filter on stone, and one that is active but unfiltered, stone should always be output on one of the filtered channels, unless both of those channels are blocked. When both of those channels are blocked, it should be output on the unfiltered channel.

I've never looked at this part of the techpack code, but if it is still unclear, maybe I could cook up a PR with what I consider to be the expected behaviour.

[joe7575]

Again, your proposal make more sense, even if I uploaded the changes already as v2.03.02

[fluxionary]

Thank you for your work :) I will play around with this update.

[fluxionary]

Using the latest update, I tested the following setup:

• "Regular" distributor.
• 2 filtered outputs, filtering only on stone
• 1 unfiltered output
• One of the stone outputs was blocked, the other was available.

No stone was output on the unfiltered output, which is expected. Half of the stone was output on the open, filtered output, which is expected. However, half of the stone disappeared entirely, which was not expected.

The HighPerf distributor seems to function as expected, though I will do some more testing.

[joe7575]

Right, I missed to check the number of outputs, should be fixed now.

[fluxionary]

Things seem to be working as I would expect them now, though I might do some further testing.

Probably unrelated, but I've also just noticed that unfiltered items are output four-at-a-time from a regular distributor, vs. the 1-at-a-time output for filtered items. I'm not sure whether or not this is intended, but it isn't a change in behaviour from the most recent update. I see this same behaviour on Blocky Survival.

[fluxionary]

Oh, I see now that the 4-at-a-time thing is probably intended, and related to the fact that putting a single item into a filter slot multiple times results in multiple items being output at once. I remember that not always being the case, but it has been a long time since I tested that.

So things seem to be working correctly, as far as I can tell.

[joe7575]

The distributor code is ugly and unfortunately different for both distributor types.
I am open for pull requests :)

[fluxionary]

Sounds good. I'll go over it and see what I can do. This might take a while though.

[fluxionary]

As an update, over the last week I've become the major party responsible for resolving bugs on BlS and upgrading mods, so I've had little time to work on this. That might change in the future, but I don't know when.

[secularism1]

I'm having a similar (if not the same) issue, on BlS, with techpack c2a9d6f:

My setup is: One highperf distributor with three outputs enabled (I use the other one as an input):

• filtered on cobblestone
• filtered on cobblestone
• unfiltered

In the case both filtered outputs get blocked, I expect the cobblestone to go the the unfiltered output, but nothing happen, the distributor state is "standby" and nothing move (until one of the filtered output gets unblocked), but anyway, nothing goes to the unfiltered output, never.

The idea behind this setup is to have a row of highperf distributors, each distributor is distributing to two gravel sieves, and forward the excess to the next distributor.

[joe7575]

Should be fixed now. Please respond if not.