Lawnmower Man

  • Content count

    175
  • Joined

  • Last visited

Community Reputation

64 Excellent

About Lawnmower Man

  • Rank
    Member
  1. The steam takes such a long path that I don't understand the purpose of condensing it. I thought the main benefit of condensing is that it's much easier to move around liquid than "free gas". In your setup, the steam just takes a tiny U-turn through the liquid phase. All I can guess is that the vacuum created by condensation is creating all of your steam pumping force. Is that the case? Also, did you consider trying normal tempshift + metal/glass, just more widely spaced? I know you lose temperature gradient resolution, but it seems like it would be...more elegant? Overall, I like what you did, and I relearned a few of the lessons the hard way, so I appreciate what this build represents.
  2. 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.
  3. 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.
  4. Ok, then you'll have to explain your scenario in a little more detail.
  5. F does no such thing. There are two sources on the input side of the bridge, so even if the vent is overpressured, packets will never flow backwards towards a pump. If you had a combination of sources and sinks on the input side, then directionality becomes essential. But notice that this is handled in the "go towards closest sink" rule.
  6. What is the point of a stable?

    Might be a little out of date, but still pretty authoritative on critters:
  7. Sorry, but I just observed behavior contrary to 1). If one branch is full on a plain pipe split, I observe that the other branch is taken with no delay. When you see the turns being taken by both branches, I assert it is because the pipe is just "mostly blocked" and clears up enough to trick the pipe engine into sending a packet down a branch, but then some other packet takes a spot downstream, and it becomes blocked again. If you can construct a scenario with a plain pipe branch where one branch is hard-blocked (like shutoff/valve) and you get less than full 1 m/s flow on the other branch, then I will recant. For 2), thanks for bringing that up. I forgot to mention that you can do more than 2:1 and 1:2 merge/split.
  8. My moltens are around 110 C body temp and petro is about 120 C. I have a steel pump in their ranch, but if I wanted to live dangerously, I could make due with gold amalgam. Also, a passive cooling loop connecting to almost anywhere else would be more than enough to keep it under 125 without massive heat leakage. Even a few wheezes would probably sufficient, but I like to keep it hot because they need to be > 100 C to maximize chance of molten larva.
  9. Technically, the bridges in A and F are completely redundant, and you should get exactly the same split/merge behavior if you take them out. I was going to write a post on this topic, but since you already started one, I'll make a few comments here. The key to understand is that this behavior is not about *bridges*. It's about *sources* and *sinks*. The green outlet box is a "source", and the white inlet box is a "sink". And *all* sources and sinks exhibit this behavior, whether they are on a bridge, a shutoff, a refinery, a pump, etc. That's the point @chemie was making. More importantly, the interesting behavior does not happen when a source or sink occur in a single isolated segment. But, for completeness, I'll cover all the cases: Source, no sink: nothing happens. Packets just sit in the pipe because they don't know where to go. Very useful if you need to stop a "bad" packet from damaging some equipment. Most folks have "deconstruct" on a higher priority than "plumbing", so deleting a pipe segment will usually happen faster than clearing out the bad packet on the fly. And sometimes you need to stop the flow just to get at the bad packet. Sink, no source: same as 1. Source connected to sink on isolated pipe segment: the trivial case. Packets flow from source to sink at 1 m/s, if present. One source, two sinks: fair split. This is the A case above, but works the same with or without the bridge. Packets are switched between each sink in a "fair" alternation, regardless of flow rate. That is, even if the flow is sporadic, each packet will alternate between top and bottom, which is equivalent to the split pipe "remembering" which output it sent the last packet on, no matter how long ago. In each case, the entire packet only goes down one branch or the other. The split never divides a packet and sends half down both sides. Two sources, one sink: fair merge. This is the E/F case above, and works the same with or without the bridge. Packets are "fairly" alternated onto the sink line, conversely to 4 above. If the sources send different elements, then the packets are always forced to alternate. *However*, if they are sending the same element, then the flows can merge completely, with no blocking in any segment, as long as there is sufficient pipe capacity. For instance, if you have two pumps sending 500 g/s of O2 into a merged line, they will merge "cleanly" into a single 1000 g/s stream to the sink, with no blocking. If you have two lines sending 10 kg/s of H2O into a merged line, they will alternate, because even though both sources are H2O, the sink line can still only handle 10 kg/s. You can confirm by checking the output temps, if the inputs are different. Also, the animation shows this behavior clearly. The average flow velocity of the source lines will be 0.5 m/s. If you have two lines sending 750 g/s of H2 into a merged line, they will do a "partial merge" where one source will get to send a whole packet, and the other will get to "fill" the packet with 250 g/s, then they will swap. Every 3rd merge, both packets will merge cleanly, and the source lines will have an average flow velocity of 0.75 m/s. Pipe passes a sink: biased split. This is D above, and works exactly the same if you replace the bridge with a shut-off, valve, reservoir, etc. Packets will enter the sink if they can, and continue on the pipe if they cannot. Since the bridge is a static building, the only time its sink cannot accept a packet is if the downstream pipe is blocked. This will cause packets to overflow onto the input pipe. If a reservoir is full, it will stop accepting packets, causing overflow on the input. If a shut-off is disabled, it will stop accepting packets...you get the idea. Pipe passes a source: biased merge. This is B/C above. Packets will exit the source if they can, and block if they cannot. They can "exit the source" if the pipe section connected to the source is empty or has a partial packet of the same element. Just like pure pipe-based merges, a source can "top up" the pipe flow passing by it. Unlike pipe-based merges, the merging is *not* "fair". The pipe always gets precedence over the source. Any source can push packets through an "orphaned" pipe (one that has lost its source), but the bridge is one of the most popular sources for draining a pipe section, because it's fairly cheap to build. However, building a Carbon Skimmer works just as well. Note that nothing needs to be connected to the sink side of such buildings in order for the source side to have its "pushing" effect. Just the presence of the source is sufficient. In summary, a packet *always* needs to "see" both a source and a sink somewhere on its line to move. Now, in order to understand some funky behavior, you need to know one more rule: A packet will flow towards the nearest "available" sink. A sink is "available" if it can accept a packet. This rule is almost always the reason you see a packet "bouncing" inside a pipe. For instance, if you have a stream of reservoirs with a single input line going through their sinks, a packet will normally go into the first reservoir until it is full. Then, it will flow into the second until it is full, etc. However, if you start draining packets from the first reservoir, then a packet that has made it past the first and is on its way to the second will decide that it should turn around instead. Thus, if you want uninterrupted input flow, you need to always drain from the *last* reservoir *first* (making them a LIFO buffer, or stack). Another common scenario is where a bridge or shut-off input has an overflow bypass. Without another bridge to prevent backflow, it is possible for packets to bypass the bridge or shut-off, and then turn around and go back because the shut-off opened up or the bridge became unblocked. In most scenarios, it is possible to solve "bouncing" by forcing a flow direction with a bridge (note that a bridge is not at all magical with direction...it just takes advantage of the fact that packets can only go *into* a sink, and *out of* a source). P.S. @beowulf2010 brings up the important point that merges and splits can go 2, 3, or 4 ways. And, as he observes, a 4-way merge/split is only possible with a bridge or other building that gives access to all 4 sides of the source/sink (like a reservoir, but not a valve, unless the goal is to also bypass the valve, which is pretty useless).
  10. Pre-Space Sustainable Base

    This. I was losing my wild shine bugs to heat, so I started ranching them so they would not go extinct. I did open ranching and ended up with 40+ shine bugs, which is actually pretty annoying. But they provide a pretty stable supply of egg shells and eggs. They are not the most efficient egg shell source, but they are very, very easy to maintain, and if you keep the doors on your bristle farms open, they are free light.
  11. I believe a sweeper can pull 1 ton per sweep, which is enough to fill a loader in 1 sweep. The receptacles are pretty pathetic at only 100 kg each, but the sweeping latency means that a single sweeper can only keep up with 2 receptacles with a full line. The conveyor line is the weak link, so it really doesn't make sense to have more sweepers than you can move in/out on the conveyor.
  12. Just to be clear, Ceramic is confusing because it's description says: "Insulator", which kinda implies that it has similar properties to "Insulated X" where X is normal building minerals. But if you use it to build normal pipes, it will have very disappointing insulation behavior compared to even thermally conductive Insulated Granite/Sedimentary/Obsidian. So to get ceramic's wonderful insulating properties, you have to spend the 4x on the "Insulated" version of pipes/tiles. That is the point @bleeter6 was trying to make. I actually have no idea why anyone would spend precious ceramic on any non-insulated versions of anything (and don't tell me it's for the decor value when Granite is so plentiful).
  13. Normal ceramic is not that great an insulator, unfortunately.
  14. Bunker Door placement

    This kind of thing is what I was asking about, not just space for rockets. Thanks for the tip!
  15. Bunker Door placement

    He built right under the red zone and showed that only one layer of junk accumulated.