Alternating pipe preference not remembered

Is setting 2 valves to 5000 Gram  not a solution?

Edited March 7, 2022 by Upload

On 3/8/2022 at 1:36 AM, Upload said:

Is setting 2 valves to 5000 Gram  not a ?

Not if you're using packets to alternate an automation signal. The new liquid meter valve offers a bit of an alternative in some cases, but won't work for all, especially if you have packets of varying sizes or temperatures.  It's like binary, you want to obtain a signal of "01010101", a packet is 1, an empty pipe is 0.  Using a valve will give two "1111111" signals.
Creating a 01010101 signal by placing a bridge across pipe also screws up once pipe is constructed as well.

It may not be required for everyone to get from point A to point B, but those who want to build cool things would surely appreciate some consistency. 
I don't think it'd be too hard to implement code-wise.  You'd really just need a collection of junctions which can be used to reference the priority, then refer to that upon a rebuilt pipe network.  As long as the flow of a junction isn't modified, the priority should be retained.
compare junction priorities of the old pipe network with the new pipe network, if the junction still exists, set the priority.

A long time ago before the DLC, I created a packet counter that would accurately fuel rockets with exactly the right amount of liquid hydrogen and oxygen.  I tested it multiple times, and it worked perfectly using the alternating pipe method to count packets.  Sometimes, it'd screw up and I'd have to go and fix everything which was a real headache.  I couldn't figure out why it kept screwing up for the longest time.  
This was before I knew this issue even existed.  I had to figure out "Why does this sometimes fail?"

This was the reason.  
Imagine the frustration of having something not work seemingly at random, but it works every time you observe it.
That was me.  Until this is fixed, people are probably going to experience the same thing.  "Why doesn't this work some of the time? What am I doing wrong?"


There are many things I'd love to build.  I've always wanted a junction based cooling loop that can cool areas to different temperatures using pipe priority junctions.  Currently, it's impossible to get consistent results unless you plan to build it, and then never construct a pipe again.
It sure would save on insulation material for the insulated pipe.  You can do this with filters if your cooling liquids are different, but if you're using super coolant, that's probably not going to be the case.
Pipe thermo sensors with shutoffs can somewhat work, but it's ugly, takes up space, requires power, has to be manually calibrated any time an aquatuner output is adjusted, as well, at the end of the loop, you'd have no way of recombining the liquids onto a single pipe and have them split back to their rightful destinations, which would congest the pipes and break everything, or if you use valves, you'd mix your liquids together and put a lot of burden on the aquatuners.
This would also fail if you have too much temperature variation, require too much precision, and would pretty much fail on the first packet every single time.
Only a junction makes this viable, and only if junction priorities are fixed.  I hope that states my case as to why I believe this is an important implementation.


Consistency should be a priority, even before performance, not that I feel a fix for this would impact performance in a noticeable way.
I can't think of any negative consequences to having priority persistence.  Can you?
Maybe a bit more ram in terms of holding one more collection?
Maybe an additional millisecond to iterate an additional collection on pipe construction?
Those are the only downsides I can think of, but they are far outweighed.

This problem still exists... am I... am I allowed to bump this?