Friday Facts #276 - Belt item spacing & Script rendering

[bayoublue]

Changes look great.
Can't wait to play them.

Looking through the comments from the last couple posts, I feel I must be strange. I have well over a thousand hours in the game, have done everything from a 1K SPM base to a winning SeaBlock, prefer to use belts for most of the game, but I have never cared about getting my ratios perfect.
For me, it is more fun to just eyeball things, add and upgrade belts and inserters when needed, and when that does not work find ways to spaghetti my way forward.

[Allaizn]

The point isn't that it's possible with pulse mode, but that this change removes a possibility that was there before.
Deciding on full throughput is much easier than trying to count the pulses for 32 ticks, see my other answer

While it might make an old method of detecting throughput obsolete, it makes detecting full belts so much easier. Additionally, the fact that full throughput on a yellow and red belt is now also integer means that detecting if there is full throughput on those much more doable.

Detecting full throughput of yellow was a pure integer affair, since their item timing was 9 ticks. Red belts were indeed a little awkward with 4.5, but it was managable to work with halfes even though it sometimes doubled stuff needed. This change basically switched the roles of blue and red, where before red was tricky and blue nice, while now red is nice, but blue is not - and I heavily favor the highend item being better than the lowend one.
Detecting throughput is also usually more useful than detecting how full it is, but even disregarding this, you still merely exchanged one setup being easy for another - while breaking a ton of other stuff, which warrants restistance to this change on my part.

[dee-]

Yes it is, if the value is a constant 8 it's full througput, if thoughput isn't full than it will fall to 7 or below.

No that is detecting that the belt is full. That says nothing about throughput on the belt. Admittedly I've never needed to measure throughput as such, so I'm not sure when it would be useful.

Well, split the belt into two belts and read one of them
If it's 4, then the belt is on full throughput
If it's <4 then the source is starving
if it's >4 then the destination can't consume as fast as items come in

After that join them again into a single belt:

Code: Select all

   >=(read)=>
===>========>===

[Allaizn]

I also wonder if this build will still work

3 stack inserters per blue belt loading

Code: Select all

0eNrlWduOozgQ/Rc/Q2SbcEk0O78w0u6+rUbIAXdiDRhkTGuyLf59bTyh08EkBnp7RpqnbrCpy6k6VRX7BRyKltaCcQn2L4BlFW/A/p8X0LAjJ4V+J881BXvAJC2BBzgp9RP9XgvaNL4UhDd1JaR/oIUEnQcYz+l3sEed91CIIKy4+gR3Xz1AuWSSUWNE/3BOeVseqFAyhy8Zf2JcLfnZiTZSSayrRn1Wca1LifKDTeiBs/on3oS9BrM/baiUjB8bvU/QsnqmaavWCkkFzVNtnlp6IkVDPWBeG0subhc0k6LiLPMzJrKWad1Z1Wr0MIQeKKtc7yPSLyjpLRvw+NppSG5cwo8QveNa2LuWM6Fs6te3FgXBSEGpkCgqklPhM95QoXy8pyUaafGAgk0IltO0kST7ljbsX9pHJxdVnd5IghtsJMEN2u0wSmItr2bZt3a816iEmwTCOEE4tEG2XQFZ4AJZuELB1oKW4pTKmSI90BN5ZpXQH/3InpRycihomrNG/x1S77IsKMnTE+F5qoUoO1U2StFe7bi8N1tN+sGuV8qNDX2uI5Pw+TWtmHqKdFpaMIgGDHRFkIRLP6vKA+NEVrZ0gZMAYDsA1+QalYlnJmSr3gxGmB3+36Ab6IbeUMvZ4fDKWf0cv0KpH9EEHvFgSk4zprlzDw48D4sfInUsczZ48MREI9O52JhgqQBC/VTWRPQm7sEn9UXVyrqdIZMqnp/lSRVMI7w+pz366ZOoypRxJczkYzcn4+4GAN8sI3QboJt1/GA9GAfYA3jCOMdsSEYVolWpKI5CgZM/rBHIUiMu/bGH1KJxN9LY1AWTE7Xb6MG2ym0yQDX8Sij5ugmz48mqEsH5dRBP+2jTgGaxaqgx2KnEfgir/ljAqi93yNTX/xlsiiez+ygo5bfb0c4twRGeFRn/FwhN+B6h+evnhQZHjqEJ5rWi/zEyNz8JxrPxmwBtfxfurBhQoVPZDBc0A7iyGUTznUKznIqXd5uRAmxTkCz3wHdzYTeLmQM8H1cyv7xlJHoHQv65lJB2jqEH02Bwu/4+RRXDNRMdnh7oDJw2RmG0vEwgl4THeHnCY5d8x8ES0PAq0LbLfXIaSXG4xqclkz2OFg3BHzho9UNRQ7WM2XXhqrp8/snz2G0t6I8b7VUIP6hCu8kq5KAXTerFyVR5iucdx9zj2LsdxmwnDmO8GTKgVQaeOCt97eBNSYrCL0hZTztvyHjv8G1gxVJSvLZSOEr2WX3Pkpv2RHgdMfqjV5cTXH0KZTsYXtXyRgepkUP1DpC79eiB9dhdFH4galEbQ6uA2K7pMstUhleACaLnfL+/fxnr2fZaoscTRhA5y8TOMmNXmdBZZOJ8b3SBOFxwa2TO5dddGpWVw51RsJvtT/Qr+7OFzlxGb/y5poBuqv15xP7qRtMDz8p2syGJMU7QDsa46/4DMpTPtw==

This design will not work anymore if your goal is to empty the belt fully without it stuttering. The required throughput per inserter would be 15 item/sec, or 4 ticks/ item which results in 48 ticks/swing. An inserter swing takes 26 ticks, which leaves 22 for picking up items. But the item timing is 8/3 ticks per item, or around 32 ticks. This calculation isn't entirely exact, since the inserter doesn't need to do a full swing and a few items will be buffered up already, but it's not enough to overcome that 10 tick gap.
As a comparision, 0.16 numbers were 13.33 item/sec/inserter or 4.5 ticks/item for a total of 54 ticks/swing. The spacing was 3 ticks/item which resulted in a race between 54 and 26+3*12=62 ticks, which was very barely closed by saving 2 ticks on not having to swing fully, and 6 ticks on 2 items being buffered.
The design barely worked, which is why it likely won't survive this change

[Bokkie]

Yes it is, if the value is a constant 8 it's full througput, if thoughput isn't full than it will fall to 7 or below.

No that is detecting that the belt is full. That says nothing about throughput on the belt. Admittedly I've never needed to measure throughput as such, so I'm not sure when it would be useful.

Well, split the belt into two belts and read one of them
If it's 4, then the belt is on full throughput
If it's <4 then the source is starving
if it's >4 then the destination can't consume as fast as items come in

After that join them again into a single belt:

Code: Select all

   >=(read)=>
===>========>===

Intelligent!

[DecJunkie]

https://xkcd.com/1172/
Nothing is impossible you just might have to change your thinking and you might find an easier way.

[Allaizn]

Yes it is, if the value is a constant 8 it's full througput, if thoughput isn't full than it will fall to 7 or below.

No that is detecting that the belt is full. That says nothing about throughput on the belt. Admittedly I've never needed to measure throughput as such, so I'm not sure when it would be useful.

Well, split the belt into two belts and read one of them
If it's 4, then the belt is on full throughput
If it's <4 then the source is starving
if it's >4 then the destination can't consume as fast as items come in

After that join them again into a single belt:

Code: Select all

   >=(read)=>
===>========>===

Breaks once it fills up, since there isn't enough output throughput to get rid of the excess that accumulated due to stutter.

[J-H]

How are you using the circuit system to read the belt like that?\
Every attempt I've made at using the circuits to do anything (like make a beep when a train arrives) has fallen flat on its face. We need a good tutorial, either in-game or written. (Video tutorials are a non-starter - I can read in 2 minutes what a video takes 10 minutes to explain).

Train signals also need fixing.

[Zavian]

I also wonder if this build will still work

3 stack inserters per blue belt loading

Code: Select all

0eNrlWduOozgQ/Rc/Q2SbcEk0O78w0u6+rUbIAXdiDRhkTGuyLf59bTyh08EkBnp7RpqnbrCpy6k6VRX7BRyKltaCcQn2L4BlFW/A/p8X0LAjJ4V+J881BXvAJC2BBzgp9RP9XgvaNL4UhDd1JaR/oIUEnQcYz+l3sEed91CIIKy4+gR3Xz1AuWSSUWNE/3BOeVseqFAyhy8Zf2JcLfnZiTZSSayrRn1Wca1LifKDTeiBs/on3oS9BrM/baiUjB8bvU/QsnqmaavWCkkFzVNtnlp6IkVDPWBeG0subhc0k6LiLPMzJrKWad1Z1Wr0MIQeKKtc7yPSLyjpLRvw+NppSG5cwo8QveNa2LuWM6Fs6te3FgXBSEGpkCgqklPhM95QoXy8pyUaafGAgk0IltO0kST7ljbsX9pHJxdVnd5IghtsJMEN2u0wSmItr2bZt3a816iEmwTCOEE4tEG2XQFZ4AJZuELB1oKW4pTKmSI90BN5ZpXQH/3InpRycihomrNG/x1S77IsKMnTE+F5qoUoO1U2StFe7bi8N1tN+sGuV8qNDX2uI5Pw+TWtmHqKdFpaMIgGDHRFkIRLP6vKA+NEVrZ0gZMAYDsA1+QalYlnJmSr3gxGmB3+36Ab6IbeUMvZ4fDKWf0cv0KpH9EEHvFgSk4zprlzDw48D4sfInUsczZ48MREI9O52JhgqQBC/VTWRPQm7sEn9UXVyrqdIZMqnp/lSRVMI7w+pz366ZOoypRxJczkYzcn4+4GAN8sI3QboJt1/GA9GAfYA3jCOMdsSEYVolWpKI5CgZM/rBHIUiMu/bGH1KJxN9LY1AWTE7Xb6MG2ym0yQDX8Sij5ugmz48mqEsH5dRBP+2jTgGaxaqgx2KnEfgir/ljAqi93yNTX/xlsiiez+ygo5bfb0c4twRGeFRn/FwhN+B6h+evnhQZHjqEJ5rWi/zEyNz8JxrPxmwBtfxfurBhQoVPZDBc0A7iyGUTznUKznIqXd5uRAmxTkCz3wHdzYTeLmQM8H1cyv7xlJHoHQv65lJB2jqEH02Bwu/4+RRXDNRMdnh7oDJw2RmG0vEwgl4THeHnCY5d8x8ES0PAq0LbLfXIaSXG4xqclkz2OFg3BHzho9UNRQ7WM2XXhqrp8/snz2G0t6I8b7VUIP6hCu8kq5KAXTerFyVR5iucdx9zj2LsdxmwnDmO8GTKgVQaeOCt97eBNSYrCL0hZTztvyHjv8G1gxVJSvLZSOEr2WX3Pkpv2RHgdMfqjV5cTXH0KZTsYXtXyRgepkUP1DpC79eiB9dhdFH4galEbQ6uA2K7pMstUhleACaLnfL+/fxnr2fZaoscTRhA5y8TOMmNXmdBZZOJ8b3SBOFxwa2TO5dddGpWVw51RsJvtT/Qr+7OFzlxGb/y5poBuqv15xP7qRtMDz8p2syGJMU7QDsa46/4DMpTPtw==

This design will not work anymore if your goal is to empty the belt fully without it stuttering. The required throughput per inserter would be 15 item/sec, or 4 ticks/ item which results in 48 ticks/swing. An inserter swing takes 26 ticks, which leaves 22 for picking up items. But the item timing is 8/3 ticks per item, or around 32 ticks. This calculation isn't entirely exact, since the inserter doesn't need to do a full swing and a few items will be buffered up already, but it's not enough to overcome that 10 tick gap.
As a comparision, 0.16 numbers were 13.33 item/sec/inserter or 4.5 ticks/item for a total of 54 ticks/swing. The spacing was 3 ticks/item which resulted in a race between 54 and 26+3*12=62 ticks, which was very barely closed by saving 2 ticks on not having to swing fully, and 6 ticks on 2 items being buffered.
The design barely worked, which is why it likely won't survive this change

Actually your definition of broken does not match my definition. Unless I'm missing something, that design will still function at least as well as it did in 0,16. If it was capable of loading 40 items per sec, it should still load at least 40 items per sec (perhaps even 41 or 42). So hardly broken, just no longer capable of handling a full blue belt. The same goes for most other blueprints that produce or consume a full blue belt. In general most should still work the same as before, and make the same number of items as before. It's just that they might need adjusting if you still want a full belt. The only things that I can think of that is likely to be broken is combinator setups reading belts and timed inserter swings interacting with belts. (Both things that won't affect most players).

[dog80]

this is another step into the right direction to enable more scripting functionality - awesome work bilka

[Allaizn]

Actually your definition of broken does not match my definition. Unless I'm missing something, that design will still function at least as well as it did in 0,16. If it was capable of loading 40 items per sec, it should still load at least 40 items per sec (perhaps even 41 or 42). So hardly broken, just no longer capable of handling a full blue belt. The same goes for most other blueprints that produce or consume a full blue belt. In general most should still work the same as before, and make the same number of items as before. It's just that they might need adjusting if you still want a full belt. The only things that I can think of that is likely to be broken is combinator setups reading belts and timed inserter swings interacting with belts. (Both things that won't affect most players).

Sure, but this change does IMO nothing good apart from fixing OCD with a few numbers. And you certainly don't think that the people bothered by those numbers will simply accept belt stuttering and decompressiong occuring everywhere, do you? I thus call these things broken, because they will need adjustment.
The argument that it won't affect many people is also rather weak: optimizing the game at this point will only meaningfully affect mega base builders which are a tiny minority, but the Devs still do those. And there are easily more people using circuitry than mega base builders.
Changes that break stuff need justification, for all definitions of "breaking" you could possibly use. The science changes broke a lot more stuff, but they were plentifully justified during it's introduction with it being far superior game design wise, so far so that it outweighed the obvious need for people to redo their bases. Changing belt speeds in comparision got explained by "we didn't like a number, so we changed it", which feels like they just did it without considering all the pros and cons of it and I don't like that at all.

[knightelite]

Yes it is, if the value is a constant 8 it's full througput, if thoughput isn't full than it will fall to 7 or below.

No that is detecting that the belt is full. That says nothing about throughput on the belt. Admittedly I've never needed to measure throughput as such, so I'm not sure when it would be useful.

Well, split the belt into two belts and read one of them
If it's 4, then the belt is on full throughput
If it's <4 then the source is starving
if it's >4 then the destination can't consume as fast as items come in

After that join them again into a single belt:

Code: Select all

   >=(read)=>
===>========>===

Breaks once it fills up, since there isn't enough output throughput to get rid of the excess that accumulated due to stutter.

I think you could fix that somehow by putting a controlled belt segment to stop input into the measurement device once it became full, with a priority splitter on the ouptut to drain the measurement block with higher priority. Maybe some other way using multiple splitters with priority would also work, but I don't have the game available to me to try it right now.

[Allaizn]

Breaks once it fills up, since there isn't enough output throughput to get rid of the excess that accumulated due to stutter.

I think you could fix that somehow by putting a controlled belt segment to stop input into the measurement device once it became full, with a priority splitter on the ouptut to drain the measurement block with higher priority. Maybe some other way using multiple splitters with priority would also work, but I don't have the game available to me to try it right now.

At which point it's again bigger than the current solution This setup was literally the first thing I thought of, and I'm quite sure that there are multiple others that became more complex or impossible. One could argue that it's no wonder that none is able to show a better design in the new version since none had much time to think about it, but I object to that with saying that whoever thought of implementing the change should have thought of that in the first place, solved it and showed that in the FFF, instead of the useless belt "fullness" reading.

[DaveMcW]

you will have trouble finding the correct blueprint on the sharing sites

That's not a bug, it's a feature.

[Selvek]

As much as I'd like the furnace speed change (since faster furnaces mean less furnaces for the same throughput), I don't like the belt speed change at all.
As someone who is heavily using circuits I also see nearly no benefit of getting a constant amount of items per belt piece on fully compressed belts - how would that help with anything?
Trying to detect full throughput with read mode is now completely impossible, since you will never notice stutter in a constant value - whereas before you could look at the fluctuations and decide upon those (not pretty but possible).
Detecting full throughput with pulse mode is still possible, but the non-integer spacing between item pulses for blue belts will make it a lot harder to get a robust system going. The old system had this problem for red belts, which wasn't ideal, but I'd argue that it's plainly bad to ruin the niceness of the highest tier item.
I don't see how one could argue that this spacing is better for circuits than the old one, since I don't see circuits getting any easier, which in turn doesn't warrant breaking all old designs that related to the current state.
Note that now all the inserter/belt interactions will also have practically completely different timings, and you'd thus need to redo everything using those, too.
The few blueprints unaffected by the science changes, like smelters or circuits, will now also be broken in the sense that they can't consume their input fully and can't compress their output anymore. This isn't too hard to fix, but it means that you will have trouble finding the correct blueprint on the sharing sites, since the majority of blueprints will be of old designs (and I wouldn't be surprised to see absolutely none taking the effort to update their shared blueprints).

So what's up with this change? It makes a whole 3 numbers a tiny bit nicer, and powercreeps belts for no reason, while wrecking havoc on almost every existing thing using belts, which is an insanely bad tradeoff IMO.

Edit: oh, and I completely forgot that almost all mods will now need updating if they every cared about a nice factory/belt ratio, which is a further downside

Not sure how this qualifies as "wreaking havoc on almost every existing thing using belts". Sure, your perfectly balanced setup will now produce exactly 40 items/sec on a belt that can carry 45, but it's not broken... it's doing everything it did before, the only thing that's broken is an OCD sense of perfectly filling every belt (which I share, but...)

Also, if you have some circuit setups that depend on calculating whether a belt is perfectly compressed or not which will *actually* break when belt capacity increases, would you share them? I have trouble envisioning what kind of setup that could be. (Obviously any circuit which counts belt items in "hold" mode will produce somewhat different results, but I'm curious what setups the change actually breaks.)

[DaemosDaen]

Woot love the belt changes. Most of my belt builds are insulated in the fact that they are not designed for late game. My belt based-beaconed smelters on the other hand... They get re-designed. For that I am glad. (no sarcasm) That's the whole point of this game.

I also wonder what will come out of the script drawing talked about in the second part. but I dunno.

[Mike5000]

Good changes reported in this FFF.

Thank you.

As the smelting recipe change, I am proposing the following:
- Iron plate, copper plate, stone brick: 3.2
- Steel: 16

That would mean exactly 48 stone furnaces per yellow belt, which is the number that people already build, but some of the last ones flicker with inactivity in 0.16, now all of them would work nonstop.

With the possible exception of direct insertion, exact ratios are way overhyped. Exact ratios take forever to saturate belts. And unsaturated belts cost UPS. It's much better to always have a little overproduction and back-pressure.

In any event, mining and smelting are by far the most boring parts of the game. (And unrealistically predominant compared to manufacturing - although realism is not a priority in this game.)

I could happily see basic 0.17 miners and smelters made twice as fast as 0.16, and with two or three new tiers each double the speed of the previous tier.

[sparr]

Will the capacity of underground belts be changing to match?

What does the capacity of the inside and outside lanes of a belt corner look like now?

[PaszaVonPomiot]

I really like the changes

[5thHorseman]

I like it.

Sure it breaks some eggs, but fixes more. No solution will make every single build better.