Add a logic latch as a default with Combinators 2.0

[ThePiachu]

TL;DR

Add a logic latch as a default logic functions with Combinators 2.0 (https://www.factorio.com/blog/post/fff-384)

What ?

It would be nice if, with Combinators 2.0, we could get a simple logic latch logic in our inserters / pumps, etc. Basically something like you'd see with Oxygen Not Included's Liquid Reservoir - https://oxygennotincluded.fandom.com/wi ... _Reservoir - activate something when a threshold hits X, and deactivate when threshold hits Y.

Why ?

A few times in my playthrough I've hit a few challenges that I'd need to use some complicated logic to solve that was automated in ONI.

First, pump automation. Since I had some problems with automating trains ( viewtopic.php?p=595711#p595711 ), I often resort to sending my trains to my oil fields to just sit there until full. While on paper that's pretty alright, UPS-wise it's probably a pretty bad decision, especially if you don't put a good pump design in place, meaning you might have 3 pumps per wagon constantly trying to squeeze a trickle of oil coming in from the fields and thus being a forever drain on your UPS. If we had a simple logic latch you could tell your pumps to only activate when you have, say, 30k fluid and deactivate when you have 1k fluid. If I tried doing it a dumb way with the current tech and set it to "activate when Oil is above 1k", I'm not solving the problem of trickling oil in, I'm just shifting it up by 1k oil.

Second, Uranium Processing (or other, modded dual ores). I had my Uranium Processing separate from Uranium Enrichment. I wanted to load both variants of my processed Uranium onto a train that had a simple logic of "wait until full". Both of them were going to the Enrichment bin that would properly handle both 235 and 238, but I had to load it onto the train first. I fired I'd put all of my 235 onto one wagon and just call that a day, but the system would get clogged with not having enough 235 to trigger the train to think it is full and leave. Even when I pre-sorted the ores and put 235 into its own bin, I'd get the same problem. The only solution would've been "if you have more than 10 stacks of U-235, enable Inserter, disable if you have less than 2 stacks and a train is not present" or something along those lines. So you'd keep a large enough buffer to fill a few stacks on a train without committing to a whole stack if you only have a handful of U235.

Thirdly, you could also automate nuclear reactors with this. Have a latch condition coming from how much a steam tank is filled to enable / disable inserters feeding the fuel in. A niche scenario in Vanilla, but could be more important in something like Warptorio or other mods where you have expensive reactor fuel (Space Exploration and its antimatter for example).

So yeah, it would be nice if we got a logic like that with the new Combinators 2.0 and didn't have to fiddle with some possibly complicated logic to get this kind of functionality with the pieces we currently have...

[Illiander42]

RS latches are a single combinator already.

[Tertius]

The 2.0 decider combinator has added functionality for combining multiple conditions.
So you add 2 conditions, one for checking the lower threshold, and the other for checking the upper threshold, and combine them with AND. Since conditions can additionally be combined with OR, complex conditions are possible that check more than 1 signal.

As output, define some "enabled" signal set to 1.

And that's your latch. And no preprocessing for any input values required, since both thresholds are checked completely independent from each other.

[SoShootMe]

The 2.0 decider combinator has added functionality for combining multiple conditions.
So you add 2 conditions, one for checking the lower threshold, and the other for checking the upper threshold, and combine them with AND. Since conditions can additionally be combined with OR, complex conditions are possible that check more than 1 signal.

As output, define some "enabled" signal set to 1.

And that's your latch. And no preprocessing for any input values required, since both thresholds are checked completely independent from each other.

I am missing how this provides the hysteresis the suggestion seems to be getting at, which I take to be essentially like https://wiki.factorio.com/Tutorial:Circ ... er_version.

[Qon]

For the why, your oil performance argument boils down to "I don't know what is bad for performance, but I want this feature so I will pretend the current way is bad for performance and I will pretend my suggestion is good for performance."

It will not convince anyone on the dev team.
To make a performance argument you need to understand the performance and understand how to achieve the behavior with combinators so that you can do a demo base showing the difference. Though anyone who knows how to do it with combinators is less likely to ask for features to achieve the requested feature without combinators.

Instead, play to your strengths. Which in this case means that weaknesses are your strengths. Just say that it is too hard for you to do with combinators as they are now and that you don't yet understand how to do it with combinators 2.0 either.

Also, for the uranium loading, it's not a good argument to say "so the only possible way to solve this is..." if you don't understand how to solve it and think this is hard. Since you don't understand the problem you are most likely wrong any time you state something like this, you would need the expertise to solve this easily to prove this is the optimal and only worthwhile solution. The issue is when an expert reads this and knows that there is simpler solutions (like only checking if u238 is full, or setting an inactivity condition or somethng), your argument falls apart.

Again, just tell us what is not working for you and what you think would help you solve your problem.

I'm not arguing against your suggestion. I don't personally need it. But as an expert, the most convincing argument was just writing that in ONI you could achieve the same goal easily and you don't know how to do it in Factorio. A wall of text of false statements just drowns out and hides the convincing arguments. Keep it simple. Good luck

[Tertius]

I am missing how this provides the hysteresis

In your example, the generator should be turned on if the accumulator charge drops below 20% and should be turned off if it's above 90%.
Hysteresis requires feedback. The condition needs to know if the output is currently on or off to apply the different thresholds.
- initially, the generator is off.
- in the off state, I want the generator to turn on and stay on if charge (A) drops below 20.
- in the on state, I want the generator to turn off and stay off if charge (A) raises above 90.

So I create this decider 2.0 configuration:
- reserve signal G for the generator: 0=inactive, 1=activate
- configure the generator control (a pump or a power switch) that it is active if G=1
- connect the accumulator charge (signal A) to decider input with red wire
- connect the decider output to decider input with green wire
- connect the decider output to generator control input with green wire
- add conditions "A < 20" AND "G=0" to the decider combinator, as well as "A < 90" AND "G=1", and combine the two condition pairs with OR. Check the corresponding input wires (red/green: R/G) for all the conditions. This combination of 4 conditions with AND/OR is possible according to the picture in fff-384.
- add output G=1 to the decider combinator and check the green/G output.

Proof for proper operation:

Initially, state is A=0, G=0.
So "A<20 AND G=0" is true within the decider combinator.
So the decider sets G := 1.
So the generator turns on.

Next tick:
A=0 and G=1 → "A<90 AND G=1" is true within the decider combinator. (that's the other condition)
So the decider sets G := 1.
So the generator turns on (stays on, since G was 1 before)

next bunch of ticks:
A slowly raises from 0 to 89 (or just stays in this range).
So A=0..89 and G=1 → As long as A is below 90, the condition stays true and G stays 1:
"A<90 AND G=1" is true within the decider combinator.
So the decider sets G := 1.
So the generator turns on (stays on, since G was 1 before)

next tick:
A raises to 90
So A=90 and G=1 → Neither "A < 20" AND "G=0" nor "A < 90" AND "G=1" is true.
So the decider sets nothing (so G := 0).
So the generator turns off.

next bunch of ticks:
A stays at 90 or above:
So A=90..100 and G=0 → neither condition is true.
So the decider sets nothing (so G := 0).
So the generator turns off (stays off, since G was 0)

next bunch of ticks:
A drops below 90 but stays above or equal 20:
So A=89..20 and G=0 → Neither condition is true.
So the decider sets nothing (so G := 0).
So the generator turns off (stays off, since G was 0)

next tick:
A drops below 20:
So A=0..19 and G=0 → "A<20 AND G=0" is true within the decider combinator. That's the first condition again.
So the decider sets G := 1.
So the generator turns on.
And the cycle starts again.

[Hares]

I am missing how this provides the hysteresis

In your example, the generator should be turned on if the accumulator charge drops below 20% and should be turned off if it's above 90%.
Hysteresis requires feedback. The condition needs to know if the output is currently on or off to apply the different thresholds.
- initially, the generator is off.
- in the off state, I want the generator to turn on and stay on if charge (A) drops below 20.
- in the on state, I want the generator to turn off and stay off if charge (A) raises above 90.


So I create this decider 2.0 configuration:
<...>

I created the following single-comb RS-latch using Decider Combinator 2.0.
One of the most-common use-cases, a signal thresholding. For example, you want to power up your boilers when your accumulators are below 20%, and shut down them as soon as accumulators reach 90%.

Inputs:

• Green: output of the accumulator; 0 <= A <= 100
• Red: loopback of the DC; 0 <= S <= 1

Outputs:

• Green: exported of the DC connected to a water pump
• Red: loopback of the DC

Conditions (any of):

• A < 20 AND S == 0
• A < 90 AND S == 1

Output:

• S = 1

Edit #1

Fixed conditions