Background:
I created a very large warp itemduct network. It was the backbone of my logistics network.

Scenario:
I connect any additional logistics pipe to the warp itemduct network.

What should happen:
The pipe and the duct connect. The duct's connector turns green. The pipe becomes part of the logistics network.

What actually happens:
Every single connector between that warp itemduct network and any logistics pipe turns red. The entire logistics network becomes fragmented into little pieces because the itemducts are no longer connecting to them.

Hacky fix:
Break up the warp itemduct network into smaller bits by placing basic logistics pipes at strategic locations.

Comments:
When I say 'warp itemduct network' I mean a bunch of warp itemducts that are all directly connected to each other, forming one giant branching pipe system that is all powered as a unit.

I cross-posted this issue on Team CoFH's feedback repo: CoFH/Feedback#1265

May be related to #1065

You need a basic pipe anywhere an item can go down more than one path (intersection of more than two).
The hacky fix may be what you're meant to do.

@BlueAgent This is not the case for itemducts. Itemducts have basic routing capabilities. When an item enters an itemduct from a logistics pipe, logistics tells the itemduct where it should be routed (within that itemduct network).

When using buildcraft pipes, yes, you do have to have a logistics pipe at every intersection. But that is because buildcraft pipes have no ability to route.

That's very cool, I will be using ducts much more often for LP!

Itemducts are awesome and I love them almost as much as I love logistics. Warp itemducts are heaven. They have speed up my logistics system incredibly. As long as you have the resources and power, I would suggest you never use anything else. You can build massive systems and still have the speed of a small network.

As far as my insight goes, and please dont quote me on this, LP itself uses a Modified A* Routing Algorithm...no idea what Thermal Dynamics runs Internally. But Probably either A* or Dijkstra too

But you allready came up with the most prominent Solution to the Problem.

As i played alot with Warp Systems. I can give you some tipps: have a Central "BUS" Warp line, as straight as Possible. Have sublines going from there, no direct connections to the BUS.

Il make a Drawing when Im home in half an Hour

@firelizzard18 @BlueAgent
The Number of allowed Connections per Itemduct Line is there for a reason, ive debugged that with davboeki for a long time.

Basicly if we go above our current Cap of, 32 I think it is, you quickly run into problems where the discovery algorithm for routes to take, that is based on the Thermal Dynamics internal routing algorithm, runs so long that it halts your server and causes it to think its frozen and shuts down.

So, the Disconnecting effect is entirely Intentional.

Davboeki allready mitigated the crippling effects of the discovery by caching the routes once they have been taken, so discovery only runs exactly once for N routes, given the connections are unchanged. But everything over 32 I/O Connections on a Duct line is basically impossible to handle for a Server.

That's fascinating. What kind of search algorithm are you using?
On Thu, Oct 20, 2016 at 08:19 Bitterholz [email protected] wrote:

@firelizzard18 https://github.com/firelizzard18 @BlueAgent
https://github.com/BlueAgent
The Number of allowed Connections per Itemduct Line is there for a reason,
ive debugged that with davboeki a long time.

Basicly if we go above our current Cap of, 32 I think it is, you quickly
run into problems where the discovery algorithm for routes to take, that is
based on the Thermal Dynamics internal routing algorithm, runs so long that
it halts your server and causes it to think its frozen and shuts down.

So, the Disconnecting effect is entirely Intentional.

Davboeki allready mitigated the crippling effects of the discovery by
caching the routes once they have been taken, so discovery only runs
exactly once for N routes, given the connections are unchanged. But
everything over 32 I/O Connections on a Duct line is basically impossible
to handle for a Server.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#1069 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA1pzydOje1ytCRnrJJ0tFpi_gPJwr3uks5q14ZrgaJpZM4KZSoU
.