I like that it also works evenly for steel furnaces on yellow belts, which some of us use. I'm not sure I'll still do it it in 0.17, when the upgrade planner makes transitioning to red belts easier, but maybe I will.V453000 wrote: βFri Jan 04, 2019 3:57 pm 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.
Friday Facts #276 - Belt item spacing & Script rendering
Re: Friday Facts #276 - Belt item spacing & Script rendering
Re: Friday Facts #276 - Belt item spacing & Script rendering
+1 for the belts buff and finally having integer throughput numbers.
Also like the new graphics API. Will it support sprite animations, so that the Oil Refinery flame animation could be fixed by a mod?
Also like the new graphics API. Will it support sprite animations, so that the Oil Refinery flame animation could be fixed by a mod?
Re: Friday Facts #276 - Belt item spacing & Script rendering
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.Trying to detect full throughput with read mode is now completely impossible
-
- Inserter
- Posts: 22
- Joined: Tue Jul 05, 2016 11:43 am
- Contact:
Re: Friday Facts #276 - Belt item spacing & Script rendering
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.
Re: Friday Facts #276 - Belt item spacing & Script rendering
Making it easier to calculate ratios and having more sensible belt speeds far outweighs extreme fringe cases like combinator measurement setups. A lot more people benefit from having numbers that make sense than the few people who use such devices
That some beaconed setups worked so nicely with consuming or outputting a full belt was probably a coincidence. Some setups have issues with outputting or consuming a compressed belt with this, but others can be easily adjusted by adding a machine or two.
Sacrificing some productivity in one or two machines to put in more speed modules is a solution when outputting a fully compressed belt is really needed. For example with plastics in 6 chem plants: swapping out one PM3 for one SM3 in two machines will bring the output to >90 items/s.
In other cases you maybe be able leave off some beacons to slow down a machine. For example 5 Blue Circuit assemblers with 12 beacons will consume 80 Green Circuits per second. Another one with just 8 beacons will consume 10
That some beaconed setups worked so nicely with consuming or outputting a full belt was probably a coincidence. Some setups have issues with outputting or consuming a compressed belt with this, but others can be easily adjusted by adding a machine or two.
Sacrificing some productivity in one or two machines to put in more speed modules is a solution when outputting a fully compressed belt is really needed. For example with plastics in 6 chem plants: swapping out one PM3 for one SM3 in two machines will bring the output to >90 items/s.
In other cases you maybe be able leave off some beacons to slow down a machine. For example 5 Blue Circuit assemblers with 12 beacons will consume 80 Green Circuits per second. Another one with just 8 beacons will consume 10
Last edited by Serenity on Fri Jan 04, 2019 6:31 pm, edited 5 times in total.
Re: Friday Facts #276 - Belt item spacing & Script rendering
Also? If it was up to me I would make belts always twice as strong as the previous level.V453000 wrote: βFri Jan 04, 2019 3:57 pm 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.
Because currently, we have: Yellow(15) +100% of Yellow(15) = Red(30) (AKA: Yellow(15) *2= Red(30)); Red(30) +50% of Red(15) = Blue(45).
Why not: Yellow(15) *2= Red(30), Red(30)*2 = Blue(60)???
It doesn't make sense and doesn't entice you to upgrade to Blue Express Belts because the speed upgrade is not worth it till you want to squeeze every bit of efficiency out of your factory. Newbies will incorrectly assume Blue is twice as strong as Red because Red was twice as strong as Yellow, D'uh?!
-
- Manual Inserter
- Posts: 2
- Joined: Fri Oct 26, 2018 4:06 pm
- Contact:
Re: Friday Facts #276 - Belt item spacing & Script rendering
awesome change as always
maybe make burner inserter a bit faster so they can keep up with yellow belts.
maybe make burner inserter a bit faster so they can keep up with yellow belts.
Re: Friday Facts #276 - Belt item spacing & Script rendering
It's currently possible using the following setup:Uristqwerty wrote: βFri Jan 04, 2019 4:23 pmWould watching for "read mode's been stable for at least X seconds AND has received a pulse in the last Y" be harder than trying to determine it from fluctuation alone at the old rate?
https://imgur.com/59yyTWW
This setup works with pulse mode and with read mode, and it works by simply summing the detected values from the previous three ticks, which is either 1 per lane for pulse mode, or 11 per lane for read mode. This makes for great versatility since you can hook up the same belt piece to a second network and configure it to either pulse or read corresponding to the need of that other one.
The new spacing makes this much more difficult:
- using pulse mode now needs at least a span of 8 ticks, which almost triples the combinator count
- using pulse & read mode like you suggested is also worse: first off it requires two belt pieces for measurement (which you don't always have available). The minimal setup would also need to have at least 4 combinators, 3 for to save the last three ticks of pulse signals, and one to decide on the constant signal - which means that you in total need 1 more combinator and 1 more belt connection. What's even worse is the fact that this probably won't be reliable, since you can have the 2 tick timing happening on one lane and thus mask a microstutter on the other lane -.-
Last edited by Allaizn on Fri Jan 04, 2019 5:59 pm, edited 1 time in total.
Re: Friday Facts #276 - Belt item spacing & Script rendering
It's a bit annoying, but red = 2 yellow and blue = 3 yellow. They take yellow belts as their base. Not the previous tier. You can also turn 3 red belts into 2 blues.
Blue belt is somewhat overrated anyways. Some people suddenly only use blue when they get it. Even when it's not really needed. You can do a lot with just red belts. Where blue really begins to shine is when you move to beacons and modules. And maybe large mines (even then a red belt can support ca. 50 drills)
Re: Friday Facts #276 - Belt item spacing & Script rendering
Express belt being faster (4x yellow belt) becomes visually too fast. We have already tried to do that earlier.
-
- Inserter
- Posts: 20
- Joined: Wed Apr 26, 2017 4:54 am
- Contact:
Re: Friday Facts #276 - Belt item spacing & Script rendering
Can I also propose modifying the heat exchanger to heat steam to 515 C? So that it makes 100 steam per second instead of 103.whatever, and turbines can still consume 60 steam per second, but produce 6 MW instead of 5.82, and also make nice 5:3 ratios with exchangers instead of 97:60?V453000 wrote: βFri Jan 04, 2019 3:57 pm 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.
Of course, it would be even nicer if the base number were 4 instead of 3, since you always have a multiple of 4 exchangers per reactor...
Re: Friday Facts #276 - Belt item spacing & Script rendering
it's not referring to a pixel on a screen, but a "pixel" in game's logic, 1/32th of a 'tile'.arrow in my gluteus wrote: βFri Jan 04, 2019 3:52 pmWhy? Aren't those pixel distances only valid for a zoom of 1.0 ? I assume it's more likely that a player is on a different zoom level and that those nice integer pixel distances are no longer integer.There is a visual requirement that belts only move integer number of pixels every tick, so that is 1/2/3 pixels for transport belt, fast belt, express belt respectively.
count pulses every 32 ticks, and if there's constant 8/16/24 the throughput is full?Allaizn wrote: βFri Jan 04, 2019 4:15 pm 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).
it makes an attribute of something that is one of the core elements of this game MUCH nicer, a reason may be that so it's a tiny bit harder to complain that robots are OP, and welcome to a development of a game.
Re: Friday Facts #276 - Belt item spacing & Script rendering
I would appreciate both of these changes.EntroperZero wrote: βFri Jan 04, 2019 5:06 pmCan I also propose modifying the heat exchanger to heat steam to 515 C? So that it makes 100 steam per second instead of 103.whatever, and turbines can still consume 60 steam per second, but produce 6 MW instead of 5.82, and also make nice 5:3 ratios with exchangers instead of 97:60?V453000 wrote: βFri Jan 04, 2019 3:57 pm 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.
Thanks for the FFF, looking forward to see what this buff will do to change my setups.
The sprite rendering was something that I'd always hoped would be released, and now it's here!
I was secretly hoping for a release date this week. Oh well, we'll see next week ^^
My mods: Red Alert Harvesters - Clean Pipes - Filtered Splitters
Re: Friday Facts #276 - Belt item spacing & Script rendering
is an additional boiler tweak planned (apart from fuel efficiency) ? If I understand correctly, 1 full belt of coal will feed 33.33 boilers in 0.17.
Re: Friday Facts #276 - Belt item spacing & Script rendering
The point isn't that it's possible with pulse mode, but that this change removes a possibility that was there before.Shingen wrote: βFri Jan 04, 2019 5:22 pmcount pulses every 32 ticks, and if there's constant 8/16/24 the throughput is full?Allaizn wrote: βFri Jan 04, 2019 4:15 pm 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).
Deciding on full throughput is much easier than trying to count the pulses for 32 ticks, see my other answer
Re: Friday Facts #276 - Belt item spacing & Script rendering
Change to belts sounds awesome.
I'm curious what effect this will have to the behavior of inserters grabbing things from belts when they are "too spaced out" for the inserter to grab.
Will this possibly make the issue more common now that we have more spacing, or could it perhaps reduce this issue?
Either way, I'm excited for this change.
I'm curious what effect this will have to the behavior of inserters grabbing things from belts when they are "too spaced out" for the inserter to grab.
Will this possibly make the issue more common now that we have more spacing, or could it perhaps reduce this issue?
Either way, I'm excited for this change.
Re: Friday Facts #276 - Belt item spacing & Script rendering
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.Allaizn wrote: βFri Jan 04, 2019 5:33 pmThe point isn't that it's possible with pulse mode, but that this change removes a possibility that was there before.Shingen wrote: βFri Jan 04, 2019 5:22 pmcount pulses every 32 ticks, and if there's constant 8/16/24 the throughput is full?Allaizn wrote: βFri Jan 04, 2019 4:15 pm 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).
Deciding on full throughput is much easier than trying to count the pulses for 32 ticks, see my other answer
My mods: Red Alert Harvesters - Clean Pipes - Filtered Splitters
Re: Friday Facts #276 - Belt item spacing & Script rendering
Make sure to adjust stack inserters to new belt speed too! I'd be sad if compressing full blue belt with 4 stack inserters become complicated due to higher belt speed.
Also, since with this change items can have fixed 'spots' on the belt, I think it would be a good idea to revisit 'stacker belts' concept.
Also, since with this change items can have fixed 'spots' on the belt, I think it would be a good idea to revisit 'stacker belts' concept.
Re: Friday Facts #276 - Belt item spacing & Script rendering
I also wonder if this build will still work
3 stack inserters per blue belt loading