Resource counting with combinators

[XKnight]

One combinator per chest should be enough. Each combinators should have a different output "resource". Then you can store all chest values on one storage cell instead of one per chest. Then you can use Each>0 = Resource(input count) to sum all the different signals.

Actually there are even more ways... best is probably to activate all input inserters if all chests are empty and activate all output inserters when all chests are full. Than you can actually just sum up all chests.

Perhaps no one actually understand these messages, so I am going to show them on the real case:

Different item types per chest (1 combinator per chest + 2)

1.png (331.71 KiB) Viewed 7884 times

Blueprint

Code: Select all

H4sIAAAAAAAA/82abW+jOBDHv0rFyztSgZ8wWrFfZHWKKHFbSwkg46w2ivLdj6bZhgTW+GHuwsuK8PfMz/96mJE3zdO2qcrt07o4ilpLLUVXHI91uRNF1O1K
pVfVu+h0FLdN1z9t6uL4q1il6XOeMcoQjQ/FCv/+43SKL6++lp1eyboTSgtlfBmNX/7zuvnMsoaIk5CIk5mITS/n3tnygJC596pZwKpZACfmHTH1dgULyJV6
x0sCVsUBhIl3xHgm4lJJ/b4TWlarqtm9yLrUzd3q6DlBmODsIkEuEnHV1LWoPn7VHzw/ojT6pzgqsekPofN5dFjLTcHRqV/rR4SmHqIkrqSq9lKf/+pjGjxD
t89O8ZsSor55n+DTh3ofx0ZewrimUxxfper0upNvdbktjvrQ9un+lErvy20UX7idH65EWb1HZ6FOl7UukrhphSrPAKK/o7jZ63ZvJ5VG55js6aYhdFMD3TS3
IIiWRzBxJUhCCBKTP5HBn8SCLlseXexKF4fQZQ7+vKGbWtDNlkcXudJlIXS5ybvEQJfO06XJ8uhSV7o0gG6emOimBrrYgm66PLrElW4WQheb6GIDXWZBlyyP
LnOly0PoGqsaNdDNLOjS5dHNXOnmIXRNVe3enzd0+fBZOk2XL48ud/6mTZ/pFe+1X4k3Un3SLZAV6ns/Dmmy5I7m156MqbK7TuO/QbxKh4z/cmL8qTXALH61
SnTdSquy7tqmb+9exNY8zUknQbsp5tCCtxMYCMUMWpBDCzJoQQotSKAFMbQgAjcitCC0sZNhTZrR+xz4TE+LbiYKyVVn6sAdH5WmoUyWj07Oy2+djs2fQh30
u6zfbutTX03aUn1UkyIqosFRaEoWBSVr6kH5uAP6P5K1cUrq4BQbPQTkPBLmPENTxcejvkc7D4cla5gt8fEX9lKch4GdR4Ccx8I2w9Bw8vGY6dHOo2HJGiZD
/DEHvI1TGLDzKJDzsrDNMDTj+XhI9Gjn8bBkDb1xPm7KluI8Duy8DMh5edhmGFrrfLkFKHeAtxGV3AhlOaaYFrMbU1gMdsYjCNtxRWoYIo3/ay5Jh42Khlv0
3WmO8bLdi7NWe1hXzb7W61fV7Nay7gWKSKuPpx6XTb6+eIebQ2xujwxVvjos53snE29aXzvxjj33DyCHWD/zRcf9A+f2gdteZwmQYRAYmS9G6o+RwuRPIPIn
vvlj//yxa+Dzo5SBjF2Fnbhc4VFFy3quhn73mZW4ZwPSgXtlM+GN4cYk5lTMt47O39jz6yH/9W5nTFPrzQ9T3HdrfPXkgbtFAnYr9aOHg+iB9PxQ9HAAPeRH
j4XQm7g68kB6LIAe9qNHg+iBdP1Q9GgAPeJHLwuiN7768diay4OyAenDobyQBXiBetRcHrAe8/NeHrRb46sbD9ytPIBe9md67tcS0HXx6+c3C7hEACGYA+tx
YL0MWI8B61FgPQKsh4H1ELShgfWA/z+GVxEs5bp2K7WxgUa/p60+QghKCEMJESghCiXEoIQyKCEOJZTPC51iWZ2r2lHWG9FbLzb6vV/483coHlfSvuB9U0Lv
Vf20/ibqzb9vLo9ybTkAAA== 

Chests summarizing (0 combinator per chest + 4). This is actually useful for counting inexpensive items like plates, green circuits, etc.
Because this build transfers 9 items simultaneously and 8 items will have to wait for the ninth.

2.png (345.1 KiB) Viewed 7884 times

Blueprint

Code: Select all

H4sIAAAAAAAA/9Wa326jOhDGX6Xi9pAKjG2wVuyLrI4ilritpcRExlltFPXdj5P2tDHxEv8ZqexebZrys79vBmY8dDM8bIe+2z6s2xOXWmjBx/Z0kt2Ot9lT
N+qVkCNXmqss3w+j+X6Q7el3uyrLR1ZTQhHJj+0K/f/h9TX3ubi4c/G465Re9S981LOXVkGXlncundsyS5DbRKttosWyBK11glYarZVGa60TtJIErThaK47W
ShK0VtH7re6syn/vFR/HlVadHPeDofzk2wmkfCxQhat6snq+EYr3l1/CQTx0l0eDeBUwDwPzCDCPAvNqYF4DzGPAPFOJYIGT2la6iCiQWEITGTSwgQbW0EAK
DSTQQAwNrKCBCDyzoYHQ9571dADglQG8t0Lu7gIsTvHJ6Qcp30DmAPAjK7N/25PiG3MYuJwLjmuxaTE1Jf9ZcS6tHzfo1fw7EzbiHdAL1R+Ebk9PQo16PYpn
2W3bkz7uzfZ+CaUP3TbL33d7+XLFf3F11C9CPmcX1qg7qdvC/He371SnB9VmbfYa1nQg4ChUQFFAKVGozBJXH2t3UPCXBGVOdJWWepZo5hZNF5uJGChzcIqJ
tWUiKdwmNovLHJIimtmikVM0KxabOQQoc2iCiSZVLBOx28TlFgIKZGKdYiKyTXQ/uNnXPLiDj3gA1ZQBBaVJCQq2g+IuLGy5haUBMpGlmGgXFlrm7+6cP9lZ
z/6Q9V9TdMIP+p8Of0A2vBcbrlZmlZ9CnleZANAjcVp7NSlw2nxr05yzFNnfmQ3+yJAzXHZJZOz6wtIZH3vhcmbhcp49CfK7d0FB7vqX6/CySXjz4aD3h0DW
/rjuh4PU6yc17NZCGkCbaXXg19kSFmj3veh1P53vhrtBuI7w/YD91cZ7v0z6ON2658reb7TucDxfMn08OILfbDmu9H3DlGABg3CAxRrQxOunMPprCP11rH4a
rx/D6CcQ+kmsfhyvv4LYeOWz8ftDtav1fR71TQXR+HTyXtvz/fas7TDhWkgRKMR9JsQXfcFDsVAX7a6jIUsyFSWYard4jXsAi6m3x1VSplp7qZfkcZWUuJYu
d++Fa2+PcYLHxN4LW5LHOMFje3zL3JNHzLw9Jgke24dVdtsbf6HHJMHjxtblHnSSwttjmuDx5IS5qCJH4z1m9hyUuWseQd4e1/Ees8lJe1E1r07weDIwctc8
gr09bhI8tmseW1TNaxI8tmveH+YNxL/msXiPp9OoReUxi/d4diz2h6S2C2DQvMl57vEbN93MlYJmT1NaiW4GkX/x6Cn876yQKxApfwoGAWTAvAaYVwPzKDCP
APMwMA8B8ypgHnQ+R9xw434r9Ozo5uNxGr+xwsIl7KsK35cbhKBABAqEoUA1FIhCgRooEPMHdUrolx3XovdrFJxp6dcoOEq7Zxcw91bwtkP4lJTSJBT5sOem
RTjry/6J6BEu+xL9ZUsnITfcOJnPPguMyrffQ/ltY2lo3xTXByUf1t+43PwH8QaDOX01AAA=

wire all chests with input of arithmetic combinator sum/#chests=iron, this will be 1 if all chests have one iron otherwise 0.
wire (same color) combinator output to every input and output inserter.
wire (different color) every chest with every input and output inserter.
input inserter rule: iron=0
output inserter rule: iron=2 *might not work due to inserter timing, in that case it will get a little more difficoult

Rule "iron = 2" will work only if all output inserters transfer items simultanesouly which is not possible at all.

Breaking example

(3 chests)
0: first chest - empty, second chest - empty, third chest - empty. Sum = 0, Sum/3 = 0.
Rule "iron=0" is active, all input inserters put one item into its chest.
1: 1 plate, 1 plate, 1 plate. Sum = 3, Sum/3 = 1.
Rule "iron=2" is active, all output inserters get one item from its chest.
2: 0 plate, 0 plate, 0 plate. Sum = 0, Sum/0 = 1. Unfortunately, first output inserter couldn't place item on the belt, so it is still holding an item.
Rule "iron=0" is active.
3: 1 plate, 1 plate, 1 plate. Sum = 3, Sum/3 = 1. First output inserter is holding an item.
Rule "iron=2" is active. But first output inserter is still busy.
4: 1 plate, 0 plate, 0 plate. Sum =1, Sum/3 = 0.
Rule "iron=0" is active.
5: 2 plate, 1 plate, 1 plate.
From this moment this setup will be broken because no one actually expect 2 plates in a single chest.

P.S. These builds were successfully tested with jammed output belts.

[siggboy]

Perhaps no one actually understand these messages, so I am going to show them on the real case:

It helped.

Different item types per chest (1 combinator per chest + 2)

This is not going to work anymore (in 0.13):

obsolete.PNG (126.27 KiB) Viewed 7876 times

The decider combinator will get changed and it won't be possible anymore to add up different input signals in this fashion. Actually it is probably not going to be possible anymore, at all (unless you do it manually with lots of dummy combinators for recoloring).

A good change, if you ask me, the current behaviour makes no sense (it's useful in this case, though). Actually I was wondering where you could abuse the current behaviour of the decider, this is actually a good example.

Maybe something important should be mentioned about the first implementation: the smart inserters don't look into the chests themselves, they take the input from the combinator that does the counting. That way, the information (count) from the chest is delayed by 1 tick, and this avoids the problem that the input inserter will drop the item right into the hand of the output inserter, instead of into the chest.

This little quirk is actually what makes the setup work at all.

But I like the second implementation a lot better anyway (chest counting in batches of 9 items).

It's a little slow, though. In my tests even 22 inserters could not manage to empty a compressed blue belt. It's probably not so great for counting very high volume belts.

Chests summarizing (0 combinator per chest + 4). This is actually useful for counting inexpensive items like plates, green circuits, etc.
Because this build transfers 9 items simultaneously and 8 items will have to wait for the ninth.

You can also be hard to understand, sometimes .

I really like this way. I did not understand how kann_ was supposed to synchronize the inserters.

The various combinators delaying the signal several times, very nice. Very difficult to understand. Almost sad it will be quite useless with version 0.13.

I have to give it to you, XKnight. Every time you post something about combinators, it's really clever, and useful.

[XKnight]

This is not going to work anymore (in 0.13):

Indeed, it is announced that this behaviour will be changed in 0.13, but this doesn't mean new behaviour will be inapplicable...
Personally, I will talk about combinators in 0.13 only after playing with them directly.

Anyway, is is still possible to solve this task with 1.5 combinators per chest using "stable features" + "different item per chest" with arithmetic combinators:
"signal 0 + signal 1 => plate", "signal 2 + signal 3 => plate" ...

[siggboy]

Anyway, is is still possible to solve this task with 1.5 combinators per chest using "stable features" + "different item per chest" with arithmetic combinators:
"signal 0 + signal 1 => plate", "signal 2 + signal 3 => plate" ...

Yeah, sure but it's not nearly as elegant as having 1 combinator add all of them. Setting all the different virtual signals is so tedious, one for each combinator. It's not elegant. It works well but I don't find it aesthetically pleasing. (Same with binary decoder that uses a combinator full of constants. It works, but it's ugly.)

The other solution, where the 9 inserters are synchronized, that's actually amazing, and then only 4 combinators for the entire counting, it's really good. You make a lot of good combinator designs. Please look at my train scheduler and tell me what you think or what you might improve (it's here: viewtopic.php?f=8&t=25311).

[golfmiketango]

This is not going to work anymore (in 0.13):

Indeed, it is announced that this behaviour will be changed in 0.13, but this doesn't mean new behaviour will be inapplicable...
Personally, I will talk about combinators in 0.13 only after playing with them directly.

Anyway, is is still possible to solve this task with 1.5 combinators per chest using "stable features" + "different item per chest" with arithmetic combinators:
"signal 0 + signal 1 => plate", "signal 2 + signal 3 => plate" ...

Yeah, I'm not sure, myself, that I get what they are saying is going to happen... but I've only skimmed through the thread where it's proposed; it seems like the full intent is spelled out pretty clearly there but I'd probably need to sit and scratch my head longer than I have to fully grasp it. Wish I could link to it but I can't find the damn thread anymore... was just reading it yesterday... bah... *throws up hands in frustration*

[golfmiketango]

Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator? Then I can eliminate a whole row of combinators. But, otherwise, I plan just use OP's two-combinator design and de-specialize the whole apparatus to not depend on item-type.

I'm sure this is impossible, for the following reason:

What you want is an edge detector for a rising signal. So there's the temporal component (signal changing from one tick to the next), which you can only isolate by delaying the signal. This requires 1 combinator.
Then you need to compare this delayed signal (from 1 tick in the past) to the present signal (to detect the change and, optionally, to distinguish rising from falling edges). This requires another combinator. It can never be the combinator that you used to delay the signal, because you can't delay a signal with an operation and use the same operation to compare the past version to the present version, because the delay has not happened yet.

If we did have an "oracle" combinator that can view 1 tick into the future it might be possible, however . Or we'd need a combinator that can do more than one operation during the same tick.

Yes, I'm inclined to agree. It's much harder to rigorously prove something can't be done than that it can, but your analysis sounds correct to me.

Regarding your counter contraption:

1. You do not need smart inserters on both ends. It's enough if you have smart inserters removing the items (each connected to the chest in front of it), and configure it to only act when the chest is not empty (otherwise the loading inserter might skip the chest and hand the item directly over to the unloading inserter, and then the item won't be counted).

This, and there is the possibility of items going into and out of the chest simultaneously going undetected. It seemed to me that limiting the inserters to act one-at-a-time was by far the most rational starting point. From there, I suppose it might be possible to implement something like you describe but I would be concerned about the inserter-to-inserter handoff situation and other potential complications, like simultaneous addition and subtraction to and from the chest -- the only way to rule those out, imo, would be extensive testing, and not only with saturated belts.

I expected fully, by the way, that this limitation of both inserters would slow down the per-inserter efficiency of the device. In my mind, it should add the duration, whatever it may be in combinator ticks, of one-half-smart-inserter-rotation to the time cost of measuring each object on the belt, hence it's not surprising that...

2. You do not need that many chests/inserters to count a blue belt. 20 inserters/chests is already more than enough.

...I did need that many in my contraption as implemented.

3. Your layout can be more compact.

No doubt. Compactness was not a design objective I gave much thought to.

Here's my version (I've tested it, it's count-perfect). There are 22 chests in this version, so you can remove one column, 20 inserters/chests is enough for one blue belt -- well 20 FAST inserters is enough, the smart inserters are a bit slower, so probably 22 chests is the correct number or otherwise some backlog might be building up in the chest, albeit very slowly.

Oh, and by the way, this will be entirely moot in 0.13 because we'll be able to count belt contents directly .

Interesting use of a splitter-bus. What inspired you to do it that way? Personally I've made it a habit never to drop items directly into or pull items directly out from splitters as I pretty quickly came to the conclusion that I didn't know what the rules were, but the crap I expected to happen wasn't happening -- but that's just a fancy way of saying I've been too lazy to learn some stuff.

[siggboy]

Yeah, I'm not sure, myself, that I get what they are saying is going to happen... but I've only skimmed through the thread where it's proposed; it seems like the full intent is spelled out pretty clearly there but I'd probably need to sit and scratch my head longer than I have to fully grasp it. Wish I could link to it but I can't find the damn thread anymore... was just reading it yesterday... bah... *throws up hands in frustration*

You're talking about this thread: 13706

The two main reasons for the change are:

1. The current user interface is ambiguous, because it doesn't tell you what is meant by "input count". Is it the count of the input to the predicate function? Or is it the count of the signal that you actually want to output? It's also downright confusing, because it will take the count of the output from a different signal than the output itself.

2. While the current behavior allows for obscure solutions like summing a bunch of different signals in a single combinator (as demonstrated by XKnight above), it does not allow a much more common (and arguably more useful) scenario, namely to use the decider as a tri-gate (think of a triggerable "valve"). In version 0.13 this will be very easy: apply "Blue = x" and "Red" to a decider; let ONLY "Blue = x" pass through if and only if "Red = 1"; currently not possible because you can't pass the count from Blue, unless you pass "Everything (input count)", which is what most people do but it's often quite ugly.

Just try to solve the following problem in 0.12: you have a wire with many signals on it (e.g. "A", "B", "C", "D", ...). Extract a single one of these signals from the wire (e.g. "B"), but only if signal "Red" is equal to "0" (i.e. not on the wire). Or in other words: make a filter extracting "B" which can be disabled with "Red = 1".

Not exactly an exotic problem (it comes up all the time when you have a shared message bus), and if you look at the Decider Combinator your first impression will be that it's straightforward, but it's not.

So that was a lengthy explanation of the change, I hope it helps.

It's a good change, but some people are violently against it because it can break some setups.

It's much harder to rigorously prove something can't be done than that it can

That's not true. Negative proofs are not inherently more difficult than positive ones, it's just a matter of applying the correct proof technique and reasoning.

We don't have the formalism for making actually rigorous proofs about combinators. Your delay problem doesn't really require that, though: you can't compare A to B before B even exists, q.e.d. :)

Negative proofs can never be constructive, i.e. they can never give an example for something that is proven to not exist -- which is probably what makes you think they're more difficult, because you like to think in examples.

But in mathematics, computer science and logic, proofs are usually not made by way of listing examples, so it's really not important if you're trying to prove a positive or negative statement.

Negative proofs are often done as "proof by contradiction": if you want to prove that "S is false", you assume instead that "S" is true, and then show that this leads to a contradiction.

Interesting use of a splitter-bus. What inspired you to do it that way? Personally I've made it a habit never to drop items directly into or pull items directly out from splitters as I pretty quickly came to the conclusion that I didn't know what the rules were, but the crap I expected to happen wasn't happening -- but that's just a fancy way of saying I've been too lazy to learn some stuff.

I got that idea from here: http://imgur.com/a/WytKJ I just love it and always use it when I have to unload from a row of chests onto a belt.

If you insert into the splitters, then your inserters can't clog eachother up, they will always work at maximum speed as long as the belt is not backing up. This is because every splitter is like a mini-buffer for 1 item that drops the item onto the belt (at the exit). If you drop directly onto the belt, there might be an item in the way and your inserter would be delayed for a moment.

The splitter bus is also a lot more compact than the usual way of merging several lanes hierarchically. Which is why I love it for train unloading and I've also started to use it at the exit of a smelting setup (from the buffer chests onto the belt).

I'm not sure if we'll still need that construction with the new rapid inserter that is coming with 0.13. It might be awesome in combination, or not needed anymore at all. We'll see.

[JasonC]

@siggboy FYI, not sure if it's useful for you, but if you want more precision with rate calculations one trick I like to do is e.g. multiply the resource count by 1000 (or whatever) before dividing by time, then your output is in thousandths of an item per time (i.e. deal with fractions by doing fixed-point math, since combinators only work with integers). E.g. the rate tests at viewtopic.php?f=18&t=23409#p146781.

[JasonC]

Personally I've made it a habit never to drop items directly into or pull items directly out from splitters as I pretty quickly came to the conclusion that I didn't know what the rules were, but the crap I expected to happen wasn't happening

Prior to 0.12.31 there was a bug when inserting onto splitters which you may have been running into. Since then it makes a lot more sense. See my images here for the way it used to work and the way it works now.

Btw, in a setup like that it is usually overkill to use one splitter per inserter. Often you can get away with small groups of inserters going onto their own belt then using a splitter to merge it into the real belt.

Also, fyi, another good use for inserting onto splitters is to get long inserter distance with fast inserter speed (both to and from the belt), e.g. here.

[golfmiketango]

Yeah, I'm not sure, myself, that I get what they are saying is going to happen... but I've only skimmed through the thread where it's proposed; it seems like the full intent is spelled out pretty clearly there but I'd probably need to sit and scratch my head longer than I have to fully grasp it. Wish I could link to it but I can't find the damn thread anymore... was just reading it yesterday... bah... *throws up hands in frustration*

You're talking about this thread: 13706

Ahh, thank you, that was driving me nuts.

The two main reasons for the change are:

1. The current user interface is ambiguous, because it doesn't tell you what is meant by "input count". Is it the count of the input to the predicate function? Or is it the count of the signal that you actually want to output? It's also downright confusing, because it will take the count of the output from a different signal than the output itself.

2. While the current behavior allows for obscure solutions like summing a bunch of different signals in a single combinator (as demonstrated by XKnight above), it does not allow a much more common (and arguably more useful) scenario, namely to use the decider as a tri-gate (think of a triggerable "valve"). In version 0.13 this will be very easy: apply "Blue = x" and "Red" to a decider; let ONLY "Blue = x" pass through if and only if "Red = 1"; currently not possible because you can't pass the count from Blue, unless you pass "Everything (input count)", which is what most people do but it's often quite ugly.

Just try to solve the following problem in 0.12: you have a wire with many signals on it (e.g. "A", "B", "C", "D", ...). Extract a single one of these signals from the wire (e.g. "B"), but only if signal "Red" is equal to "0" (i.e. not on the wire). Or in other words: make a filter extracting "B" which can be disabled with "Red = 1".

Not exactly an exotic problem (it comes up all the time when you have a shared message bus), and if you look at the Decider Combinator your first impression will be that it's straightforward, but it's not.

So that was a lengthy explanation of the change, I hope it helps.

Well it definitely helps me understand why the change is made. Not sure I have grokked exactly what is being changed but I think I am probably just being mentally lazy, I get the gist.

It's a good change, but some people are violently against it because it can break some setups.

Any change is bound to have a few impassioned detractors. Of course, if their complaint could be fixed by a mod, it's worth considering that those detractors are apparently even more passionate about not implementing a mod, than they are about their original complaint I have enough faith in the factorio developers not to do anything hopelessly silly on purpose, to be confident that, once I see it in-game, the old brain-indicator-light will fully illuminate.

It's much harder to rigorously prove something can't be done than that it can

That's not true. Negative proofs are not inherently more difficult than positive ones, it's just a matter of applying the correct proof technique and reasoning.

[snip!]

Negative proofs can never be constructive, i.e. they can never give an example for something that is proven to not exist -- which is probably what makes you think they're more difficult, because you like to think in examples.

But in mathematics, computer science and logic, proofs are usually not made by way of listing examples, so it's really not important if you're trying to prove a positive or negative statement.

Negative proofs are often done as "proof by contradiction": if you want to prove that "S is false", you assume instead that "S" is true, and then show that this leads to a contradiction.

I think there must be more to it than that. For example, consider the statement "This statement is false", which, if it is false, leads to a contradiction, and therefore, must, by your proposed mechanism, be true. Even if we try to fix the mechanism by saying that, since this statement led to contradiction both ways, it must fall into a third truth category we'll call "nonsensical", we can still construct predicate-logical statements such as "If pigs can fly, then 2+2=4" which don't have this problem, but will cause any quick-and-dirty formulation of proof by contradiction to confirm some extremely counter-intuitive hypotheses.

But, I'll leave it there, as we seem to have stumbled into the very interesting but also very off-topic and confusing areas of scientific methodology and the metaphysics of epistemology, which, most likely, we needn't figure out, entirely, just to play factorio

Interesting use of a splitter-bus. What inspired you to do it that way? Personally I've made it a habit never to drop items directly into or pull items directly out from splitters as I pretty quickly came to the conclusion that I didn't know what the rules were, but the crap I expected to happen wasn't happening -- but that's just a fancy way of saying I've been too lazy to learn some stuff.

I got that idea from here: http://imgur.com/a/WytKJ I just love it and always use it when I have to unload from a row of chests onto a belt.

If you insert into the splitters, then your inserters can't clog eachother up, they will always work at maximum speed as long as the belt is not backing up. This is because every splitter is like a mini-buffer for 1 item that drops the item onto the belt (at the exit). If you drop directly onto the belt, there might be an item in the way and your inserter would be delayed for a moment.

The splitter bus is also a lot more compact than the usual way of merging several lanes hierarchically. Which is why I love it for train unloading and I've also started to use it at the exit of a smelting setup (from the buffer chests onto the belt).

I'm not sure if we'll still need that construction with the new rapid inserter that is coming with 0.13. It might be awesome in combination, or not needed anymore at all. We'll see.

Love it. I'm sold. A similar idea I had watching antielitz latest-and-greatest was to use underground belts to try to enable inline inserters to more fully compress a belt. This makes me wonder: how close to fully compressing a belt-side with a single row of inline smart-inserters might one be able to get by cleverly combining both ideas? Actually, re-reading what you've written, it sounds like maybe the splitter-bus alone is enough to do it. I guess there's only one way to find out....

[siggboy]

Prior to 0.12.31 there was a bug when inserting onto splitters which you may have been running into. Since then it makes a lot more sense. See my images here for the way it used to work and the way it works now.

That's interesting, it never occured to me (I'm pretty sure I've used the splitter-bus before 0.12.31, the author of the cheat sheet that suggested it certainly has, because the cheat sheet is over 6 months old).

The old behaviour was only a problem when your splitter-bus was longer than 9 tiles (for a blue belt), because 9 inserters are just barely enough to fill one side of the belt. Since I've only used this to unload trains, where the bus is never longer than 7-8 tiles, it didn't really matter that I could only compress one lane due to the bug.

I have to try it without merging the belts at the exit of the splitters, that should not be necessary anymore after the bug fix. It would probably even be possible to make a 18-inserter splitter-bus and get a fully compressed belt as a result.

Btw, in a setup like that it is usually overkill to use one splitter per inserter. Often you can get away with small groups of inserters going onto their own belt then using a splitter to merge it into the real belt.

Yeah, but as mentioned above if you use it to unload trains it's just way easier to drop a row of splitters next to each wagon and merge the two sides of the railway once at the end of the train (like what is shown on that cheat sheet).

It also means your entire setup is exactly 5 tiles wide: (wagon) -> inserter -> chest -> inserter -> splitter, and then you can put a substation next to it (2 tiles) and it's tileable with a 6-rail gap between each platform. Very convenient to make compact train stations.

Saving a few splitters by merging small groups of inserters is not going to make the setup more narrow, so I've never entertained that idea.

Also, fyi, another good use for inserting onto splitters is to get long inserter distance with fast inserter speed (both to and from the belt), e.g. here.

Yes, lovely, basically a belt that is two tiles wide. (Why don't we have that, btw? :)

@siggboy FYI, not sure if it's useful for you, but if you want more precision with rate calculations one trick I like to do is e.g. multiply the resource count by 1000 (or whatever) before dividing by time, then your output is in thousandths of an item per time (i.e. deal with fractions by doing fixed-point math, since combinators only work with integers). E.g. the rate tests at viewtopic.php?f=18&t=23409#p146781.

Yes, I know about this sleight, it's often done when you need to deal with monetary values and don't want to write special purpose functions. So you multiply by 100 and then do all calculations in cents.

I think in this case it doesn't really help to get more meaningful results, because 40 units/s is not really much, and polling for less than a few tens of ticks gives rather inaccurate results anyway, due to aliasing -- the flow rate would have to be way higher, and then one could integrate over shorter time spans, and the multiplication trick would be very useful.

[siggboy]

I think there must be more to it than that. For example, consider the statement "This statement is false", which, if it is false, leads to a contradiction, and therefore, must, by your proposed mechanism, be true. Even if we try to fix the mechanism by saying that, since this statement led to contradiction both ways, it must fall into a third truth category we'll call "nonsensical", we can still construct predicate-logical statements such as "If pigs can fly, then 2+2=4" which don't have this problem, but will cause any quick-and-dirty formulation of proof by contradiction to confirm some extremely counter-intuitive hypotheses.

"This sentence is not true." is the "Paradox of the Liar", but it does not mean that proofs-by-contradiction are invalid.

The Liar's Paradox arises because "Truth" is not a finitely describable thing. This observation, by the way, gave rise to one of the great mathematical discoveries of the 20th century, to wit, Gödel's Incompleteness Theorem (which says that no mathematical system can discover all truths).

Proof by contradiction does not invoke the Liar's Paradox, at all (because such proofs don't have to involve self-referential statements such as the Liar's Paradox).

Here's a great proof by contradiction (and you see that it doesn't touch the problem that the Liar's Paradox invokes):

But, I'll leave it there, as we seem to have stumbled into the very interesting but also very off-topic and confusing areas of scientific methodology and the metaphysics of epistemology, which, most likely, we needn't figure out, entirely, just to play factorio

I think you might greatly enjoy this book: "Infinity and the Mind", by Rudy Rucker

[kann_]

Actually there are even more ways... best is probably to activate all input inserters if all chests are empty and activate all output inserters when all chests are full. Than you can actually just sum up all chests.

Perhaps no one actually understand these messages, so I am going to show them on the real case:

I am so proud right now.

Sorry that I am so bad at explaining. I was out for a few days and couldn't work on a working example myself. So thank you even more XKnight.

Btw. talking about splitters and good use: if you want to count the throughput of a full belt you can send it through four splitters in a row, count 1/16 th of the throughput and connect all the splitter outputs again. Multiply the result with 16 and your have your final result.

[siggboy]

Btw. talking about splitters and good use: if you want to count the throughput of a full belt you can send it through four splitters in a row, count 1/16 th of the throughput and connect all the splitter outputs again. Multiply the result with 16 and your have your final result.

LOL, that's ingenious, the best solutions are often the simple ones. It doesn't have to be a full belt, you can count any belt that way, at the expense of some precision.

[golfmiketango]

Apologies for the semi-hijack but I have a technical question which seems to have become a requisite of my counter project; I suspect the folks watching this thread are as likely as anyone to know the answer.

My question is: if I have a combinator-based timer, i.e.,

Code: Select all

[ Const: 1 Blue ]
      |
      r
      |
      v
[ Decider: Blue < 61: Blue input count ] -+
      |        ^                          |
      r        |                          |
      |        +------------g-------------+
      v
[ Decider: Blue == 1: 1 Yellow ]

What will happen in factorio-space, if I run a compile on my computer while playing factorio (or deconstruct a Bob's-mod roboport, etc), causing my UPS to droop? Will this cause some kind of combinator-time-dilation to occur in-game?

Assuming it would, then I have a second question: if, instead, I implement a timer using, say, a circle (square, really) of inserters shuffling an iron plate between smart-chests, would the same time-dilation occur? Or would the inserters be immune to this UPS-induced "tick" slowdown? What if they are smart inserters with circuit conditions?

Note: I'm aware that if there is a power insufficiency, all these entities will slow down (a problem, if they do so in lockstep, which neither approach, nor any combination thereof is going to be able to address), but I'm wondering specifically about what happens when UPS (or, if it matters, FPS, but I suspect it doesn't) happens to be low for some reason orthogonal to power-insufficiency.

I'm sure you can all surmise how this question became relevant when building my resource counter -- I'm wanting to provide some "items/game-time-unit" averages but trying to figure out how to do so in a minimally flakey manner.

[DaveMcW]

UPS is not an issue, everything slows down at the same rate and it's undetectable inside the game.

[siggboy]

UPS is not an issue, everything slows down at the same rate and it's undetectable inside the game.

Yes, but the length of "1 tick" measured in real-world time (seconds) will change; I think that is what he was alluding to with his question.

The rule "60 ticks = 1 second" is only true at the full 60 UPS.

[golfmiketango]

UPS is not an issue, everything slows down at the same rate and it's undetectable inside the game.

Yes, but the length of "1 tick" measured in real-world time (seconds) will change; I think that is what he was alluding to with his question.

The rule "60 ticks = 1 second" is only true at the full 60 UPS.

Actually I wasn't... So if I'm understanding you correctly (pretty sure I am):

Let's say I am binge-watching episodes of The Smurfs on my tablet, and have a factorio instance on my computer, in which I'm moving a shit-ton of coal between two warehouses, by means of an inserter. During the first episode of the Smurfs, my UPS is 60 and I manage to move 10,000 coal. Now, let's say, just between the first and second episodes of the Smurfs (assume they are all the exact same duration), my UPS suddenly drops to 30 and stays there for the duration of the second episode. You are saying, all other things being equal, I will move only 5,000 coal during that episode? And, if my UPS then drops to 3 for the duration of the third episode, I will move only 500 coal during it?

I used to think that was how it worked, but recently, my Bob's campaign started getting crushed under the yoke of I'm-not-entirely-sure-what (but probably the Warehouse mod), hovering around 25 UPS all the time. It can drop as low as 5 UPS if, for example, I request deconstruction of a bunch of warehouses containing several million items. I am pretty sure when this happens, although game-time clearly starts to progress more slowly in real-life (a fun, but otherwise needlessly confusing, way to express this is that "Smurf"-time clearly contracts in-game), it's hard to believe that my game is really running 12 times slower than it would at 60 UPS. Subjectively, it seems like the slow-down is several times less severe than that (game-play becomes increasingly "choppy", presumably due to the FPS problems that always accompany UPS problems on my box. But that's obviously not the same as lowering game-time:real-time as otherwise you could slow down the game by playing peek-a-boo with it ).

Assuming my subjective sense of what's going on to be right, I had concluded (but "in pencil") that the likely significance of UPS is as a kind of "fudge factor" which factorio uses to measure how many "adjustable-granularity" calculations it is performing per game-time-second, and concomitantly, that the combinator tick-rate was likely one such "fudge-factor" (also probably I based that on things I'd heard people say around here -- but perhaps they were talking about real-life time, and I heard "game-time" because confirmation bias). Since it's hard to precisely target a UPS any science you might want to do to "prove" that would need to, i.e., screen-scrape the UPS from the game-window, which is more work than I'm willing to do to figure it out.

Another thing that made me doubt UPS measures game-time:real-time was that setting the game-speed in the console failed to cause an almost exactly proportionate change to the UPS (maybe because it's already bottlenecked elsewhere, or because the game.speed frob doesn't do what I think it does).

I must admit: the more carefully I spell out my working assumptions, the less plausible they sound to me... but I'm encouraged by this, since, in the "Smurfs" scenario above, my question has a clear answer: the two are exactly the same, but the combinator-based timer is going to be more reliable, since it allows us to tick off exactly one game-second with no rounding error and will be less prone to breaking due to incidental ridiculous circumstances (i.e.: "oops, I accidentally dropped a bunch of turrets into my clock and now they're gumming up the works"). Anyhow, if strictly UPS=[60 * (game-time seconds per meatspace second)], it is presumably impossible to measure anything in-game in meatspace time units, without peeking at the UPS statistic, which AFAICS is going to be impossible without some kind of mod.

To be clear, my objective in the build I discussed in my previous post to this thread is to measure in-game time intervals.

[siggboy]

You're making it way, way, more complicated than necessary.

I was only talking about combinator "ticks". A combinator only does something when it "ticks". If you feed an "Each + 1" arithmetic combinator back to itself, it will increase the value exactly once per tick (this is the simplest possible "clock" that you can build in the game).

The "ticks" only happen when the game engines updates the internal state of the game. How often the game engine updates is indicated by the "UPS" value (updates per second).

At full speed, the game does 60 UPS, so your combinators will tick 60 times per second (each update = 1 tick).

If you use the clock mentioned above you can measure how many UPS you have (just count the ticks from the combinator per time unit, e.g. with a real-world stop watch).

You cannot reliably measure real-world passing of time with a combinator unless you know a priori that your UPS is constant (i.e. 60).

[JasonC]

What will happen in factorio-space, if I run a compile on my computer while playing factorio (or deconstruct a Bob's-mod roboport, etc), causing my UPS to droop? Will this cause some kind of combinator-time-dilation to occur in-game?

On this forum and elsewhere, in the context of Factorio, when we say the word "second" we almost always mean a "game-second" -- i.e. 60 ticks -- unless otherwise specified. We never talk about wall clock seconds because that's not generally a useful time unit in discussions here.

Note that your game's "play time" is also measured in game-seconds, not real seconds (for example, increasing game.speed will make your play time advance more quickly).

Outside of debug timing info and frame/update rate measurements, the game is not aware of wall clock time. There is nothing you can do to measure real time, nor would you ever want to, since it doesn't correspond to anything in the game.

Prior to 0.12.31 there was a bug when inserting onto splitters which you may have been running into. Since then it makes a lot more sense. See my images here for the way it used to work and the way it works now.

That's interesting, it never occured to me (I'm pretty sure I've used the splitter-bus before 0.12.31, the author of the cheat sheet that suggested it certainly has, because the cheat sheet is over 6 months old).

The old behaviour was only a problem when your splitter-bus was longer than 9 tiles (for a blue belt), because 9 inserters are just barely enough to fill one side of the belt. Since I've only used this to unload trains, where the bus is never longer than 7-8 tiles, it didn't really matter that I could only compress one lane due to the bug.

Yeah it also depended on the direction your belts were moving. If your "bus" belts were moving south or east, and you were inserting onto the sides of splitters, it worked fine. Since that's not an unusual setup (people seem to like assembling things left-to-right I think, or something), the old behavior worked fine in a lot of cases. If your belts were going north or west, then it got weird.