Jump to content

Alternating pipe preference not remembered

  • Branch: Live Branch Version: Windows Pending

Liquid/gas (probably conveyor too) priorities are not remembered upon construction/deconstruction of new pipes.
To establish reliable packet counters, the best way is to have two paths for liquid or gas to take, which splits packets 50/50 between the two routes.
This allows you to put an automation signal which will activate and deactivate continuously, counting packets as it goes.

The problem is, if you construct any pipes, the packets will only flow one way, rather than a 50/50 split.
This breaks so many automation things, and it's really disappointing because it removes reliability from some of the larger automation projects.  
There might be a solution using shutoffs, but I haven't been able to make this reliable.
The only fixes I can think for this is:
construct it, then basically never construct a pipe again.
Shut off everything, construct pipes, turn everything on again.
Beg the developers to fix this problem.

I'm trying the third solution.  Please fix the problem.

Steps to Reproduce

Create a 50/50 pipe split, construct pipes while activated.  Observe pipe preferences.



User Feedback

Is setting 2 valves to 5000 Gram  not a solution?

Edited by Upload

Share this comment

Link to comment
Share on other sites

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.

Share this comment

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...