Jump to content

Pipe source priority


Recommended Posts

I know you can use pipe bridges to take priority of water flowing out to prefer going to the bridge over the other path, but how can you prioritize one source over another?  I have some polluted water coming in from my NG gen, but if that isn't enough I want the water sieve to pull from the pump in my main pool.

Link to comment
https://forums.kleientertainment.com/forums/topic/94767-pipe-source-priority/
Share on other sites

1 minute ago, RonEmpire said:

I made water sensor that detects when one line is clogged it automates to close off another line so that there is a priority to the one that is clogged up.

You can do it as described above with just pipe bridges, and knowing how they work. No need for automation in most cases.

Pipe bridges work on the simple principle that a liquid or gas will always prioritize going across the bridge but only if there is room in the pipe on the exit. So the OPs problem can be solved with just one pipe bridge from the aux line into the main line. Nothing else is needed.

An example of what Saturnus said in action, a self refilling refinery.

5b7f38fbd172b_Selfrefillingrefinery.thumb.jpg.24dea950748cd24be6bd246662772be4.jpg

Because of the bridge in the bottom right, the fresh coolant that comes from the bottom will only be able to go through if there's no coolant being recycled from the refinery for another round. A thermo sensor is used to decide whether the coolant can be recycled or is to hot and must be expelled to the left.

2 hours ago, Grimgaw said:

Nothing changed with bridges for a loooong time. 

Let me correct that. Nothing has changed with bridges except visual appearance. The mechanics of how they work have been exactly the same since the very first alpha release. So they've literally never changed.

2 hours ago, Saturnus said:

Let me correct that. Nothing has changed with bridges except visual appearance. The mechanics of how they work have been exactly the same since the very first alpha release. So they've literally never changed.

Umm... no?  That thread that describes how to stack two pipe bridges to combine packets into full size ones noted that they changed them I think in CU and it no longer works.  Now you have to use element sensors and shutoff valves.

3 minutes ago, psusi said:

Umm... no?  That thread that describes how to stack two pipe bridges to combine packets into full size ones noted that they changed them I think in CU and it no longer works.  Now you have to use element sensors and shutoff valves.

Not sure which thread you're referring to but packet stacking still works for me in EU.

20 minutes ago, Grimgaw said:

What you're showing still works like it did before, so only if the valve is set to 0.625, 1.25, 2.5 or 5kg in case of liquid.

I'm pretty sure I did that and it still didn't work.  The other thread you linked also says it no longer works.  Also in order for it to work, a bridge would have to output into a pipe that is not completely empty, which would mean you can't use them to prefer one input source over another.

An infinite in-line stacker with element sensor and liquid shut off also works. It outputs only full packets regardless of input flow.

image.thumb.png.3a7ff16a323ec3bcceb0779a3febb7c3.png

image.thumb.png.e92795f70164014cecfb7d4c142d7f6a.png

Here it's a little more clear how it's built but as shown above it works even when the loop bridge is tucked in on the same line.

image.thumb.png.c6cf3445af83732fbb98926152bd168b.png

 

@SaturnusYeah I linked the element sensor one. @psusi was talking about the first image from this thread:

The OP says it's broken, but I can confirm that it works exactly like it had before ( but only with the values I listed above).

Hope that helps clear things up.

If anyone can explain how this two bridge thing works I'd be grateful. The packets get confused due to outputs on both ends of the pipe.

 

16 minutes ago, Grimgaw said:

Agreed.

The difference is that the opposing bridges. The by-pass and loop bridges. Together with the element sensor forms a blockage detector. This part can be used to stop machinery that requires unrestricted outputs to function or to indicate when a buffer is full. The valve is in my case just used as a deliberate blockage.

3 hours ago, Saturnus said:

Are you guys just trolling me? Packet stackers still works fine in EU. At least the way I have always built them. Just tested it.

image.thumb.png.79d85932f2d54b44c8c8b26422571292.png

How the hell does that work?  If the first valve ls limited to 500g, then at the fork in the pipe, 250 will go each way.  The only way the 250 going through the bridge will end up giving you a full packet is if the second valve outputs 9750g, which it isn't going to do.

2 hours ago, Grimgaw said:

@SaturnusYeah I linked the element sensor one. @psusi was talking about the first image from this thread:

The OP says it's broken, but I can confirm that it works exactly like it had before ( but only with the values I listed above).

Hope that helps clear things up.

If anyone can explain how this two bridge thing works I'd be grateful. The packets get confused due to outputs on both ends of the pipe.

 

When I tried to get that to work, it seemed to keep looping the small packets back and building up bigger ones, but once the system reached steady state, it kept outputting one full packet, one partial, one full, one partial.

3 minutes ago, psusi said:

then at the fork in the pipe, 250 will go each way.

Forks don't work this way. Forks alternate packets into branches.

3 minutes ago, psusi said:

it kept outputting one full packet, one partial, one full, one partial.

That's why you need those specific values I mentioned. The packets are doubling until full and then send left over.

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...