Factorio Forums

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.

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.

+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?

Trying to detect full throughput with read mode is now completely impossible

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.

Tias wrote: ↑

Fri Jan 04, 2019 4:33 pm

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

How do you tell the difference between full throughput and a backed-up belt?

Tias wrote: ↑

Fri Jan 04, 2019 4:33 pm

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.

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

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.

Also? If it was up to me I would make belts always twice as strong as the previous level.

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?!

awesome change as always
maybe make burner inserter a bit faster so they can keep up with yellow belts.

Uristqwerty wrote: ↑

Fri Jan 04, 2019 4:23 pm

Allaizn wrote: ↑

Fri Jan 04, 2019 4:15 pm

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).

Would 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?

It's currently possible using the following setup:

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 -.-

Tomik wrote: ↑

Fri Jan 04, 2019 4:46 pm

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.

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)

Express belt being faster (4x yellow belt) becomes visually too fast. We have already tried to do that earlier.

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.

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?

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...

arrow in my gluteus wrote: ↑

Fri Jan 04, 2019 3:52 pm

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.

Why? 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.

it's not referring to a pixel on a screen, but a "pixel" in game's logic, 1/32th of a 'tile'.

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).

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

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.

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.

EntroperZero wrote: ↑

Fri Jan 04, 2019 5:06 pm

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.

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?

I would appreciate both of these changes.
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 ^^

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.

Shingen wrote: ↑

Fri Jan 04, 2019 5:22 pm

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).

count pulses every 32 ticks, and if there's constant 8/16/24 the throughput is full?

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

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.

Allaizn wrote: ↑

Fri Jan 04, 2019 5:33 pm

Shingen wrote: ↑

Fri Jan 04, 2019 5:22 pm

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).

count pulses every 32 ticks, and if there's constant 8/16/24 the throughput is full?

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.

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.

I also wonder if this build will still work