Logistics Pipes

Logistics Pipes

13M Downloads

Taking unrouted items entering a crafting pipe as results

Faerdan opened this issue ยท 11 comments

commented

I have a number of crafting pipes (mk2) set up with assembly tables (each pipe connected to a single table, providing resources for a single recipe).

When an item, or items, are requested (by a request pipe/table or supplier pipe) from one of these crafting pipes the item is created but it does not route to the requester, it goes to the default storage instead.

The requester still seems to be waiting for the request to be fulfilled. When using a supplier pipe for example it will not make another request for the items, so the items are never delivered.

If you could help with this I would really appreciate it.

I'm using Logistics Pipes #102 and BuildCraft 4.2.2.

commented

AFAIK assembly table ejects to nearest inventory or pipe.
So the solution would be to count as crafting result any item which enters crafting pipe from the machine side, without checking if its pulled or pushed.

commented

Hmm, something very close to this was implemented by @6dc96d0cc0b4110de62f9dca3ca9c725130ce892 and appears to have been killed by @590bdc9e0f2f284aa207b8f45c860e02137624b4 in the port to MC16.
Should be relatively straightforward to re-implement in pretty much the same way.
On second thought... adding a new method in CRP and override in crafting pipes, or changing the name/semantics of getQueuedForItemStack might be better.
Abusing getQueuedForItemStack the way I did is quite ugly in retrospect.

commented

What I did'n get yet is where pipe reacts on unrouted item entering it.
Such event/method should be the proper place.

commented

@ArtForz I've got why you've changed getQueuedForItemStack - actually it was the only present place where we could influence routed entity before actually assigning route.
Though I've got an idea on how to do this more elegant.

commented

I'm guessing the crafting pipes only count as crafted when it extracts the items, otherwise it is treated as any other item entering the network. As a workaround, you can use a supplier pipe to supply the assembly table and a chest next to it with the crafting pipe on it.

commented

Ah yes, that makes sense. The supplier pipe would continually supply the assembly table though, not on demand?

commented

Whoops I meant a satellite pipe.

commented

yes that is currently the workaround for that

commented

@Faerdan what you see is the current behavior of LP and of BC's Assembly Table. I don't know if this is a bug per say. The BC table outputs to an adjacent inventory; The LP Crafting pipe wants the result back via that same pipe. You can place a chest next to the BC table and put crafting pipes on the chest and a satellite pipe on the BC table. Set your recipes on the crafting pipes but with ingredients all going to the satellite pipe and LP will put ingredients in the BC table and when the table feeds the chest, the crafting pipe will pick it up and everything works.
lp_laser

commented

Updated the title to actually reflect what is needed. Making the assembly table work with LP is possible with a chest, a crafting pipe and a satellite pipe.