Factorio Forums

www.factorio.com
https://forums.factorio.com/

Better logic design for 'elastic' hysteresis?

https://forums.factorio.com/viewtopic.php?f=18&t=78968

Page 1 of 1

Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 3:49 pm
by SoMuchForSubtelty
Background

I am trying to come up with a light sensor which better suits my needs, it comes on early as light rises, and goes off early as light falls. However, this post is not really interested in that particular end goal.
Now at first sight it seemed like I needed some combinator logic which expressed hysteresis https://en.wikipedia.org/wiki/Hysteresis.
An idealised hysteresis loop as commonly desired in digital electronics would be a Schmidt trigger https://en.wikipedia.org/wiki/Hysteresi ... c_circuits , https://en.wikipedia.org/wiki/Schmitt_trigger.
Note that in order to move from '-M' > '+M' you need to cross the higher input threshold of '+T', and to move back from '+M' > '-M' you then need to cross the lower threshold of '-T'. - this is actually the reverse of what I needed.
I need: that in order to move from '-M' > '+M' you only need to cross the lower input threshold of '-T', and to move back from '+M' > '-M' you then only need to cross the higher threshold of '+T'. This seems to be a far more uncommon shape for a hysteresis loop both in engineering applications and in the natural physical world. However, one example of where it is expressed is in the behaviour of rubber bands as they extend and shrink as you load and unload them. The name of this shape of loop is apparently (/) Elastic hysteresis. https://en.wikipedia.org/wiki/Hysteresi ... hysteresis.
I came up with some combinatoric logic which achieves this: can anyone simplify or reduce this? (I'm sure someone can)
There is a blue print of my combinator logic below. It has input 'A' (scalar), and output 'H' (boolean 0/1). You can use the slider on the constant combinator for A. In reality it has four thresholds A<=9, A>=10, A<=40000, A>=40001.
When A<=9 the logic is latched into a rising mode (R=1). Now when A rises to A>=10 the H = 1 this produces may pass through and the circuit latches 'H=1'.
When A<=40001 the logic is reset into a falling mode (R=0). Now when A falls to A<=40000 the L = 1 this produces may pass through and the circuit is reset 'H=0'.
Note that when the logic is in rising mode (R=1) A<=40000 is ignored and cannot (yet) reset the latch, and that when the logic is in falling mode (R=0) the A>=10 cannot (yet) set the latch.

(I have a sneaking suspicion that my logic is cheating somehow but I can't quite put my finger on in. Maybe it's just that I'm thinking in 'Real' numbers while working in 'Rational/Integer' numbers?)

Code: Select all

0eNrFmEGOmzAUhu/y1mRkAyGBRaVuRrOY1WyrESLgTC2BQcZEE0UcoPdoL9aT1IY2TAIkNiWZTSKD/Zv3f37P4ANs0ooUnDIBwQFonLMSgm8HKOkbi1J1TewLAgFQQTKwgEWZaiUkpgnhizjPNpRFIudQW0BZQt4hwPWrBYQJKihp1ZrGPmRVtiFcdjjqlFmUpos0ygqpXeSlHJIzNauUWchue/m3lMryuQTP03BDvkc7KmeTXWLK44qKUN5LjuO2lJci7D39jnJRySvdxE2PxRO04qWIlANINbIi4k1EAXyBur3PSKxmKJUkVj9vnBD2MTaaQGBbx4dqmvVrLcf3wrcv2di3wW5tcB7GjPir0hlRTnWiJEpDf9Bza9+JYxbklSgqcwjFXkZQMRFueZ6FlEkNCLZRWpIxCJwk1xFYw6ycPisLbD1VPKqKR5A7k5Dj2yJ/OV38+Azl7x+/ZoYpeGXCcq3L0j3HY53c9kZR62TxuZqrl+SuGXH8GcRRj/jPCcSf5yOO0cT0xVeYOnrQll1s1Uaa1BDqwbIfli0tJGkNqHhm6N1GDN2BvGl5f5ylvL/MWN493fWxMinvnm55H1h1QwtgNWUB2LddAF9PU9+fJfUnox101zfLae9ynfb1Un49ZWe+LyuMbr4zm8M6L9Xn9mN8MeU0M8k3o+N8Ah0XITTPq9PjrIBW+nx0K+gQIbUOzF907o/o9u865ojWowVvIGNcvYzB3cf1PwN0KtoYji1NBeEjZwJX7K+U90vUmt+dDfzXlmBdM7BWm3dzWBF8ONuwYCejaKJeOQj7no2dlVfXfwAeL9zU
Can any one come up with more simplified/elegant logic, or find any cases for which my logic breaks down, and more powerful/correct logic to cope with those?

For example for a regular Shmitt Trigger type (not elastic) hysteresis loop see Xnight's circuit here: viewtopic.php?t=28899&start=50#p189322

My approach is a rather 'digital' (easier, naive) electronic's type approach , where as XKnight's is almost a 'linear' (far more difficult/clever :) ) electronics type approach.

Have fun if this type of problem is your thing! Many thanks!

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 5:25 pm
by DaveMcW
First, a note on notation. If we were using real numbers, we would use A<10, A>=10. This works perfectly with integers too, and is the preferred notation. Since integers are special, you can also use A<=9, A>=10, and it means the same thing. But it is confusing. So in my blueprint I use A<10, A>=10.

Here is my blueprint. It follows same logic as yours, but saves 2 combinators. The first because we don't need to store rising/falling permanently, it is only needed for one tick. The second because I merge two tests using an EACH operator.



elastic.jpg
elastic.jpg (39.12 KiB) Viewed 3562 times

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 6:21 pm
by SoMuchForSubtelty
DaveMcW wrote: ↑
Sat Dec 14, 2019 5:25 pm
 ...
Here is my blueprint. It follows same logic as yours, but saves 2 combinators. ...
Awesome! Thanks DaveMcW.

I suppose at some level the logic equates to the same the function demonstrates the same, but the maths is beyond me. To me it appears as only just some of the principles are the same.
The importance of outputting the input count of L escapes me (although it is important).
I can see the path difference through the operator arithmetic which is presumably where the 1 tick comes from, but I can't yet fathom how the second stage of comparators picks up on this.

I have noticed one thing which is that your design does not respond to A>=40000 -> A=0 (E.g. constant combinator off). But it's not a criticism, I don't understand why it doesn't, and mine covers it frankly by luck if you will.

I'm going to keep studying your solution, but if you want to short cut me to an understanding I certainly wouldn't complain ;) .

Thanks again.

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 7:20 pm
by DaveMcW
I thought some more, got it down to 5 combinators, and fixed the zero bug.



The trick is that we want a pattern of exactly 1, 0 in two consecutive ticks from the A < 10 condition. I convert the two results to binary using the formula 2 * H₁ + H₂, then check if it is equal to binary 10 (decimal 2).

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 8:01 pm
by SoMuchForSubtelty
DaveMcW wrote: ↑
Sat Dec 14, 2019 7:20 pm
 ... got it down to 5 combinators, and fixed the zero bug.
...
Even more awesome thanks!

That's just got to be the perfect solution. Easily maintainable too. (Still trying to understand it but I'm getting there :D )

That's got to be the optimal solution though!

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 8:01 pm
by Honktown
I've been checking out your blueprints, and one of the things I noticed, was I think these are specific kinds of elastic hysteresis behaviors (or not exactly the same), but what was designed wasn't exactly "configurable". Not sure if that matters.

The first two turn off, and stay off until a threshold reached below the initial on (looks like it anyway). The third one (5 combinators) stays on until a different threshold falling threshold then turns off, only turning back on once it has reached below a second lower threshold (which I think would be a negative curving, so to speak, since it intersects the turn-on curve..)

For a fully-functional elastic hysteresis, you'd have to design the trigger, but basically as two intervals, and only when rising past the end of the first interval do you use the upper and lower bounds from the second interval. What gets a little confusing to me is there are probably illogical states which would reduce one behavior to a simpler device, like how the "turn on during rising while a < b, but stay off until < a" isn't quite the same as a fully configurable X|Y|T behavior (whatever letters we want to use).

Edit: a^b, not a<b.

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 10:58 pm
by SoMuchForSubtelty
Hi Honktown, thanks for the feedback.
Honktown wrote: ↑
Sat Dec 14, 2019 8:01 pm
 I've been checking out your blueprints, and one of the things I noticed, was I think these are specific kinds of elastic hysteresis behaviors (or not exactly the same), but what was designed wasn't exactly "configurable". Not sure if that matters.
...
I'm not familiar with much notation. I'm not sure what you mean by 'specific' is this a technical term for such hysteresis functions? They certainly are limited or unusual compared with other 'elastic' type loops in that the output is simply true/false, I'm not sure how this could be extended. On the other hand it's similar to the aims of a Shmitt trigger. Can't say I know anything about 'eslastic' hysteresis except except what I looked up on wikipedia today and echoes of physics lessons. Concerning being configurable: this was solvable certainly in first and also most recent blue prints by substituting the values with channels for the upper and lower thresholds (and in the case of the first/my blue print changing some of the operators to leverage the difference between < and <=). I just though it was easier to illustrate by eliminating variables that were actually just terms for constants. Not sure if was easily solvable in DaveMcW's first blue print, can't say I fully grasped it.
...
The first two turn off, and stay off until a threshold reached below the initial on (looks like it anyway). ...
I think I might see what your concern is. Does it look like there is a 'kink' in each end of the loop if you will? I have wondered about that but in the end I don't think so. 2/4 of the thresholds are invisible. I think... It's really just for the rising direction of the loop 'static bound<=9<triggering bound', and in the falling direction 'static bound>=40001>triggering bound' in the falling direction of the loop. I think as DaveMcW corrected me my liberal mix of equivalent operators made things very confusing and creates the impression of a kink.... I think. If there could be a 9.5 or a 40000.5 I'd be in trouble and there would be a kink in the loop. Luckily there can't be.
...The third one (5 combinators) stays on until a different threshold falling threshold then turns off, only turning back on once it has reached below a second lower threshold (which I think would be a negative curving, so to speak, since it intersects the turn-on curve..)

For a fully-functional elastic hysteresis, you'd have to design the trigger, but basically as two intervals, and only when rising past the end of the first interval do you use the upper and lower bounds from the second interval. What gets a little confusing to me is there are probably illogical states which would reduce one behavior to a simpler device, like how the "turn on during rising while a < b, but stay off until < a" isn't quite the same as a fully configurable X|Y|T behavior (whatever letters we want to use).

Edit: a^b, not a<b.
The last seemed to me to behave the same as the others. I lack the terminology to understand 'turn on the curve' a^b , a" , X|Y|T . I'm guessing exponential curves, term prime prime, Exclusively bound functions accross a domain (to invent my own terminology). I'll have to have another look. Are you able to plug in some figures to help me understand?

Re: Better logic design for 'elastic' hysteresis?

Posted: Sat Dec 14, 2019 11:36 pm
by Honktown
SoMuchForSubtelty wrote: ↑
Sat Dec 14, 2019 10:58 pm
 Hi Honktown, thanks for the feedback.
Honktown wrote: ↑
Sat Dec 14, 2019 8:01 pm
 I've been checking out your blueprints, and one of the things I noticed, was I think these are specific kinds of elastic hysteresis behaviors (or not exactly the same), but what was designed wasn't exactly "configurable". Not sure if that matters.
...
I'm not familiar with much notation. I'm not sure what you mean by 'specific' is this a technical term for such hysteresis functions? They certainly are limited or unusual compared with other 'elastic' type loops in that the output is simply true/false, I'm not sure how this could be extended. On the other hand it's similar to the aims of a Shmitt trigger. Can't say I know anything about 'eslastic' hysteresis except except what I looked up on wikipedia today and echoes of physics lessons. Concerning being configurable: this was solvable certainly in first and also most recent blue prints by substituting the values with channels for the upper and lower thresholds (and in the case of the first/my blue print changing some of the operators to leverage the difference between < and <=). I just though it was easier to illustrate by eliminating variables that were actually just terms for constants. Not sure if was easily solvable in DaveMcW's first blue print, can't say I fully grasped it.
...
The first two turn off, and stay off until a threshold reached below the initial on (looks like it anyway). ...
I think I might see what your concern is. Does it look like there is a 'kink' in each end of the loop if you will? I have wondered about that but in the end I don't think so. 2/4 of the thresholds are invisible. I think... It's really just for the rising direction of the loop 'static bound<=9<triggering bound', and in the falling direction 'static bound>=40001>triggering bound' in the falling direction of the loop. I think as DaveMcW corrected me my liberal mix of equivalent operators made things very confusing and creates the impression of a kink.... I think. If there could be a 9.5 or a 40000.5 I'd be in trouble and there would be a kink in the loop. Luckily there can't be.
...The third one (5 combinators) stays on until a different threshold falling threshold then turns off, only turning back on once it has reached below a second lower threshold (which I think would be a negative curving, so to speak, since it intersects the turn-on curve..)

For a fully-functional elastic hysteresis, you'd have to design the trigger, but basically as two intervals, and only when rising past the end of the first interval do you use the upper and lower bounds from the second interval. What gets a little confusing to me is there are probably illogical states which would reduce one behavior to a simpler device, like how the "turn on during rising while a < b, but stay off until < a" isn't quite the same as a fully configurable X|Y|T behavior (whatever letters we want to use).

Edit: a^b, not a<b.
The last seemed to me to behave the same as the others. I lack the terminology to understand 'turn on the curve' a^b , a" , X|Y|T . I'm guessing exponential curves, term prime prime, Exclusively bound functions accross a domain (to invent my own terminology). I'll have to have another look. Are you able to plug in some figures to help me understand?
I was thinking about this a bit (I felt like it should be able to come down to fewer elements). Factorio's circuit elements aren't normal ones, so I'm having a hard time using the normal tools one might use to solve this problem.

To use a slightly more normal notation, the behavior I saw in the first two blueprints was ((A > low) AND (A < high)) AND rising. I didn't like using the slider because it didn't vary over time. I changed the upper bound to 90 and slapped an accumulator for A attached to a radar for draining, with a bunch of solar panels so I could charge/discharge the accumulator at whim with a power pole and get a better feel for how it behaved during rise an fall.

In terms of a phase, for a rise, it goes 0____| |____100, and during the fall it was entirely off, until it reached below T(low) and then rose above T(low). I didn't try disconnecting it in the middle of the cycle, which may have had different behavior: daylight has a single monotonic rise and monotonic fall. Something like power consumption wiggles around a lot (and even with accumulators, if you put a bunch of panels down when they just hit discharging, they can start charging again because solar power is just enough, but keeps falling until the accumulators discharge again).

I felt fundamentally that changed a kind of circuit we would want to use (with the two-state monotonicity during the 'transition' being simpler).

By X|Y|T, I just meant X was one 1/0 state, Y was another, and T was the truth value. I think normally they use like R|S|Y ? Either way, there were three logical elements, A > Tlow, A < Thigh, and 'rising'.

I'd question how applicable it is to come up with a digital elastic hysteresis device for one reason: a rubber band has an analog output state, length. If we use T for tension and L for length, dL as a function of T is assymetric: a decrease in the tension does not cause the same length change as an increase in the tension. For a rubber band specifically, this curves away in both directions (I think). The absolute value of change is less than Hooke's Law predicts. An increase in tension provides less length than you'd expect, and a decrease in tension decreases the length less than one would expect.

It would be complicated, but it would be convenient to have a "fully" configurable hysteresis device, even if it had only two output states: While in the low state, we have 0->Tlow->Thigh->1, and after Thigh, we switch to another interval function, because we're going from 1->Thigh->Tlow->0. If Thigh and Tlow could be configured on both sides of the rise/fall curve, we could probably exhibit more interesting behaviors. Have tlow during rise be less than tlow during fall might cause either undefined behavior (because we're in a mixed state) or an instant transition to 'on' (if between is on), because we did go from below the low threshold during fall, and are above the low threshold of the other condition - even though we aren't rising.

There's a lot of awfulness here because are we considering monotonicity or not, and is it 'complete' i.e. do we always go from 0 to 100% back down to 0. For the day cycle in Factorio, yes, but for an arbitrary problem?

Re: Better logic design for 'elastic' hysteresis?

Posted: Thu Dec 19, 2019 6:41 pm
by SoMuchForSubtelty
I know this reply is a bit late but the points above are of interest and while I can't answer them perhaps I can provide relevant comment.
Honktown wrote: ↑
Sat Dec 14, 2019 11:36 pm
 ...
I'd question how applicable it is to come up with a digital elastic hysteresis device for one reason: a rubber band has an analog output state, length. If we use T for tension and L for length, dL as a function of T is assymetric: a decrease in the tension does not cause the same length change as an increase in the tension. For a rubber band specifically, this curves away in both directions (I think). The absolute value of change is less than Hooke's Law predicts. An increase in tension provides less length than you'd expect, and a decrease in tension decreases the length less than one would expect.
...
Concerning how applicable a digital elastic hysteresis is the first problem is that I'm still not sure what a 'definition' of such a thing is, so there is hazard of having to argue the semantics. I'm assuming that its most essential feature is that the output/extension's rate of response to input/load generally diminishes for which ever direction the change is in [whereas for the most commonly considered hysteresis it generally increases with that direction of change]. In our case the output being boolean, the concept of rate doesn't seem very useful though; the one change either happens early or late.
Assuming the above though, I include an application of DaveMcW's logic with the blue print below. I had been intending to use accumulators but balancing the load and supply in addition to the invisible sink that the accumulator's priority creates was never satisfying. In the end the behaviour of a fluid pressure potentials, pumps, pipe capacities, and tanks is more recognisable... so I used that - not an original use I know (it does seem incongruous that accumulator function is so sophisticated while you can't even determine from a solar panel it's available power). I was curious to see how flow rate might be used, so there is a rate meter but it's of no use, I kept it out of curiosity but all that is needed is whether there is flow and its direction (not the magnitude). There is logic to determine the difference (P) between the two tanks at any moment. The present difference is passed to a memory cell only when the rate 'first' turns to negative (flowing back into the resting tank), this defines the maximum difference X that is reached (happens to be an equilibrium) during daylight before (actually as) the power to pumps 'first' diminishes. So the the blue print needs one night day cycle to be useful. DaveMcW's logic is then used to close a switch when the power to the pumps achieves a difference P in the tank greater than U percentage of X, it opens the switch when the power to the pumps fails to keep the difference P above D percent of X. U and D set in the constant combinator. (There is also some logic to first prime the tanks to an adequate level. The pumps are kept in the red even during maximum daylight by the load from two radars)
As it happens the game delivers such a consistent behaviour and the lack of slosh between the tanks means that for my purposes I could just use a regular latch to set on the rise and reset on the first fall. However with DaveMcW's logic you can pick any two points in P to act on as the as it rises or falls, U < D, U > D, U = D. I do note however that this only works in practice because because there is no weather. There amount of daylight at a given time of day involves no other variables; the amount of power delivered by the panel will always have achieved the same difference in the tanks by that point.

thumbnail preview of blue print
thumbnail preview of blue print
bpthumb.jpg (118.95 KiB) Viewed 3370 times
...
It would be complicated, but it would be convenient to have a "fully" configurable hysteresis device, even if it had only two output states: While in the low state, we have 0->Tlow->Thigh->1, and after Thigh, we switch to another interval function, because we're going from 1->Thigh->Tlow->0. If Thigh and Tlow could be configured on both sides of the rise/fall curve, we could probably exhibit more interesting behaviors. Have tlow during rise be less than tlow during fall might cause either undefined behavior (because we're in a mixed state) or an instant transition to 'on' (if between is on), because we did go from below the low threshold during fall, and are above the low threshold of the other condition - even though we aren't rising.

There's a lot of awfulness here because are we considering monotonicity or not, and is it 'complete' i.e. do we always go from 0 to 100% back down to 0. For the day cycle in Factorio, yes, but for an arbitrary problem?
I had to look up monotonicity. I don't fully appreciate the type of completeness you are referring to, I am aware of several and none are the type you are talking about, I could not easily find a clear match by looking it up either - I can imagine more than one way of not meeting the requirements you describe.

If one was interested in some logic which enables one to respond to a change from loading to unloading at any arbitrary point, perhaps my existing logic which stores a limit X on the turning point V+ > V-, might begin to hint at one way of doing this.

Re: Better logic design for 'elastic' hysteresis?

Posted: Thu Dec 19, 2019 7:41 pm
by Honktown
SoMuchForSubtelty wrote: ↑
Thu Dec 19, 2019 6:41 pm
 I had to look up monotonicity. I don't fully appreciate the type of completeness you are referring to, I am aware of several and none are the type you are talking about, I could not easily find a clear match by looking it up either - I can imagine more than one way of not meeting the requirements you describe.

If one was interested in some logic which enables one to respond to a change from loading to unloading at any arbitrary point, perhaps my existing logic which stores a limit X on the turning point V+ > V-, might begin to hint at one way of doing this.
Accumulator charge can rise and fall at any point during a solar cycle (it doesn't just have to slow down to not discharging/charging). A solar cycle on the other hand goes from minimum, to maximum, back to minimum. We can use different circuits. I didn't say it explicitly, but I assumed you were looking at a circuit where the measurement (such as daylight) went from 0->100%->0% guaranteed every cycle (as long as it can cycle, har har). If it did, we can use a condition of "rising" and "falling" because those can be determined once and the state kept until we reach the opposite extreme.

If they can rise and fall randomly, we can't really call it "rising" and "falling", so a hysteresis device which has "two" intervals for rising/falling wouldn't apply. I say "two" in quotations because logically, we could use that on the first state, the thresholds are base_value +/- a constant, and in the second state, same thing. I.e. if we want the logic outputs to be "delayed" in both directions, we can do threshold + offsets (say 15 to 25 for high, 85 to 95 for switching internal state and low) and then on the "fall" do -10, so it'd become active at 85 - 10 = 75, and change output and switch back to "rise" at 15 - 10 = 5.

For randomly rising/falling, we have to use a latching rise/fall, vs a rise/fall switch that happens at a known signal level. I don't know if I'm being clear or not.

Too many variables for me to decide anything.

I was thinking about a mod that could turn tank fluid capacity into an energy value readable by the circuit network (steam * temperature_conversion = energy), and harder, if it could further be shown on the power screen like an accumulator (assuming all the energy is extracted). Performance would be abysmal every tick, so some compromises would have to be made, even if everything along the way were possible. Would you be interested in such a thing?

Re: Better logic design for 'elastic' hysteresis?

Posted: Fri Dec 20, 2019 5:27 pm
by SoMuchForSubtelty
Honktown wrote: ↑
Thu Dec 19, 2019 7:41 pm
 ... looking at a circuit where the measurement (such as daylight) went from 0->100%->0% guaranteed every cycle (as long as it can cycle, har har). If it did, we can use a condition of "rising" and "falling" because those can be determined once and the state kept until we reach the opposite extreme.
...
The shape of some cycle - being guaranteed - was always going to be the case for my exercise. Although to me this seems more of a moot point. It seems to me to be a question of definition; i.e. how many unknowns or variables your definition includes, and whether your logic honours/operates-over those variables. Take my most recent blue print, it included some logic to cope with a cycle that might vary interns of its +ve > -ve turning point. X is defined at (approximately) the point that the +'ve change becomes -'ve > the change of output then occurs some fixed D % under that X relative to 0. (The reason I chose to cope with this variance though was more because it seemed easier than having to prime the closed fluid system consistently, and then tune accordingly (and have to retune if ever I decided I wanted some marginally different thresholds). This could probably be extended easily enough to cope with varying +ve although the behaviour is now looking a bit like elastic behaviour which to 'stretch the analogy' :lol: :roll: would be for some medium which has been loaded beyond it's elastic limit. But in our world of a boolean output, this is just a somewhat self indulgent exercise.
...
I was thinking about a mod that could turn tank fluid capacity into an energy value readable by the circuit network (steam * temperature_conversion = energy), and harder, if it could further be shown on the power screen like an accumulator (assuming all the energy is extracted). Performance would be abysmal every tick, so some compromises would have to be made, even if everything along the way were possible. Would you be interested in such a thing?
Personally I have a mostly irrational aversion to mods. In the case of this game I haven't even launched my first rocket yet! And as it's in large part a problem solving game, adding mods to solve the problems rather than solving them within the rules of the game would for me defeat the purpose of playing the game in the first place.
My first thoughts are though that unless temperature_conversion varied for some reason you could get much of whatever you needed to 'act' on, from just the steam volume/pressure (which I understand are implemented interchangeably in factorio). A more abstractly useful mod that sounds to me to deliver the same additional benefits as the mod you suggest, would be a mod introduces a new placeable called a 'logger'. The meter is peaceable perhaps with a pipe as its prototype. This pipe will then plot its contained volume/pressure in the power screen as you suggest. (Why not introduce metered storage chests as well while at it.) I almost be surprised if someone hasn't already implemented this though. These would probably be subjects now to be linked to under a whole separate task thread under a different forum heading.

For now though I'm still enjoying vanilla's challenges!

Re: Better logic design for 'elastic' hysteresis?

Posted: Fri Dec 20, 2019 5:32 pm
by Honktown
Hope you're having fun! I didn't notice you joined "recently". I only started playing some months ago, and after the first ~400 hours for two games... the things I wanted from the game changed. I never got into the circuits much, wish I were more helpful.

Re: Better logic design for 'elastic' hysteresis?

Posted: Fri Dec 20, 2019 5:38 pm
by SoMuchForSubtelty
I'm having loads of fun thanks. You've been very helpful. Not sure I would have engaged with catering for a varying turning point if it hadn't been for your discussion. I've also learnt some more or had my knowledge refreshed looking up some of the terms you've covered. I've had fun!
All times are UTC
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited