Hello all, I would like to seek for some assistance on my LP setup.

Since I am new on this website, please do correct me if I need to provide more information or post somewhere else where it is more applicable. Right now, I am currently playing on a multiplayer Tekkit Lite server 1.4.7, with Logistics Pipes version 0.7.0.96 installed.

In the attached image is a screenshot of the LP setup I had in mind. There are supplier pipes partially requesting for some refined iron (9 stacks). They also have provider mk2 pipes attached to each of these "supplier chests" may you call them. My goal for this little setup is to keep a certain amount of material stocked, refined iron in this case, so that my network could use it for faster crafting. In an event that the inventory becomes low, the supplier pipes could request for more iron to be refined via crafting pipes in the same network (not in picture).

It seems that there is a problem with how the supplier pipe is sourcing its requests. The provider pipes on the same inventory or the ones next to it are providing the materials requested by the same supplier pipes. As a result, there seems to be an infinite loop with this request. The supplier does stop this loop with the provider pipe when I manually add the specified amount into the chest. Is there a way to make the supplier pipe to ignore the provider pipe that is attached to the same/nearby inventory and instead request from crafted recipes instead?

Eventually, the supplier does resort to auto-crafting to source its materials. However, that normally involves me to deplete all the supplied materials in these supplier chests, and the result is an exaggerated overstocking of materials into these chests (I assume because of the looping requests).

I have tried to tinker with the priority levels in crafting pipes for the recipes for these supplied resources in hopes that the supplier pipes will source its material from crafting and away from this perpetual provider loop, but to no avail.

Any help or guidance to the right place would be greatly appreciated. Others have suggested that I should make a separate "supplier" system away from the main network as to avoid the loop. Also, I believe that this issue is fixed in later versions of LP. Ultimately, I hope there could be further insight to this much older issue. Thanks

Since I am new on this website, please do correct me if I need to provide more information or post somewhere else where it is more applicable.

All fine :) Compared to other issues this has an overflow of information.

Any help or guidance to the right place would be greatly appreciated. Others have suggested that I should make a separate "supplier" system away from the main network as to avoid the loop. Also, I believe that this issue is fixed in later versions of LP. Ultimately, I hope there could be further insight to this much older issue. Thanks

I have seen your post on Reddit and I might need to look into the code to make a final answer, but generally I can tell that using suppliers and providers on the same inventory was never supposed to be supported. Using a chassis pipe might work because there might be a source <-> destination equality check. I cannot remember this being a specific fix. There is still the idea of having a buffer pipe that could be attached to any inventory and do stock-keeping, but due to the natural time limit of RL it wasn't added yet.

Is there a way to make the supplier pipe to ignore the provider pipe that is attached to the same/nearby inventory and instead request from crafted recipes instead?

This does sound rather neat indeed, but the supplier pipe did never get a "crafting only" mode, which would be rather easy to add tbh. That might be worth a shot actually. I am also not sure if the ComputerCraft integration was in 1.4.7, but another solution is using a computer and a request pipe to keep a chest supplied with only crafted items. The last and fastest solution is to separate the networks like someone on Reddit suggested. Again: not sure when the firewall pipe was added, but that might help you with the separation.

I hope I could shed some light on the issue

I am very impressed by your creative solution :) It's great to see you having fun with it. Technically this seems like a very good solution for your case. I am starting to think about other solutions, but other than what I came up with above, I have no idea for now

Thank you for your quick response! I appreciate that you were able to provide some suggestions to this issue. In regards to using chassis pipes with a provider module instead of the regular provider pipes, it seems that the problem still persists.

After with some investigation with BC logic gates, I think I have come up with a temporary solution to the lack of network communication between the provider/supplier pipes whilst not recognizing the same inventory that they are attached to.

The first image below is relatively the same setup that was initially causing the problem. The supplier pipes are attached on the bottom, and partially requesting materials (9 stacks of oak planks in this case).

What I have changed with the provider configuration where I set it to normal inventory, but only the supplied material is what should be supplied (oak planks in this case).

As a result, most of the slots in the inventory is filled to the brim with irrelevant blocks, with only the amount of slots needed to supply the inventory is available (only 9 slots available for 9 stacks of oak planks in this case).

For the basic gate (I have autarchic gate in the first picture, but it performs the same basic capabilities) that is attached to the supplier pipe at the bottom of the inventory, it is configured as so below.

When the gate detects that the inventory is full, the supplier pipe is disabled. This functions to stop the supplier from sending out unnecessary requests when its inventory is supplied correctly (in this case, the inventory becomes "full" when at least 9 stacks of oak planks have been supplied).

For the basic gate that is placed on the provider pipe, it is configured slightly different:

For this gate, when the inventory has space, the provider pipe will be disabled. This functions to prevent the provider in fulfilling the unnecessary requests made by the supplier pipe. Therefore, the supplier pipe will have no choice but to find other ways to supply the inventory (in this case, autocrafting the planks from oak logs in the same network).
Additionally, this gate also functions to enable when the provider pipe should do its providing to the network. It should only provide when the inventory is full (that is why the providing is configured to normal inventory, so that the manipulation of inventory space slots is made possible). In other words, the provider pipe will no longer have to respond to the requests from the supplier pipe attached the same inventory; rather, it can respond to other requests within the network.

This separation of signalling between the provider and supplier pipes should stop the request looping. I have done some manual requesting to test if the loop persists, and it seems that the looping have stopped or at least doesn't persist indefinitely.

I hope that my investigation on this issue makes some sense. I am by no means someone who knows how to code/program or do computer stuffs. I am simply somebody who likes to have fun using LP (AE is too overrated, anyways).

Nonetheless, it would be ideal if there could be some feedback on my findings and maybe some suggestions on how to further pursue these types of problems in the future.

Thanks for reading until the end!

Update:

I think I spoke too soon, or my little test system gave me too much hope. It seems that this workaround for this loop also resulted in the inability of the provider pipe to provide the materials when something is being crafted (something resource intensive and not just crafting oak planks from wood, for example). In a way, the provider pipes were "gated" in completing the crafting orders.
I removed the gate conditions that were placed on the provider pipes, and everything was back in order. Even the request loops were back, too.

It seems that I might need to explore other, more different approaches in working around this issue. As you and others previously have suggested, how would one go about in creating a separate supplier network away from the main network? More importantly, would there need to be separate crafting network within that supplier network, or could the supplier network somehow source its materials via the crafting recipes that are already present in the main network? Indeed, this version of LP does have the firewall pipe. I will keep investigating into this as we speak.

Finally, I could potentially explore the suggestion with ComputerCraft and request pipes. I'll leave this one for last, as I am not really familiar in working with this part of the modpack.

I guess what caught my attention with using LP over other, more convenient, automation systems is its potential capabilities as a system that can do almost everything (well in Tekkit LIte 1.4.7, respectively), but not without some steps in problem-solving that normally would become obsolete in other automation systems.
With that being said, my focus with using LP is "how big/complex of a system can I make just by using the basic capabilities that LP provides?" I really think that is why I am, in some ways, persistent with small problems like this one (With respect to this issue, I really want to keep all of this in one big network).

I hope that this provides more information as to why I am somewhat interested in pursuing this issue.

Update 2:

After with some tinkering with the firewall pipe, it seems that I have found new issues in the setup of semi-separated specialized networks.

In this setup, the supplier pipe (front) is requesting some oak planks. The two systems are separated by a firewall pipe (I think in this version, the firewall pipe blocks power by default, and there is no option to change that in the GUI). The firewall pipe is configured to only allow crafting requests and not sorting/provider requests.

The other side of the network that is separated by the firewall pipe is a diamond chest providing some oak logs. A crafting pipe for oak planks is also available on the other side. I have tested the firewall's ability to block provider requests, and it seems to work. The supplier pipe cannot see oak planks directly provided by the chest past the firewall pipe. The crafting recipe on that side is also available to be used past the firewall pipe.

As indicated in the first picture, the supplier pipe is attempting to fulfill the request for oak planks. The supplier pipe did request this through autocrafting rather than to siphon the existing oak planks that is provided in the diamond chest. However, it seems that, even though the firewall pipe is configured to allow crafting requests, you can see in the first picture that the firewall pipe is prevent the materials from passing through the pipe and into the chest (front) being supplied.

What might be the cause of this restriction by the firewall pipe, even when the the GUI states that these type of requests are allowed? Does the system inventory connector pipes have anything to do with this? (I am using them to simulate the actual LP network I have on the server).

Hopefully, as much as this issue is probably resolved in later versions of LP, there could be some sort of elaboration onto this particular problem in regards to firewall pipes.

I believe that there are still some options left in working around the overall issue as mentioned previously and by others:

1. Creating a completely separate supplier network equipped with its own crafting recipes and raw materials provided separately.
2. Have everything in the same network, but only limited to 1 unique supplier pipe and not multiple duplicate supplier pipes that can result in supplier/provider loops. That being said, it means that I can only properly supply a maximum of <18 stacks of 1 type of item in a given network.
3. Utilization of ComputerCraft and Request pipes (not really sure how that will work).
4. Continue to explore logic gates and somehow disable these pipes depending on various conditions while not interfering with other requests made by the network, just like my attempts in the previous response.
5. ???Hope???