[1.45] Turtles dont connect to LogisticPipes

I'm running a small modded Server. Today I upgraded some of the Mods
Buildcraft (3.2.0pre7 -> 3.2.0pre9)
LogisticPipes (-> 0.5.1.pre11)
ComputerCraft (1.43 -> 1.45)

Since this Upgrades LogisticPipes no longer connecting to turtles, normal BC pipes still work.
Don't really know if this is CC or LogisticPipes bug or just a feature.

I'm using the Forge build 4.2.5.312


–truh

Well we implement IInventory and ISidedInventory - everything logistics pipes should need to connect to us. This is probably an issue in Logistics Pipes.

Thanks for your answer, I opened a issue at the LogisticPipes github repo.
https://github.com/RS485/LogisticsPipes/issues/171

I believe logistics pipes these days actually implement IPeripheral, ie: they can be interacted/controlled by computercraft, and they have methods to explicitley requesting being connected. it's interesting stuff.

This is intended. There is a CC command inside LogisticsPipes to enable and disable the connection. Call setTurtleConnect(true) on the pipe as a peripheral and the pipe will connect to the turtle.

Example:

pipe = peripheral.wrap("front")
pipe.setTurtleConnect(true)

The connection get's reset, when the turtle moves away and it is only activated on the specific side the turtle is on so there can be more than one turtle next to the pipe but only ont turtle is connected.

There are more commands for LogisticsPipes: A temporary list can be found here: (may change)
https://docs.google...._RgivBTyCg/edit

davboecki

So I can make LogisticPipe requests from a turtle? pretty cool

Woah, LogisticPipe's has a peripheral API? Nice!!!

local reqID = pipe.makeRequest(1,1)

I'm trying to request 1 stone from the system, but function returns me: invalid ItemIdetifierID. What should be the first argument?

seems

local reqID = pipe.makeRequest(getItemIdentifierId(1,0),1)

Hm, but this function is in the "Basic Pipe" table, not from the request one, but I'll try it, thanks.

— Edit —

Nah…

nor

local reqID = pipe.makeRequest(getItemIdentifierIdFor(1,0),1)

nor

local reqID = pipe.makeRequest(pipe.getItemIdentifierIdFor(1,0),1)

didn't work. The result is the same: Attempt to call nil.
The first time, I think, its because the semantics should be like "obj.func", like in the second example. And the second time its because its the request pipe, not basic, so it has no such function. Lol, there should be the type casting for the pipes ^_^/>/>.

So, how should I get the "ItemIdentifierID" for the "makeRequest" func?

local reqID = pipe.makeRequest(pipe.getItemIdentifierIdFor(1,0),1)

That's not the correct command. The Command is

local reqID = pipe.makeRequest(pipe.getItemIdentifierIDFor(1,0),1)

Google Document has been corrected. Sorry for the mistake.
Also all Basic Commands should be available for every Logistics Pipe. You don't need something like type cast to access them.

Yeah, thats working, but there is a major trouble here. I mean in makeRequest function.
When I request anything manually, I can control if there is somthing that is missing, whrn crafting a complex item. When I request this item via turtle, it requests this item regardless these missing parts, so the item doesnt create, but the queue for the colatteral components grouws bigger, I ended up with the couple of thousands requests on an Iron ingot crafting pipe. These queues completely shut the whole network down and make the MC client being shut off from the server due to DoS with "end of stream".
So I think the function should return not the ID of the request, but SUCC, or FAIL (true/false) considering the availability of all the requested sub components, if any thing is missed, the request should not be executed.

Kalembas, on 04 November 2012 - 05:34 AM said:

Yeah, thats working, but there is a major trouble here. I mean in makeRequest function.
When I request anything manually, I can control if there is somthing that is missing, whrn crafting a complex item. When I request this item via turtle, it requests this item regardless these missing parts, so the item doesnt create, but the queue for the colatteral components grouws bigger, I ended up with the couple of thousands requests on an Iron ingot crafting pipe. These queues completely shut the whole network down and make the MC client being shut off from the server due to DoS with "end of stream".
So I think the function should return not the ID of the request, but SUCC, or FAIL (true/false) considering the availability of all the requested sub components, if any thing is missed, the request should not be executed.

That's a LP bug, tell the LP developers.