Round Robin?

[Paril]

So far I'm loving these pipes; they're damn simple and effective, probably the most useful "just pipes" mod that exists.

There's a few things that I think would be helpful for the mod, though:

• [x] A "Retriever Pipe", which acts as a Supplier pipe with no item specified for retrieval (a Supplier with no whitelist, basically). This would be handy for resolving issues where you want a machine to request any item by a specific Provider. Only needs to be 1 item at a time, but stack size config might be handy too? Think Furnace that can request items for fuel and input from separate containers. Saves the need for them to be extracted and potentially overflow. (I've always preferred retrieval vs sending)
• [ ] Round Robin would be neat, but is probably quite the task for this kind of piping system as it would need to know how many destinations there are beforehand and cycle between them. Perhaps a solution to this would be to have a "Cyclical Priority Pipe", inwhich you specify a minimum and maximum priority (such as -5 and 5; one min, one max), and the items that pass through it will be assigned a value that starts from min and increases every item that passes through it up until the max, then it cycles back to the min. This would let you do round robin with an unknown amount of destinations.

[Ihamfp]

Thank you for the feedback, very appreciated :D .

So the Retriever would be linked to one or more provider and request items to these ones only ? Seems easy enough, I'll add an item to store a pipe's position and a "pipe whitelist" in the request class.

Your idea for round-robin-ing seems pretty nice, but unfortunately the sorting thing happens when an item enters the network, so you would need to wait for the items to get to the Cyclical Priority Pipe before sending to the next one... A simpler solution (code-wise) would be to create a not-routing round-robin pipe, that would split the network and send items to a different sub-network every time, but I guess it will just add more confusion to the network thing... I could try to do round-robin with the requests and sinks tho, provided that they have the same priority.

[Paril]

Yeah, the Retriever (stole the name from Thermal's pipe system; they have the Servo for sending and Retriever for requesting, and if you don't specify an item in the whitelist it will just continuously pull from connected inventories) would be a step below a Supplier. A Supplier is a Retriever with a filter (maybe instead of two pipes, Supplier could be turned into "blacklist" mode where the filter you give it is an inverse filter; leaving it blank means it will just pull any item on the network that it can be provided).

Oh I see, I thought you could change the routing mid-destination somehow. From what I can tell, most uses of round robin pipes are solely from the point of extraction, so you might be able to get away with it being an upgrade to the Extraction Pipe and not have it work during routing. The sub-network idea is neat, but consider that if you need round robin you're likely working with quite a few outputs and might want to add more to the network if they are getting clogged or backed up. Personally for a system like this, I would use the above Retrievers with a buffer inbetween rather than trying to round-robin them, but if you have a super-smelter with 20+ furnaces for instance it would be more efficient to have the network route them to destinations in a round-robin fashion during extraction (which is just one server tick) rather than have each furnace try to pull an item from a chest every pipe tick.

[Ihamfp]

I just did some test, and there's a """bug""" with supplier pipes that can do exactly what you want with retrievers: in a supplier's config, put one item you don't want in the chest (or whatever) in the first config slot, and set the filter to any "blacklist": the pipe will request any other item, acting as a retriever. Haven't tested with multiple filters as, well, I thought I already fixed this x)

[Paril]

Hmmmm. So how would I go about this? I hooked up a Provider to a chest and a Supplier with such a blacklist, but nothing's being routed.

EDIT: doesn't seem to work in the latest version that I'm trying out. I can get it to supply specific items, but with a negating blacklist it doesn't wanna supply anything. It seems like this is basically the functionality we'd need though, just that a Retriever in Thermal Dynamics can have an empty blacklist (which acts as "anything"). I think even leaving that "bug" in (using a dummy item) would suffice for 99.99999% of cases.

EDIT2: but again, stressing that while Providers are great and for a case where you've only got one box to pull from it's efficient, they're extremely inefficient for a few kinds of tasks; some kind of pipe or mechanism to split routed objects evenly between endpoints would be more beneficial for these. Might need a creative solution for this though.

[Ihamfp]

Works in my dev environment, which is basically the latest version with a better pipe connection method.

[Paril]

So, with "Strict blacklist", it does work, but it only pulls one item and stops after holding one. It's a neat bug (seems more like what you would "normally" have to do with a Stock keeping pipe with stack size of 1 + negate blacklist) but not exactly what I'm looking for since I need it to keep filling up.

[Ihamfp]

That's a bug in the function that checks if the pipe can insert an item (it only search for a slot with an item that strictly matches the filter (here), which you cannot do with a filter that matches everything...), so a bug over a bug that could be a feature. Meh. I'll fix it and add an upgrade for the supplier to request anything by default.

[Paril]

Sounds like a plan!

I think it might be cool to be able to make pipes opaque as well with some kind of cover (kind of like an upgrade, maybe just a "proofing" item of some sort, separate pipe items might get too crowded) to allow people to make pipes not show items being sent (without needing to edit config or anything). Would be nice for network saving and such, so people can work on their pipe networks as normal and then once they're hidden behind walls proof them since they don't need to see what's going through them. Trying to think of what would make sense here.. A cover doesn't make sense since that's more like a block cover, and waterproofing doesn't make sense since they don't accept fluids or get destroyed by water.

[Ihamfp]

Please open a new issue for the cover/opaque thing, it'll be easier to track :) .

Also I've almost finished the retriever upgrade, it will work just like the trick with the blacklist, but more elegant. Still trying to figure out how to make a real round-robin tho, redstone-triggered request pipe maybe ? OpenComputers integration could do that with normal request pipes.

[Paril]

I'm thinking of some completely vanilla (just the pipe mod, nothing else) method of doing it. The only way I can think of doing it in a manner that fits this mod would be to have endpoints with some sort of ID attached to it (like the priority) and have the sender cycle priorities in ascending order. Any other method I can think of would require the sender to "know" about all of the endpoints at send time to pick the right one to cycle to, and would require a lot of heavy lifting if the network changes.

EDIT: It would also have to work with pre-existing filter options, which is why I had suggested an in-network pipe rather than a special Extractor pipe; the network can handle pulling the items any way it wants (whether it be a retriever from a distance or an extractor pushing into the network), and once an item hits that "Round Robin Routing Pipe" it's assigned its priority and essentially re-routed to a different destination based on that priority.

[Ihamfp]

Last edits for tonight, I ended up adding the retriever as a pipe as it was actually pretty easy. I'll release 0.2.7 when every disconnection-related problem is fixed*, but here is a build to play around with :p.

EDIT: *or maybe also wait for the round-robin to be implemented, depending on the difficulty. EDIT: I added the "sequencer pipe" (available at the same link as above), that can do round-robin but also anything sequence-related, what do you think of it ? Should I implement an "upgraded" version that automatically searches "robin" pipes and cycles between them ?

[Paril]

I'm on a week-long vacay at the moment but when I get home I'll give this a shot. Manual pipe cycling is pretty cool on its own, could be very powerful, but I wonder if the locator could be set in "auto" mode or something and a right-click just searches the whole network for matches and stores them just with one right-click on the pipe.

[Ihamfp]

Mhh, I might add an "auto-locator" that would add all the pipes in the network whose config matches the one you're right clicking, with a warning when you click an un-configured pipe (you dont want every routing node in your base to suddenly receive all your items...). And maybe add some computer interaction too, could be interesting using it with a counting pipe ...

[Paril]

Basically I'm just thinking of speeding up the most common use case for round robin: you have one output (a chest) that needs to send items to multiple inputs (furnaces, machines, whatever). In these cases, your pipe network only contains one output and many input. I'm sure there are other uses for round robin that exist within a larger pipe network where you wouldn't want to auto-configure, but 99% of RR cases are simple ones I believe.