Jump to content

Why is the pump claiming these pipes are blocked?


Recommended Posts

First of all, sorry if this question is posted in the wrong place.

I did not see a questions/help board, so here I am.

fu3Mw7Y.png

The hovered pump is claiming two pipes are blocked, but I can't find the locations of these blockages. It only has 3 outputs; 2 Electrolyzers, and 1 Carbon Skimmer. All are functioning albeit more slowly than they should be.

Any ideas?

Link to comment
Share on other sites

OK, first off, every time you branch, packets start to alternate -- even if you're not drawing at full capacity.  So, since your skimmer is at the end, its getting 1 packet in 3.

Second, the "pipe blocked" that you're seeing at the pump is because the water in the line isn't flowing fast enough for the pump to move a full packet. Its normal and you can just ignore it.

You can use bridges to more efficiently move contents of a pipe.  For example, in this shot, I branch off to feed water to bristleblooms.  Instead of alternating packets, only the water necessary for the plants gets diverted:

Spoiler

image.png.f36ef5049cccc8286403ec8ede9d8fe2.png

 

Link to comment
Share on other sites

The water is confused on where to go. Every packet after the first T will try to go back upstream occasionally. Use bridges to pull the water off the trunk line for the 2 electrolizers. 

Also note that when you make a T in the pipes like you have for the 2 electrolizers, the water will take turns on each pipe no matter what resulting in half flow rate after each T. 

You can avoid this problem by using a bridge "into" the T. This will have packets keep taking turns but will skip full directions resulting in full flow if another direction is full.

Thus will also prevent the back flow calculations that are messing with your system. 

Link to comment
Share on other sites

The consumption from the skimmer and electrolyzers is less than the output of the pump, the pump is blocked periodically until a whole packet is used, then will pump for one tick, releasing 1 extra packet and then go back being blocked again.

 

Link to comment
Share on other sites

5 hours ago, ArtumisPrime said:

The pipe continuing to attempt the sending of water to a full pipe is a dumb interaction, though I understand it programatically.

The bridge information will help a great deal.

Thank you.

No problem. Learning the quirks of bridges/valves/shut-offs/anything with white-green input/outputs will help out immensely. 

Quick summary:

White has priority. So if you want to split your pipe into 2 but want as much as possible to go one way (Bristle Blossom farm, Exo suit docks) and only the extra to go the other way way (to storage), use a bridge. 

Green looses priority. Use this when you want to merge 2 pipes but want use all of one pipe and use the other to just top off packets. This is how you would run an electrolizer off a geyser but pull water from storage when the geyser is dormant. 

Green will distribute to up to 4 pipes in turns but, unlike pipe T's, it will partially fill or flat out skip full pipes. I use a pair of these to fill my 8 Exo suit docks. 

Link to comment
Share on other sites

53 minutes ago, Yunru said:

Pipes split normally also ignore blocked routes.

Not in my experience. Then again I haven't used pipe splits in a long time so they might have fixed it. I'll mess around with it in a bit. 

Edit: Yep.  No recent changes. Pipe T's still act as I described them. T's in pipes do not ignore full/blocked routes.

Pump to left, liquid vents to the right. Bottom path's vent is underwater so it will block. Top path is open to drip. First picture: Liquid taking turns as it should as both paths are currently open.

Spoiler

20190501103656_1.thumb.jpg.ea994ffe390bc98fa12fd0da0a1b3429.jpg

Second picture: Bottom path blocked, top path still getting only every other packet. (The 2 in a row was from when the bottom path first backed up, probably due to the incomplete first packet that all pumps seems to send.)

Spoiler

20190501103723_1.thumb.jpg.94af16bac448f10211dca8f5d025e94b.jpg

Third pic: Removed a piece of piping and bridged into the junction. All available flow being pushed to the open path. Will go back to every other behavior once bottom path clears.

Spoiler

20190501103806_1.thumb.jpg.38e0f64df0b67452b56da5a2c9a54e4d.jpg

 

Link to comment
Share on other sites

Okay, just double checked myself. Blocked pipes are ignored, your vent is getting every packet.

What is happening is that the blocked pipe is still getting checked, so your packet takes twice as long to decide as compared to coming off of a bridge.

 

The thing that makes this not just semantics is consumption: The vent still uses everything that's consumed, consumption just drops 50%. Saying that it only receives 50% suggests that 50% is being lost to the aether.

Link to comment
Share on other sites

24 minutes ago, Yunru said:

Okay, just double checked myself. Blocked pipes are ignored, your vent is getting every packet.

What is happening is that the blocked pipe is still getting checked, so your packet takes twice as long to decide as compared to coming off of a bridge.

 

The thing that makes this not just semantics is consumption: The vent still uses everything that's consumed, consumption just drops 50%. Saying that it only receives 50% suggests that 50% is being lost to the aether.

 

On 4/30/2019 at 10:59 PM, beowulf2010 said:

The water is confused on where to go. Every packet after the first T will try to go back upstream occasionally. Use bridges to pull the water off the trunk line for the 2 electrolizers. 

Also note that when you make a T in the pipes like you have for the 2 electrolizers, the water will take turns on each pipe no matter what resulting in half flow rate after each T. 

You can avoid this problem by using a bridge "into" the T. This will have packets keep taking turns but will skip full directions resulting in full flow if another direction is full.

Thus will also prevent the back flow calculations that are messing with your system. 

That's what he said, my dude.

Link to comment
Share on other sites

6 hours ago, G-Forces said:

Klei really should just fix the pipes so that "T"s in them work properly

The T's work just fine as far as ONI physics are concerned.  The game does not truely model fluid dynamics.  Instead, it treats each packet as an individual item.  Which is why you can have a packet with 42g of water while packets on either side have 10kg.  In a normal pipe, you would have a continuously full pipe.  In real physics, when water comes to a T junction, it splits uniformly to both sides, halving the pressure.  The pipe is still full, but if both pipes are the same diameter as the initial pipe, then the rate of flow changes.

What this means is that in ONI physics, each discrete packet of water must move individually to the next free space.  When the water comes to a T, the flow must split.  Rather than split the individual packets (would add some extra math overhead), ONI alternates packets.  First one side of the T gets a packet, then the next.  If one side of the T is full, then the packet doesn't move.

This is consistent with the way that everything else in ONI works.  Therefore, the problem isn't that the T isn't working properly -- the problem is that ONI doesn't model fluid dynamics.  

Link to comment
Share on other sites

On 5/2/2019 at 2:19 PM, KittenIsAGeek said:

The T's work just fine as far as ONI physics are concerned.  The game does not truely model fluid dynamics.  Instead, it treats each packet as an individual item.  Which is why you can have a packet with 42g of water while packets on either side have 10kg.  In a normal pipe, you would have a continuously full pipe.  In real physics, when water comes to a T junction, it splits uniformly to both sides, halving the pressure.  The pipe is still full, but if both pipes are the same diameter as the initial pipe, then the rate of flow changes.

What this means is that in ONI physics, each discrete packet of water must move individually to the next free space.  When the water comes to a T, the flow must split.  Rather than split the individual packets (would add some extra math overhead), ONI alternates packets.  First one side of the T gets a packet, then the next.  If one side of the T is full, then the packet doesn't move.

This is consistent with the way that everything else in ONI works.  Therefore, the problem isn't that the T isn't working properly -- the problem is that ONI doesn't model fluid dynamics.  

The problem with that is that when one side of a t is full already the fluid flow will pause at it slowing down the entire pipe

Link to comment
Share on other sites

1 hour ago, G-Forces said:

The problem with that is that when one side of a t is full already the fluid flow will pause at it slowing down the entire pipe

Yep. KittenIsAGeek is aware of that. They were just expanding on the point that it's not the T/4-way junctions themselves that's the bug, but that it is the entire packet distribution model that is bugged.

Klei can't fix the T/4-ways by themselves, they will have to rewire the package model, thus currently T/4-ways are "working as intended" and/or a feature pending a possible packet distribution rework. 

This is why us veterans think it's so important for beginning players to learn to use bridges early. 

Link to comment
Share on other sites

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...