Round Robin ignores priority?

[tgstyle]

I have item conduit set to extract with round robin. It sends it to conduit with any priority level instead of a higher priority first.

[tgstyle]

Would it be possible to make it RR only to a certain priority or the highest priority only?

[CrazyPants]

Not really. You could separate out those you want to receive items via
round robin by setting them to a different chanel.
On 18/10/2014 3:13 PM, "tgstyle" notifications@github.com wrote:

Would it be possible to make it RR only to a certain priority or the
highest priority only?

—
Reply to this email directly or view it on GitHub
#1130 (comment).

[tgstyle]

What about having it RR to highest priority until it has no where else to go, then it can RR to the next lowest priority?

[CrazyPants]

That would be too confusing I think. I believe most people would just expect rr to be to strict rr.

[DeathByNukes]

Counterpoint: It took me a long time to figure out my priorities and sticky input filters weren't working because I'd checked round robin. Prioritized RR would be a really useful feature and I strongly disagree that it would be "too confusing".

[HenryLoenwind]

There's just no way to implement that in a way that makes sense. Let me give you an example:

4 outputs: A and B with prio 1, C and D with prio 0. All of them empty.

1. Conduit makes list of targets, (A, B) and sets "last target"=0
2. Item comes in, conduit increments "last target" to 1, then puts the item into A
3. Item comes in, conduit increments "last target" to 2, then puts the item into B
4. Items comes, conduit increments "last target" to 3, wraps back 1 one because the list only has 2 elements, then puts the item into A
5. continue at 3

Next run:

1. Conduit makes list of targets, (A, B) and sets "last target"=0
2. Item comes in, conduit increments "last target" to 1, then sees that A is full. Conduit increments "last target" to 2, then sees that B is full. Conduit notices that it failed to insert 2 times for a list of 2 targets. Conduit makes list of targets with next lower prio, (C, D) and sets "last target"=0. Conduit increments "last target" to 1, then puts the item into C.
3. Player removes one item from A
4. Item comes in, conduit increments "last target" to 2, then puts the item into D, but remembers the very last second that it is not on the highest prio. So it makes a list (A, B) and checks every inventory for free space. It finds one in A, so it puts the item there and sets "last target"=1
5. Item comes in, conduit increments "last target" to 2, then sees that B is full. Conduit increments "last target" to 3, wraps back to 1, then sees that A is full. Conduit notices that it failed to insert 2 times for a list of 2 targets. Conduit makes list of targets with next lower prio, (C, D) and sets "last target"=0. Conduit increments "last target" to 1, then puts the item into C.
6. Player opens bug report with us because round robin isn't robin around but put 2 items int C but none into D and also that conduits take ages to get things done lagging his server.

Update. I nearly forgot this one (the "what currently happens"):

1. Conduit makes list of targets, (A, B) and sets "last target"=0
2. Item comes in, conduit increments "last target" to 1, then sees that A is full. Conduit increments "last target" to 2, then sees that B is full. Conduit notices that it failed to insert 2 times for a list of 2 targets. Conduits goes to sleep.

[DeathByNukes]

The problem being that there is one shared "last target" variable for all priority levels? Why not have one variable for each priority level with 2+ devices on it? Lag is a fair response though, if it's true.

[stephen-smith]

Would you accept a PR that both let conduits sleep but still preferred higher priority targets? It wouldn't be perfect round robin, but it would be less confusing than the behavior I was getting today (fluid trash can @ prio -10, fluid tank @ prio 10, nothing was getting into the tank; switching off round-robin fixed it)