Factorio Forums

eugenekay wrote: Tue Apr 08, 2025 10:24 pm These circuits make Barrels seem like a sane alternative for Fluid Handling.

this is (mostly) a joke. I like modded fluids too

That's mostly overcomplication

here is """"my""""" solution :
Copy blueprint

GluAp wrote: Tue Apr 08, 2025 10:02 pm

Simplifying a bit, I read the instructions as:
$1 := max(in_r1, in_r2)
out_1 := signal in_g1 value $1 if $1 < in_r3 else signal R value in_r3

I would like to have a single (decider) combinator

Impossible. While a decider combinator can evaluate arbitrary logic, it'll either produce all it's configured outputs if the condition is true, or none if the condition is false.
If in_r3 is not supposed to be a fixed signal ('C' in the example), it must be on a different wire then in_r1 and in_r2; otherwise, how are you going to figure out which input signal takes the role of in_r3?

# Tick 1: Rename in_r3 to C and find the larger of in_r1, in_r2
A1.1: Each + 0 -> C; input: in_r3 on either wire; this combinator can be removed if in_r3 is always C
S1.2: Select input 0 descending; input: in_r1, in_r2 on either wire
# Tick 2: Are we limited by C?
D2.1: Everything[red] <= C[green] -> Anything[red] input count; input: S1.2 on red, A1.1 on green
D2.2: Anything[red] > C[green] -> C[green] input count; input: S1.2 on red, A1.1 on green
# Tick 3: Rename output to fixed signal, force in_g3 to value 1
A3.1: Each + 0 -> S; input: D2.1 on either wire
A3.2: C + 0 -> C; input: D2.2 on either wire; artificial delay to keep things in sync
D3.3: Each != 0 -> Anything value 1; input: in_g1 on either wire
# Tick 4: Rename outputs to actually desired signals
A4.1: S[red] * Each[green] -> Each; input: A3.1 on red, D3.3 on green
A4.2: C + 0 -> R; input: A3.2 on either wire
# Final output: merge A4.1 and A4.2

That's 9 combinators and 4 ticks, the renaming to in_g1 costing more than half. I'd explore whether the outputs of D2.1 and D2.2 can be used as is, without renaming.

Nidan wrote: Tue Apr 08, 2025 8:09 pm When you have something that map signals '1', '2' and '3' to 'X', then converting that 'X' to 'Y' (or 'Z' or 'iron-plate' or …) can be done by adding a single arithmetic combinator, configured as 'X'[green] * Each[red] -> Each. 'Y' (or 'Z' or 'iron-plate' or …) is the signal that would come in on the red wire, with value 1.

Yes and No. Yes - you can expect 'X' and convert it to 'Y'. But you would have to know that you're expecting 'X' and code it as a static case. But I don't know if the green wire input will be 'Y', or 'Z', or 'iron-plate'. But I do know I'd like the output to be 'copper-plate' nonetheless. So it has to map any input value from red wire signals to the signal type of the green wire and we don't care about what the green wire actually signal is.

I know to expect X because I set up the previous combinators to output the result on X (that's the role of A3.1). Moving the value back to a different dynamic signal can then easily be accomplished by the powers of Each (A4.1).

Copy blueprint

mmmPI wrote: Tue Apr 08, 2025 10:21 pm

GluAp wrote: Tue Apr 08, 2025 10:02 pm Honestly - I don't know what this does.... I guess this could be a feedback loop. My programming days are long gone and I hope you can follow my notation.

I am not sure i can follow the notation, but i wanted to be sure i didn't make a mistake, because i realize it's not exactly working as a schmitt trigger, which aims at controlling that the input signals reaches the "upper bound" before flopping. I may have spoken too soon when "confirming". When i tried again the posted blueprint, i realize it wouldn't work when the value reaches the upper bound when you set it to the quantity of the fluid tank, but if you need to set it above then the blueprint just picks the maximum signal even if it's not at the specified limit. It look a lot like a schmitt trigger but isn't one.

Well .. the example with my 'special' notation has no connection with the thread opener nor the circuit I posted. It just decribed something I was wishing to be be implemented/added as it is (imo) not doable with circuits.

As far as I would say, it behaves as a Schmitt Trigger with a variable upper bound? So yes - it does not care how big the input signal is but picks the max(input), as far it surpasses the lower threshold value. If you replace the selector combinator with a decider that filters for signals above a upper bound, it should work like a Schmitt Trigger. But atm I'm a little bit lazy to test it .

Note:

The "upper limit input value" has to be higher than the highest input value that is expected to be used with the circuit. Contrary to it's naming it does not behave as the upper bound you'd find in a Schmitt Trigger. I'm not good with words I guess

So when using vanilla tanks and connecting 1 Tank to green wire, it should be bigger than 25.000. But you could make it 25.000.000 as long as there is no integer overflow when doubling that number.
When connecting 4 tanks it should be >100.000.

Then i tried to understand how the posted blueprint could serve the mentionned purpose in the OP , the usecase, but i don't think it can.

The wiring (i think plz correct me this is hypothesis) should account for 2 differents sets of inputs i thought, 1) for the fluid that could serve as fuel to know their quantity and 2) the quantity of fluid in the buffer tank, to know when to switch.

As such i am not sure i understand the usecase of the machine

Sorry, I don't understand what your idea with the two input sets is supposed to be. On the green wire are the CURRENT buffer/tank values. The red wire will only have 1 of those input signals and works as a filter. It carries the real value with a little offset regarding circuit delay.

Is this what you're missing?

Well - here is a possible use case (may not strictly be very useful for vanilla fluids^^)

You have 3 buffers with different levels of differnt fluid types. Those are on the green wire. Because Light Oil is the maximum, the circuit has choosen Light Oil and so it is on the red wire. The three buffers a connected to a 4th buffer in the middle via pumps. Those pumps are enabled but have a filter set which is set via red wire. You can see, that all pumps are filtered for Light Oil. This of cause means, only 1 pump will ever work here.


As you can see the Light Oil level has dropped beneath the other fluids. But because it is still higher than the lower treshold (I think I set it to 2.000) it is locking in Light Oil.




Now Light Oil has fallen below the threshold. And I notice that by circuit delay that threshold is overshot quiet a bit. For my usecase this does not matter much.
As you can see, there is no filter set for the pumps. And there is still Light Oil inside the buffer tank in the middle.




Now the next highest fluid - Heavy Oil - is selected and the filter is set. And the process repeats.




Here comes Petroleum ...




Now let's look at the behaviour in more detail. Let's assume that while Petroleum being pumped to the 4the tank but not beeing used, Light Oil and Heavy Oil have filled to the max. The circuit will still hold Petroleum until it reaches the lower threshold. And that's the point where I realized that it wouldn't be useful for me in the context I was using it for.




Let's have a look at another state: let's say Petroleum has emptied, but Heavy Oil and Light Oil are low, too. But still over the threshold.
Now the circuit will choose Heavy Oil next, even while it only reaches around 2.7k. And that's the point where it does not work like the classical Schmitt Trigger.
I'm not too happy about this. But as I said - just exchange the selector combinator with a decider with a signal filter for some upper threshold you would like to use.




If you want to save on two ticks circuit delay you can remove the 2 arithmetic combinators and the end. The red wire will now give you the signal type that is used for filtering the pumps. Here it really does not matter what the value is set to. Btw - this value is the term (upper input limit value - buffer tank value).



I really hope this showcases what the circuit will and can do. I would use it for fluids only atm.

I guess it's usefulness is limited, especially in vanilla. For Pyanodons it works well, because you have plenty of different fluids and several tank sizes with some of them with up to 8 connections.
You can place it down and circuit size and complexity don't increase with the amount of fluids you want to handle. It doesn't care what kind of fluid you use so there's no need to adjust values/types when placing it down.

This circuit is to be used when you have high buffer size and need/want comparativly less switching. Provided you achieve enough fill rate for you buffers and you can work with emptying out you fluids in a selective but uneven matter.

If you care for even fluid usage you may want to use a clocked setup. This may come with throughput limitations or a switching rate that's not high or low enough.

@Nidan

I have to read (understand) and reply to your message tomorrow. As my brain seems to fried for today

GluAp wrote: Wed Apr 09, 2025 1:14 am Well .. the example with my 'special' notation has no connection with the thread opener nor the circuit I posted. It just decribed something I was wishing to be be implemented/added as it is (imo) not doable with circuits.

Ok I will focus on the other thing for now then x).

GluAp wrote: Wed Apr 09, 2025 1:14 am As far as I would say, it behaves as a Schmitt Trigger with a variable upper bound?
The "upper limit input value" has to be higher than the highest input value that is expected to be used with the circuit. Contrary to it's naming it does not behave as the upper bound you'd find in a Schmitt Trigger. I'm not good with words I guess

The problem i have with using this name for the contraption is that as far as i can tell it doesn't prevent hysteresis. Since you have a variable upper bound, it can happen that it is temporarily the same as the lower bound or very close in case of low fluid. Say you have a low at 5K ; then if your fluids are in quantity 5001 5001 and 5002, it will switch rapidly from one to another.

GluAp wrote: Wed Apr 09, 2025 1:14 am
And that's the point where I realized that it wouldn't be useful for me in the context I was using it for.

GluAp wrote: Wed Apr 09, 2025 1:14 am For Pyanodons it works well, because you have plenty of different fluids and several tank sizes with some of them with up to 8 connections.
You can place it down and circuit size and complexity don't increase with the amount of fluids you want to handle.

This is troubling me because i'm trying to understand the blueprint in relation with the usecase, and i'm not sure does it work ? do you have OK answer in your gameplay help request ? or not ? x).

Because from the first of the 2 quote, i think you meant that if another tank reaches 25K (light oil in your example) while petroleum is still consumed/present in the buffer tank, it will stop the production of petroleum which has light oil as byproduct, where switching to consuming light oil as fuel, "because it has reached the upper limit" would have been more efficient in terms of keeping the factory producing the useful ressource / burning the lesser useful ?

from the second quote i think maybe it works perfect for you because you are not in a situation where all 3 fluid could be low, and if it would switch super fast, it wouldn't be a problem because it would mean you have no power and still prefer be in "orange" rather than brown-out or black out for a bit because pumps wouldn't restart.

Considering the "real setup with fluid and pipes and tanks" rather than just the combinators is also what prompted my reflexion about "don't you need 2 sets of inputs ?" ( for the original logical/logistical problem ) to be solved ? In that i thought given the description of the pyanodons situation, to handle the case mentionned it may be useful to monitor both the reserve of fluid as you already use as input on the green wire, but also the buffer tank as a second input, it can provide useful information to time the reset of the memory when empty.

mmmPI wrote: Wed Apr 09, 2025 1:44 am The problem i have with using this name for the contraption is that as far as i can tell it doesn't prevent hysteresis. Since you have a variable upper bound, it can happen that it is temporarily the same as the lower bound or very close in case of low fluid. Say you have a low at 5K ; then if your fluids are in quantity 5001 5001 and 5002, it will switch rapidly from one to another.

Maybe?

First: It get your point. But in my proposed use case it 'should' not come to this in practice?


Let's assume f (for Fluid) .. f1 = 5000, f2 = 5001, f3 = 5003. The buffer tank that connects to all the pumps is set to empty.

The circuit should choose f3. It takes several ticks until the filter is applied. Then the Pump will activate. And as I have shown, it will overshoot because of circuit delay. Pumping from 5k into empty tank should remove at least 300-500 units of fluid in a few ticks until circuit resets.

If there was no new input for the fluids, the circuit will choose f2, empty it below 5k and do the same with f1. Without new input all the signals will stay below the threshold.

So now assume every fluid get a little trickle every tick. As I said before there is circuit delay. Further more - if you pump a 100 units of fluid from a basic tank into empty pipe, for me it takes quiet some ticks. Maybe even over a second. And during that time, even if a new fluid is selected those pumps won't work, because the tank is still not empty.

So yes - there might be a certain constellation where it will could switch about 4-5 times a second. This will probably happen more easily if your lower threshold is very low - which in itself is not necessary. But with the pump situation it will should be less than once a second. And to be honest - why would you care for that in a practical sense. In this situation you're using more than you produce and everything will be limited by this anyway. It might be the same or worse when using 3 pumps without any circuits since two fluids might block each other and limit throughput while the 3rd fluid runs full.

I would love to see a setup with reasonable lower threshold that switches rapidly. I can't imagine it right now. But it's mostly gut feeling.
I would assume that this would be very specific and even hard to contruct such a case.

EDIT:

I was so intrigued that I ran some simple tests. The Circuit switched about 8-12 times a minute max. That's once every 5 to 7.5 seconds on average.
I encountered per-3-tick flickering two times. Once because I manually changed a number and forgot that two numbers had to be changed
And the second time I really don't understand. I think because somehow a value got stuck on the circuit. But it had nothing to do with the value of the inputs beeing what they are.

That's a bug. I have no clear idea why it happend nor how to fix this.

It might happen, because I use a condition if (EVERYTHING < 0) out := S=1.
But as I was annoyed some posts ago that there is no "not" function in the combinator logic, I'm now again frustrated. Because if with "Everything" there is no input signal it will evaluate to true. Which in my case is just not the same (and for me doesn't follow logic). If I had "not" I could change it to the inverse.

Now I changed it to
if (EVERYTHING < 0) AND (ANYTHING != 0) out := S=1

That seems to make sense and work. Unfortunately it's not the only problem as it happend again. ATM my best guess is that if the selector combinator wants to change it's signal to a new one because the old one is not the max any more but during the next tick it becomes the max again, my circuit breaks. I could watch it once.
If it begins flickering it can be resolved by cutting the connection of the input signals from the circuit. So the cycling does not happen in the circuit anymore. So that's a win.

I have to have a look on it. Later. I'm done for today.

EDIT2:

It seems to me I had the lower threshold set not high enough. I can't explain but since I upped it to 2k it hasn't reached a failed state whereas before it happend after 3 or 4 fluid type changes.

GluAp wrote: Wed Apr 09, 2025 3:58 am First: It get your point. But in my proposed use case it 'should' not come to this in practice?

I have to have a look on it. Later. I'm done for today.

First, no need to rush, take your time no stress answer whenever you want , or not if you have other priority, it's a game x) !

I get that it can work in practice with fluid a bit better than in theory, i understood your explanation on circuits delay, i think, and if pipes adds a little buffer or something that can reduce the flickering frequency in case of low fluid which is never supposed to happen in the first place anyway, or since the machine can't produce a satisfying output in those cases : if you lack any excess fluid fuel, the machine is correct saying a different one as soon as a tiny excess builds up, it's all good for the usecase.

The 2 combinators build i posted doesn't do the same thing as your build, its logic is simpler, it guarantees that a fluid would be fully consumed from the upper threshold to the lower threshold before changing to the following fluid. It's a trigger Schmitt, i updated to 2.0 an older version someone else made so it could use an arbitrary amount of fluid input. It wouldn't serve well the purpose that you need for the pyanodon use case because if 0 fluid is at the max threshold when the current fuel dries up, it would select no following fuel, just wait for one to reach 25K, and meanwhile power would die. But it works like the wikipedia description of 1 trigger Schmitt. That's what i wanted to clarify regarding the naming.

This is how i thought to attach your blueprint to tanks for a usecase :

Copy blueprint

It's a little different than in your pictures, i'm not sure sure how strongly adding pipes impact throughput and adds delay to drain the remaining fluids, i thought if you wanted to scale to "any" number of fluid some bus would be required but now i need to test again without to make sure x)

The easiest 'naive' solution would be to just have every pump connected to their own tank, and active if their own fluid is above 5000. And them "battle it out" x).

Copy blueprint

mmmPI wrote: Wed Apr 09, 2025 5:58 am The 2 combinators build i posted doesn't do the same thing as your build, its logic is simpler, it guarantees that a fluid would be fully consumed from the upper threshold to the lower threshold before changing to the following fluid. It's a trigger Schmitt, i updated to 2.0 an older version someone else made so it could use an arbitrary amount of fluid input. It wouldn't serve well the purpose that you need for the pyanodon use case because if 0 fluid is at the max threshold when the current fuel dries up, it would select no following fuel, just wait for one to reach 25K, and meanwhile power would die. But it works like the wikipedia description of 1 trigger Schmitt. That's what i wanted to clarify regarding the naming.

Hello. Good to make your acquaintance. You can call me Schmitt. Trigger, Schmitt.

This is how i thought to attach your blueprint to tanks for a usecase :

It's a little different than in your pictures, i'm not sure sure how strongly adding pipes impact throughput and adds delay to drain the remaining fluids, i thought if you wanted to scale to "any" number of fluid some bus would be required but now i need to test again without to make sure x)

Actually that works with practically the same limitations as my setup. I believe you can neglect the influence of the pipes as long there aren't tooo many, as the delay comes mainly from emptying the tank at the end. I didn't think about scalability, YET, because it was only a proof of concept for me.
So thank you for doing this instead.

Strictly speaking - there is no need for the tank(s) at the end/out side to be bigger than the max input tank.

EDIT: Well .. that's not true...

As I just tried your proposition to only filter each pump on it's own I found out that the pumping speed (py uses the old 12k/s) from one Pump into a single tank is only 6k/s. But if I connect a second tank to the first one it will be 12k/s.

That's a little bit weird...

The easiest 'naive' solution would be to just have every pump connected to their own tank, and active if their own fluid is above 5000. And them "battle it out" x).

No. There would have to be at least some kind of hysteresis. Otherwise you get the problem I mentioned before: As the currently used fluid is trickeling in it will block throughput for all the other pipes.

But I have a another 'great' idea how to improve it. One the shared pipe you could connect another pump that will be pumping into another tank. So this would make a N->2 mixer. This could be quiet useful for Py. My first thought is to make the two output pumps have a filter set that are exclusive to each other.
But this will fail, if one output is empty but the other one is full and the shared pipe still has that last fluid type.

Maybe this can be done with some circuits... But I'm not sure if I want to spend time on this
Addendum:

Maybe something like this? A manifold.
I know Boldviking used a fluid train setup similar to this, but I think he didn't use a combinator hysteresis.
Built like my example here the setup would prefer the left end input. You could even give every fluid a increasing negative offset - increasing from right to left. This would have the effect that your most produced fluid on the left would switch on more often than every other fluid to the right. It has the most usable manifold-tank storage of all the fluids so it will empty out fast and with certainty. So while the leftmost fluid is used, the other fluids to the right have more storage to fill up and will now be next in line. They will block less of the manifold, so they won't block throughput for as long. They will be triggered less often, too.

GluAp wrote: Wed Apr 09, 2025 1:08 pm

me wrote: The easiest 'naive' solution would be to just have every pump connected to their own tank, and active if their own fluid is above 5000. And them "battle it out" x).

No. There would have to be at least some kind of hysteresis. Otherwise you get the problem I mentioned before: As the currently used fluid is trickeling in it will block throughput for all the other pipes.

yes correct sorry, the pipes are drained too slowly it doesn't switch fluid when there is a trickle , in my tests that was pet gas running dry due to light oil backing up so no more prod, no trickle and no problems. It was lucky but can't be made to work all the time.

GluAp wrote: Wed Apr 09, 2025 1:08 pm Maybe something like this? A manifold.

That reminded me of a (now-broken) other machine from this thread 113114 but at this point we can call it "fluid sushi" or something. It is not only the logic part to associate an output to different situation that can occur. " select a fluid with combinator", It is also the logisitic/routing part of the fluid to the consumer, the left-over and fluid mixing problem.

I think both should be considered together, but it doesn't narrow the problem.

I think starting with the situation in game with more details would make it easier to define what kind of machine and logic could serve the purpose a simple minimalist setup with say 3 fluids, and the consumer, on a save game, with the goal stated would help re-narrow thing down a little x).

Currently, I am using the idea from a design from the discord

Each fluid fills a tank and an sr latch opens the pump at 25k and closes below 1k. Ensures it floods the system whenever a fluid caps out, but shuts when little is left.

Aside from no prioritization between fluid types it seems to work. So I still need improvements.

Ranakastrasz wrote: Thu Apr 10, 2025 4:07 pm Currently, I am using the idea from a design from the discord

Each fluid fills a tank and an sr latch opens the pump at 25k and closes below 1k. Ensures it floods the system whenever a fluid caps out, but shuts when little is left.

Aside from no prioritization between fluid types it seems to work. So I still need improvements.

That's like what my 2 combinator setup is doing ? the risk with this for the proposed used case is that if no fluid is at 25K when one run below 1K, say they are at 23K and 24K the others, then nothing happens and power dies right ?

Yep. That is the other problem.
But, well, if that happens in the first place, you aren't producing enough fuel of any type, so no matter what you do, power will run out regardless.

I 'think' you are correct, i'm not 100% sure, i think it could happen a situation where "no fuel" is consumed, and suddenly 2 fluid at the same time reach 25K threshold and are available, which could have been avoided if one had been consumed before. I am not sure that is possible to happen several time in a row without also meaning a lack of fluid, not "caused" by some fluid backing up, or if it risk creating sustained innefficencies.

I have tried with no sucess to make a smaller footprint for the logic in OP. I like it now because i think in case of low fluid it is reacting 'better', less predictable maybe but it "tries its best to provide what it has", for fuel.

Tried to finish the thing Shulmeister sent me but ended up making a memory cell that kept track of the most abundant fluid and changed dynamicaly when the most abundant fluid changed, which was the point i realized it was just like using a selector combinator and no memory at all.

mmmPI wrote: Tue Apr 08, 2025 10:28 pm """"my"""""

You could have used the other one just underneath in the thread I sent you, it is a single combinator.

mmmPI wrote: Fri Apr 11, 2025 9:03 pm Tried to finish the thing Shulmeister sent me but ended up making a memory cell that kept track of the most abundant fluid and changed dynamicaly when the most abundant fluid changed, which was the point i realized it was just like using a selector combinator and no memory at all.

Blame me ?

mmmPI wrote: Fri Apr 11, 2025 9:03 pm I 'think' you are correct, i'm not 100% sure, i think it could happen a situation where "no fuel" is consumed, and suddenly 2 fluid at the same time reach 25K threshold and are available, which could have been avoided if one had been consumed before. I am not sure that is possible to happen several time in a row without also meaning a lack of fluid, not "caused" by some fluid backing up, or if it risk creating sustained innefficencies.

I have tried with no sucess to make a smaller footprint for the logic in OP. I like it now because i think in case of low fluid it is reacting 'better', less predictable maybe but it "tries its best to provide what it has", for fuel.

Tried to finish the thing Shulmeister sent me but ended up making a memory cell that kept track of the most abundant fluid and changed dynamicaly when the most abundant fluid changed, which was the point i realized it was just like using a selector combinator and no memory at all.

Maybe. But I think it is both very unlikely, and unimportant anyway. Just means one will drain, and as soon as it closes, the other one will run, since it is already open.
No real prioritization though. But in my game, it has only broken on account of my running out of fluid fuels, or my incorrectly thinking it was the dedicated syngas line and then wondering why my mines were broken lol.