Jump to content

Pipes / bridges priority cheat sheet


Recommended Posts

Just now, Lawnmower Man said:

Ok, then you'll have to explain your scenario in a little more detail.

Ok. So E's not running. The output's not accepting anything for one reason or another.

Without a bridge, a backlog of F forms, preventing E from ever entering the pipe unless a full packet of F is removed first.

With the bridge... it's... much... the same?

 

Why did I think the bridge would make a difference again?

Link to comment
Share on other sites

27 minutes ago, Yunru said:

It's only if you have inconsistent flow rates. Say E only operates half the time. Without a bridge, if the line backs up, only F will flow.

This is incorrect.  Every time E sends a packet down the line, it has a 50% chance to get on the output line.  That's because the alternation does not happen "per tick".  It happens *per conflict*.  If F gets the line all to itself, it stays "F's turn" until E sends a packet.  Once it does, and the pipe engine sees that both E and F want to place a packet onto the merged segment, it will switch to "E's turn", and then they will alternate, bridge or no bridge.  That's because the join is happening *at the pipe*.  The sink does not come into consideration until the pipe merge is resolved.

Link to comment
Share on other sites

54 minutes ago, Nitroturtle said:

I think you might be right about F, but there's definitely a difference with A, specifically when one line is backed up.  Without the bridge, the pipe that's not blocked will receive packets at half the rate.  With the bridge, full flow will be maintained.  Try it in game and the difference will be obvious.

I checked this very scenario in game, but I'm too lazy to make a movie of it.  I observe that flow proceeds at full velocity onto the unblocked branch.  When I have seen the stuttering, it is always because there are multiple ambiguous sinks on the line, or a branch is not consistently blocked.  In those scenarios, a bridge/source doesn't resolve the conflict and cause smooth flow.  The only time that a bridge resolves flow issues is when a packet has the option *and preference* to travel backwards, and the bridge prevents that.  For instance, if you put a sink after A but before the split, you can make a packet bounce without a bridge.

Link to comment
Share on other sites

9 minutes ago, Lawnmower Man said:

This is incorrect.  Every time E sends a packet down the line, it has a 50% chance to get on the output line.  That's because the alternation does not happen "per tick".  It happens *per conflict*.  If F gets the line all to itself, it stays "F's turn" until E sends a packet.  Once it does, and the pipe engine sees that both E and F want to place a packet onto the merged segment, it will switch to "E's turn", and then they will alternate, bridge or no bridge.  That's because the join is happening *at the pipe*.  The sink does not come into consideration until the pipe merge is resolved.

Which only matters if there's an empty section. Which there won't be if the output isn't taking full packets.

...

Right?

Link to comment
Share on other sites

3 minutes ago, Lawnmower Man said:

I checked this very scenario in game, but I'm too lazy to make a movie of it.  I observe that flow proceeds at full velocity onto the unblocked branch.  When I have seen the stuttering, it is always because there are multiple ambiguous sinks on the line, or a branch is not consistently blocked.  In those scenarios, a bridge/source doesn't resolve the conflict and cause smooth flow.  The only time that a bridge resolves flow issues is when a packet has the option *and preference* to travel backwards, and the bridge prevents that.  For instance, if you put a sink after A but before the split, you can make a packet bounce without a bridge.

Take the same branched line, remove the bridge and replace with just pipes.  When one path is blocked, the second path will receive half flow rate.  I'm not talking about bouncing packets.

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