[1.0.11] integrate SR latch with counters \ sensors - built-in range \ hysteresis option
Please add resource threshold range logic
I think this is the most useful logic for resource counter. On when below some threshold. But keep it on even over lower threshold, Then off only when over another threshold. Such as when we want to let beaver pumping water when water low. But keep pumping until full then rest
Without this resource counter then just switch on/off constantly and it inefficient
Even this logic can be created from 2 resource counter and 1 memory logic block, it just too useful that it need to be repeated to all resources for control production building. So please have this logic in resource counter itself
Can be another version, advance resource counter. Or unlock option with science
mod edit: title from "Resource counter range option" to "[1.0.11] integrate SR latch with resource counter"
Comments: 21
Oldest
•
Newest
•
Most likes
•
Fewest likes
-
15 Mar
Jcheung SystemHighlighted comment
"Resource counter use range instead of >, <, =, !=" (suggested by <Hidden> on 2026-03-15), including upvotes (1) and comments (0), was merged into this suggestion. -
04 Mar
Codemaster256 MergedAllow separate on/off conditions for resource counters, e.g. turn on when a resource is below 75%, turn on when it’s above 90% (a bit like the stockpile switch from the Minecraft Create mod, for example). The reason this is useful is that otherwise, beavers will stop producing certain items (especially consumables, which have frequent in- and out-flow) only for the items to immediately drop below the threshold, leading to them walking back and forth without having time to actually enter a different job. This is currently possible using two resource counters and a memory, but it would be nice for it to be included in the resource counter directly. This could also be applied to other sensors, but it’s most important for the resource counter, as it will often control manual work (as opposed to the depth/flow sensors, which also change frequently but are usually just used to control floodgates). It could be useful on the depth sensor in a setup that involves a fluid dump though.
-
06 Mar
NemoStein MergedThere is a SR Latch (Set-Reset) in the Memory automation that does this, but using it requires multiple sensors and a fair bit of Logic understanding.
I'm not sure if moving this functionality from Memory to Resource Counter would make Memory less useful or break the balance, but it's certainly useful to have this without building 3 (or more) building per automated resource... -
06 Mar
Jcheung System"Separate on and off conditions for resource counters, hysteresis for goods counting" (suggested by <Hidden> on 2026-03-04), including upvotes (5) and comments (1), was merged into this suggestion.
-
07 Mar
PieterWhy not pass actual values around. now everyting is quatized in the sensor, after that everything is boolean. If you could take a sensor and then pass it into a "within" range quantization block it makes it more intuitive to use for non-boolean people.
-
07 Mar
Codemaster256Just wanted to add (I don’t seem to be able to edit it now it’s been merged?), I’ve been playing around with it more and have switched exclusively to using 2 resource counters and a memory. This works fine, but it’s very time consuming to set up for a lot of different resources, and it’s not like the cost of the buildings is enough to be relevant, so I still think it would be far better if it was integrated into the resource counter directly. (Also more lag efficient maybe? Idk, depends how well optimised automation is)
-
07 Mar
Fred MergedFor (almost) every automation sensor I use I build a low bound, a high bound and use a Set-Reset memory building to set on low bound and to clear on high bound to implement the hysteresis. This keeps whatever I'm controlling from chattering. e.g. for the scrap metal mine I have my low bound set to < 90%, my high bound set to > 98%. I would be nice to have a separate setting for most sensors to add an optional hysteresis range, e.g. 2% or 5%, etc.
-
08 Mar
ThainaAlternative idea
- Have SR latch option logic in memory
- Allow memory to stack over other sensor (like detonator)
https://timberborn.featureupvote.com/suggestions/699694/sr-latch-block-to-be-placed-only-on-sensor -
08 Mar
Thaina Mergedduplicated? https://timberborn.featureupvote.com/suggestions/698362/1011-integrate-sr-latch-with-resource-counter
-
15 Mar
Jurgen MergedWhy make it so complicated for the resource counter?
Just let the user set a range and a checkbox to set true or false when whiting the range.
Makes is more simpel and adds more functionality.
Because now you need to have 2 counters and a relay to do this.
Keep it simple :) -
15 Mar
Robert Szynal MergedI came here to suggest this too. For example, the water storage trigger being set to a threshold results in flapping the water pump states too quickly to be of any use. I just end up using it like a manual switch. Having either separate on and off thresholds or a hysteresis percent/quantity, as suggested by Fred, would make them significantly more useful.
-
16 Mar
Gin Fuyou System"Hysteresis for automation sensors" (suggested by <Hidden> on 2026-03-07), including upvotes (8) and comments (0), was merged into this suggestion.
-
17 Mar
Alan MergedThe whole automation process is only on/off. While it works for anything, dams are creating vast amount of issues with such behaviour. It would be nice to have a function allowing for a dam to open or close at a given rate with a probe of any kind, For example, we could say that the dam opens between 0.2 to 0.7m should the flow be between 0.4m3/s to 1m3/s
Without it, flooding is likely given the waves the open/close creates. Moreover, as it is abrupt, it tends to fuzzy the sensors with peak/low values, making the sensors irrelevant in the vicinity. -
17 Mar
Gin Fuyou System"Automated dams should act smoother" (suggested by <Hidden> on 2026-03-17), including upvotes (1) and comments (0), was merged into this suggestion.
-
20 Mar
Peter34 MergedYou can already create an S/R latch with the current Automation system, but it's a complex process that requires advanced logic, and involves the construction of many interlinked Automation thingies.
Very few players are going to actually do that.
For the vast majority of the subset of players who are willing and able to use Automation, actually programming an S/R latch is too complex to become an actuality. It'll remain a theoretical possibility.
Add a new Automation thingie, one thingie, just one, that turns ON when value X is above Y and that turns OFF when value X is below Z, where Y is higher than Z. When the X value is between Y and Z the state doesn't change.
That'll make advanced Automation use *extremely* more accessible to a large subset of the player population. -
20 Mar
Gin Fuyou System"Add simple and EASY to use "hysteresis" automation" (suggested by <Hidden> on 2026-03-20), including upvotes (1) and comments (0), was merged into this suggestion.
-
21 Mar
Takeshi MergedI want to set a range for the resource counter so that production continues until a certain number of resources is reached.
-
21 Mar
Jcheung System"Set a range for the resource counter value" (suggested by <Hidden> on 2026-03-21), including upvotes (1) and comments (0), was merged into this suggestion.
-
22 Mar
Tonton MergedAdd the function Between to the Relais. This would allow the ressources to level as an example between 40-70% and not turn on an off the hole time (Wrokplace Management).
-
23 Mar
Gin Fuyou System"Relais automatisation" (suggested by <Hidden> on 2026-03-22), including upvotes (1) and comments (0), was merged into this suggestion.
-
02 Apr
QodvuxI'm strongly in favor of configurable hysteresis as it would simplify a LOT of setups, and not just for resource counters but for all sensors/counters. But I believe the best place to implement this is not in the sensors but in target buildings, as I suggested here:
https://timberborn.featureupvote.com/suggestions/704197/sensors-should-transmit-actual-values-instead-of-onoff-target-buildings-should-p
Otherwise you still need several identical sensors for one and the same physical property if you want several buildings to react to different values. Thresholds/hysteresis should come into play not BEFORE sending a signal but after, when PROCESSING it, based on actual sensed values instead of on/off, and – as argued here – not by intermediate/additional automation buildings but integrated into sensor-based automation conditions. This could still be an upgrade at a cost, but I'd prefer a one-time science fee for that instead of per-building material costs.