Suggestion: Slow Combinators for UPS

[JDoolin]

There are a couple of things that I like using combinators for that do not require 60 updates per second.

Come to think of it, there is only one practical situation where I can think that I might need a signal to be updated 60 times per second, and that is stopping a belt when there is something on it so that a slow inserter can pick it up.

Most of the time, though, I use combinators to keep a tally of supply or demand, which probably doesn't need to be checked more than once every ten seconds or so.

I've seen a couple of mods that seem to be working toward this. Factorissimo2 has factory circuit connector adjustable rates for transferring data in or out of a factory. And AAI programmable structures has certain structures that can be set to update their signals periodically.

I wondered, also, if there is any way to optimize circuits for updates-per-second in the current form of the vanilla game?

For instance, I've seen some people try to combine many signals into one signal; for instance, taking several variables with values 0 or 1, and multiplying them by 2, 4, 8, 16, etcetera and adding the result to get a single variable which contains all the information, encoded. However, this doesn't look like it would save on updates per second, but only make it so more information fits into one variable. But I don't know how the updates-per-second works. Does it actually take more updates-per-second to encode and decode the signals to and from one variable, or does it take more updates per second to update many signals. I would think that the encoding and decoding would take more time. I suppose I should ask this question in the context where I saw it.

[Tekky]

Some time ago (in 0.13 or 0.15 if I recall correctly), circuit networks were optimized so that only those circuit networks get updated whose inputs actually change. Therefore, I believe they are already optimized quite well.

I have never heard of the circuit network reducing the FPS significantly, unless of course you decide to geek out and decide to build your own video player into the game.

Therefore, I don't think it is necessary to try to optimize circuit networks as you suggested.

If UPS really is an issue, it already is possible to do what you want. For example, if you have a massive display board (with lights connected to circuit network), just create an additional circuit network that makes the input logic of the display only update once every 600 ticks. That way, the enitre display logic will only be updated every 10 seconds (=600 ticks), because, as I pointed out above, only circuit networks whose inputs change are updated.

[JDoolin]

Some time ago (in 0.13 or 0.15 if I recall correctly), circuit networks were optimized so that only those circuit networks get updated that actually change. Therefore, I believe they are already optimized quite well.

Hmmmm, well, maybe it's a question of what I've been doing with them...

I've been using a mining station with 24 steel chests, each one connected through red wires to an arithmetic combinator to divide the contents by 24, which is sent to 24 inserters, who insert into the chest if the quantity in their respective chest (connected by green wire) is less than the average value. Since those twenty-four inserters are each doing multiple inserts per second, and each chest-to-inserter connection is an independent circuit network, up to a maximum of 60 times per second, each train station is doing roughly 1440 calculations per second. So by the time I have 10 railroad stations in play, they are doing 14,400 comparisons per second, with 240+ independent networks.

What I've found is that my game tends to start running sluggishly, and I thought that might be a major factor. But then again, the sluggishness might just come from having so many belts, and so many inserters, and so much going on.

But I suppose, perhaps, the inserters were already doing that many comparisons per second, simply by comparing "Is there something on the belt to insert?" I thought maybe, though, that was somehow optimized internally in a way that the combinator logic was not.

In regards to Factorissimo, it is possible that I misunderstood: https://mods.factorio.com/mods/MagmaMcF ... ssion/9922
https://mods.factorio.com/mods/MagmaMcF ... sion/20239
He said that "circuit connectors" are very bad for UPS, but it may be that he was only talking about the custom circuit connectors that he made for his mod, and does not apply to circuit connections in the vanilla game.

[golfmiketango]

Some time ago (in 0.13 or 0.15 if I recall correctly), circuit networks were optimized so that only those circuit networks get updated whose inputs actually change. Therefore, I believe they are already optimized quite well.

I have never heard of the circuit network reducing the FPS significantly, unless of course you decide to geek out and decide to build your own video player into the game.

Therefore, I don't think it is necessary to try to optimize circuit networks as you suggested.

If UPS really is an issue, it already is possible to do what you want. For example, if you have a massive display board (with lights connected to circuit network), just create an additional circuit network that makes the input logic of the display only update once every 600 ticks. That way, the entire display logic will only be updated every 10 seconds (=600 ticks, because, as I pointed out above, only circuit networks whose inputs change are updated.

The "problem" here is that your 60 ticks timer is still buzzing away like mad 24/7. This could in theory* be ameliorated by creating one and only one "high resolution" ticks timer like this for your base, with a high modulus (flipover value) like 479001600 (12 factorial for max "divisibility"), a small "library" of "medium"-resolution timers (the obvious choice would be signals 2-9, A, and B, which would be clocked at 2, 3, 4, 5 and so on, ticks. Each would fire a one-tick pulse every time the high-resolution timer is divisible by the corresponding value. Finally, a small library of useful "low-resolution" timers could be built out of the medium-resolution timers, like M=(4 AND 3) AND (4 AND 5), which would fire once every 60 ticks (the redundant 4 being there basically to prevent asymmetrical timer lag problems) should be built, each connecting only to the medium-resolution timers they need if possible.

Finally one would distribute only those low-resolution timers you actually use, bundled into a single red/green wire network, to all of your timer-dependant builds, which would in turn only consume only the clock signals they require from that bundle.

That way you create an almost optimally UPS-efficient hierarchy of clocks, each calculated once for your entire base. Only one combinator is buzzing along at a one-per-tick rate and it is only consumed by five combinators: the 2, 3, 5, 7 and B (11) medium-resolution timers (the 4, 6, 8, 9 and 10 medium-resolution timers obviously have more efficient implementations: counting off multiples of the prime medium-resolution timers), and all of this clock nonsense is calculated only once for your entire base).

This is not a theoretical problem. Busy-spin clocks (that tick up from 0 to n instead of firing a pulse every n ticks) and small combinator builds with dedicated clocks perform admirably, but, not scalably in factorio UPS terms.

* In practice, however, I don't know if this is actually more UPS efficient or, if joining up so many different combinators to a single red/green wire network might have some kind of scalability problem that would cause this advice to give you diminishing returns beyond some maximum. If this were found to be so, I imagine the devs would be interested to hear about that.

[JDoolin]

This could in theory* be ameliorated by creating one and only one "high resolution" ticks timer like this for your base, with a high modulus (flipover value) like 479001600 (12 factorial for max "divisibility"), a small "library" of "medium"-resolution timers (the obvious choice would be signals 2-9, A, and B, which would be clocked at 2, 3, 4, 5 and so on, ticks. Each would fire a one-tick pulse every time the high-resolution timer is divisible by the corresponding value. Finally, a small library of useful "low-resolution" timers could be built out of the medium-resolution timers, like M=(4 AND 3) AND (4 AND 5), which would fire once every 60 ticks (the redundant 4 being there basically to prevent asymmetrical timer lag problems) should be built, each connecting only to the medium-resolution timers they need if possible.

I think it sounds like a good idea, if you're going to have several things going on periodically, for them all to share a single counter circuit, generating all your clock-related needs. But I'm not sure how to make it apply to the sort of supply-and-demand decider-logic I have in mind.

So if I have a bunch of chests connected to circuit network A, it would keep track of all the inventory in the chests. Circuit network A is going to update every time anything gets added or removed from the chests, up to 60 times per second, and so every belt and chest connected to network A will have to recalculate every sixtieth of a second whether it will enable or disable.

But if we disconnected all the inserters, and belts from network A, and instead set it up so when some timer "ticked" it would copy an instant snapshot of that inventory to circuit network B, and all of the inserters and belts and other logic that was connected to circuit network B would do one single calculation, to enable or disable, and then would remain in that state until the next timer "tick."

Do you have a method in mind for circuit B to maintain the static snapshot of the data to keep it unchanged until the next clock tick?

[JDoolin]

Two discoveries I have made since my last post:. One, by hitting f4 you can turn on a debug menu that allows you to turn on a time usage meter that tells you exactly how many milliseconds are used each tic by your circuits. Which means I no longer have to guess whether some new circuit contraption is using a lot of time.

The other discovery was that I was using the "rtts" mod wrong. I had installed it, thinking it might improve my updates per second by some kind of magic making my computer faster without new hardware. But I have never been much of a believer in magic, so as I suspected, it didn't work. All it did was made mining much slower and crafting much faster. However, then I came across a post that said rats had worked great for them.

Once I realized rtts had a setting called "target tick rate" I realized this was science, set it to 30, and all my lagging issues disappeared and crafting and mining times went back to normal.

[quyxkh]

[...]24 steel chests, each one connected through red wires to an arithmetic combinator to divide the contents by 24, which is sent to 24 inserters, who insert into the chest if the quantity in their respective chest (connected by green wire) is less than the average value[...]

Just a note, imho that setup is irredeemably inefficient. You'll do _much_ better with bars and scheduling. Say that's for loading two wagons with ore, you can fiddle the number for other situtations. That's 2K per wagon, 4K ore for 24 chests, ~167 ore per chest is what's needed to fill the wagons your chests are buffering for. So just set your chests' bars at 3 or 4 slots so there's no way the chests empty before the train leaves.

[JDoolin]

I had been optimizing for filling the train quickly rather than emptying the boxes. In general if there isn't enough ore present to fully fill the train the train station is disabled.

I think with my current mods the cars have 40 stacks of 200 ore each.
.

[JDoolin]

Ah but yeah. I figured out what you mean. If I just put limiters on the chests that fill up first I could balance them without splitters or circuits. That's a good idea.

[golfmiketango]

Despite my post above which might seem to suggest I don't think such a thing would be useful, I just wanted to mention: I think it would, in fact, be incredibly handy. Not only would they be helpful as clocks, they would be great for debugging.

It used to be that you could use a switch to turn a combinator on for a single tick and then leave it off for an arbitrary period. Since combinators deprived of electricity do not forget anything, a network of combinators slaved to such a switch, slaved to a timed pulse generator, would in effect slow them down to arbitrary speeds or allow you to pause a combinator build for as long as you wanted and then "step" through the ticks.

Unfortunately at some point in the early 0.15 days I think this broke. It could have been a bug either in my electrical network, or the game-engine, or something; I never got around to investigating it thoroughly, but it was as though the switch was allowing accumulators to bleed tiny amounts of power through after you threw the breaker. Maybe they acquired a very small battery or something; anyhow for reasons I never quite understood I started randomly seeing them run for two ticks about half the time.

When this worked it was pretty amazing, though. Unfortunately, keeping electrical networks separated is an incredible pain in the ass, so much so that it was almost always more trouble than it was worth. There used to be a mod to auto-disconnect power poles but I don't think it was ever ported to 0.15.

I haven't tried it, since, to see if that bug/pebkac ever got sorted out (I guess, mostly because of the power pole auto-connect issue) but you might find it worth your while to give it a try.