Bridge issues

Here is a picture of the computed flow:

The flow is away from sources towards sinks:

The flow to the left of the bridge output is ambiguous -- and our updated algorithm seems to determine differently which way it should flow than before. Your best bet is to avoid ambiguous segments like this, e.g. by putting the bridge on the vertical segment above the pump, then everything agrees about which way the liquids should flow.

We plan to leave this new algorithm in place. Hopefully I've provided some clarity.

Changed Status to Closed

Hi Chris P,

Thanks for your reply. Unfortunately, I still have a couple of concerns with the new algorithms. Could you perhaps elaborate on the following cases on what is happening with the flow here and why the algorithm refuses to acknowledge a what seems to me to be a legitimate build?

 

I set up a basic sweeper-loader-split layout. The left lane goes straight to a chute, the right lane goes also straight to a vent, but with several merging lanes from other loaders who would also like to dump to the right chute. Tested in all cases with 8 shine bug eggs.

Experiment (A)

As far as I can see, both ends have a output, and yet, the first packet that enters the system tries to go right. It then bounces endlessly between the right chute and the T-junction. Meanwhile all other 7 packets will be forced to go left. After the last packet turns left, the original first packet will also cross from the right to the left and all 8 eggs end up going left, instead of splitting evenly as would be expected. Merging the additional loaders on the left with bridges clearly wouldn't work, since that would be the same case as in my original post.

Variants in the system (B) other loaders directly connect to chute, (C) other loaders connect after the chute: result is the exact same situation as in (A) - I would have thought that with the chute being at the centre/before the other loaders, that packets would flow there unheeded. Not the case.

(D) I add a bridge to the right lane, and now the packets split evenly along both lanes.

 

My concerns are, why is it so difficult to deal with merging and splitting? I feel like this is counterintuitive to a lot of systems that players use to move gasses/liquids/items around and adds an unnecessary step (in this case, a redundant bridge) and complicates builds which are in some cases space-restricted. The moment one side of a split has a "merging" output (including the 'output' end of bridges), it seems packets will try to avoid that route, even if there are viable outputs that are closer or on the way (e.g. C).

The fact that the first packet in (A)-(C) actively chooses to go right, only to uselessly bounce back and forth, blocking the route, seems like a bug as well, rather than a feature.

Could you perhaps elaborate on what makes a packet choose to go in a certain direction at a junction? What causes it to bounce back and forth? Is it merely the presence of an output on one side that makes them avoid it, or is it more complex, and they check/compare how many inputs/outputs per side and decide to go where there are more net inputs? Is the distance between junctions/merging/input/output important?

EDIT: I noticed that (A)-(C) would work if I placed the right chute further away from the merging loaders (at least 1 tile gap between merging junction and chute). Still won't work if I join any of the additional loaders with a bridge. The packets will always go:

1 packet right - it will bounce between bridge output and T-junction - 2 packets go left (1st by logical split, 2nd because right route blocked by bouncing packet) - bouncing packet then passes the point where the bridge merges and exits chute. Process starts again with the next packet (repeats every 3 packets).

 

Hope to understand more and optimise my layouts. Cheers!

Vasco

Edited July 12, 2019 by 644232_1452791058

Hi @644232_1452791058

The solid conveyors actually haven't changed yet, they're still running on the old system. We're in the process of upgrading it to the optimized system.

Some of the problems with the old system included the "bouncing", and also that the factors which decided the direction of an ambiguous piece of pipe were very touchy and unpredictable. The new system doesn't have bouncing and should be much more stable in deciding which direction a pipe goes. 

We really appreciate these explorations though! Once the new solid system is in place, give it a try and let us know if you see problems. Or, run your experiments with the liquid or gas systems and let us know how it feels, as they do represent the newest code. Thanks!

Okay cool, good to know! I was a bit irritated, because the solid conveyors weren't behaving as expected, but now I know why!

I'll have a look at some 'complex' liquid/gas piping and see if I notice any strange behaviour. Right off the bat, I already have another couple questions after doing some testing. See below:

(A) One pump connected to two vents: 50-50 split of packets (as expected).

(B) Two pumps connected to two vents (no bridges): middle output splits 50-50, right output sends all packets (every 2nd packet because of incoming packets from the left) to the right input.

(C) Three pumps connected to two vents. Only the pump all the way on the left splits 50-50, the one in the middle sends a packet every 4th packet (only to the right), the one on the right sends a packet every 2nd packet (also only to the right), regardless of which order the pipes are connected.

Why do packets from the left have 'right of way'? It doesn't matter which pipe I connect first, an output on the 'left' will always override any other outputs joining the line. It will be the dominant 50-50 split, while all other outputs will divert to the right. Is this behaviour prevalent across all systems and is there a reason for this? Or are there also cases where packets from the right have 'right of way'?

 

Also, last observation for today (gotta sleep at some point):

Each time you lay piping, packets 'reset'. If you do this every second - or more accurately, before the packets completely move to their next position - they will jump back and move forward again. This results in interesting behaviour at junctions, because each time a packet 'jumps' back, it will always opt to go left upon reaching a junction, regardless if the previous packet was already sent left. In the above picture, I repeatedly 'placed' a pipe to achieve the following picture. I say 'placed', because I didn't even lay new piping, I simply selected pipe and clicked on a tile where existing pipe was present - i.e. I didn't 'build' any new pipe, I just executed the action of placing pipe. So instead of a 50-50 split, all packets were sent to the left. I assume this is not intended behaviour?

Cheers,

Vasco