Friday Facts #276 - Belt item spacing & Script rendering

[raiguard]

Train signals also need fixing.

What are you talking about? Signals work perfectly fine. What needs fixing?

[James K]

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.

While you're reviewing things like that, can I suggest changing the steel-iron ratio from 5:1 to 4:1 (i.e. having steel take 12.8 seconds to craft, with 4 iron pates required)? Combing 5 belts into 1 is an awkward and difficult process, but 4 into 1 is very straightforward. I think this change would make steel a lot easier to get to grips with.

[zyklame]

Nice changes to the belts and the mod interface. Let's see what can modders do with these in 0.17

Can you anwer why your graphics have the wrong file extension?
The static image is obviusly an webp image, that is called png for some strage reason on the server.

[QGamer]

Wow, the new script rendering sounds AMAZING!
I don't know if I'll ever use it, but I'm sure so many others will love it.
Thank you.

[Koub]

Love the changes announced in the FFF
I'm more skeptical with tne intention to tweak the furnaces to produce perfect ratios regarding to belt throughput. I'm afraid this will be the first step in a "if you fixed the ratios for the furnaces, fix them for anything else that can be crafted", and "and now I can't make a ratio perfect build that's fully beaconed - or half beaconed, or whatever".
I wonder if it wouldn't be better for the game not to try to aim for a "perfect ratio build" like 48 furnaces per belt. I know I'm an OCD guy, like many people here, so believe me it's hard to ignore my deep pulses, but I don't think trying hard to make optimal ratios for things would be beneficial.

[nog]

"Rebalancing belt throughput to 2^n"

Love it so much, as most of OCD obsessed.

"Hitbox reason"

I would never thought it was this reason.

[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)=>
===>========>===

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

"Breaks" in the sense of detecing >4 when on full throughput for as long as the two splitted belts have not been emptied, so for about 2 seconds, after that the normal full belt throughput will again be split into 2* 1/2 full belt and detected as 2* 4 items on the belt

[miturion]

Just imagine the mix of Factorio and Tiberian Sun...

Look for the AAI mods https://mods.factorio.com/user/Earendel

[pleegwat]

"Breaks" in the sense of detecing >4 when on full throughput for as long as the two splitted belts have not been emptied, so for about 2 seconds, after that the normal full belt throughput will again be split into 2* 1/2 full belt and detected as 2* 4 items on the belt

Those bits can't empty as long as the input is saturated. There's not enough output capacity.

[Nidan]

"Breaks" in the sense of detecing >4 when on full throughput for as long as the two splitted belts have not been emptied, so for about 2 seconds, after that the normal full belt throughput will again be split into 2* 1/2 full belt and detected as 2* 4 items on the belt

Those bits can't empty as long as the input is saturated. There's not enough output capacity.

Stopping the input belt when reading more than 4 items solves that.

[Cadde]

I love it! The thing is, if you just ask one modder then you are only asking a tiny part of a minority of the player base.
Imagine how one little change can have an avalanche of modders using it once it's there.
If something can't be done then no-one will do it and few will care to ask for it. If it can be done then you will find that modders will exceed your expectations.

This is the same as what hackers do (the real kind, the friendly kind) who find uses for everyday objects that weren't imagined by their developers/engineers.

On the belt discussion and detecting running belts. Again, that's a hack you've been using. Why are you relying on an unintended side effect of there being gaps in belts when instead you should be asking for a "belt is moving items" signal? Or for that matter, an "average moved items/s" signal.

The same would apply to pipes. Connecting a single pipe to the circuit network should allow reading it's flow rate and/or it's current fill level.
In fact, i made 1x1 tanks instead just for this "fill level" issue in 0.16 so i could control splitting based on how much fluids there are.
One shouldn't have to do that IMHO.

[Burninator]

How much effort was required to change the spacing from 9 to 8? Since there is still a large imbalance between bots and belt throughput at the extreme end, and faster belts are "visually too fast", could a mod add some sort of belt compression research that reduced the spacing? Would it break anything with inserters with spacing at 4 for example?

Great changes on the belt numbers though. Not sure why people are bothered by previous designs no longer being perfect. Isn't the whole point of Factorio to design these setups in the first place?

[SpiffyTriffid]

0.17 seems to be breaking a lot of things for the sake of having a fat changelog, at least from the outside perspective. I could understand all of the upcoming changes if the upgrade to 0.17 introduced a new modding API and finally dropped the old one that was deprecated since 0.13, wouldn't let you import 0.16 blueprints due to using a new, cloud-based system, and was a switch from Unity to Unreal. Aside from that, I see no point in breaking features relied upon by a large section of the existing "powerusers" for the sake of OCD numbering or a nebulous "simple". The science changes are going to break things, but there are strong gameplay reasons to justify it. The pipe changes are very hotly debatable, but if the quirks of the new system (losing small resource count etc.) are outweighed by the massive parallelization bonuses then those are justifiable. If there are backend optimizations that have an actual and visible effect on UPS in megabase scenarios by using integer belt capacity or if there is some fundamental reason for the change due to an engine requirement, then that justifies the edits in my eyes but then please mention it in the blogs instead of having the players try and come up with the reason the edits were pushed through. Making the numbers round so that powerusers who are utilizing the circuit system "don't have flickering lights" and so that it's using "integer ratios instead of 'harder to calculate' fractional ratios" however, does nothing but break many existing systems in subtle ways. If this change was made to make some "irritatingly non-integer" numbers integer, a cost-benefit was done and decided breaking existing circuit, loader systems, spreadsheets, beaconed blueprints etc. was worth it? Then honestly I don't think the staff making that analysis should be retained in such a position for much longer; there is no justification or even excuse for such a faulty cost-benefit. Alternatively, if there are people who can't calculate ratios with fractions in them, and this belt change was designed to be the thing that lets them finally figure out how to calculate ratios, then respectfully I don't think we should be concerned about that part of the population at the cost of powerusers who *do* grok fifth grade math. I say this because the only people who are going to be calculating ratios based on belt throughput are the power users who are interested in optimizing the factory throughput instead of slapping down a higher tier belt when their single gear factory backs up. There is a wide range of user capacities in Factorio, and I agree that it should be made as accessible as possible, but when the accessibility to a system comes at the cost of losing inherent complexity from a system, that accessibility needs to be put on hold. It would be easier to use pipes if they acted like a multi-fluid net with infinite flow and capacity (i.e. electrical nets), and that would certainly optimize UPS and reduce cognitive load, but that would also remove a large amount of complexity inherent in the pipes. Some people may not consider non-integer throughput an "inherent complexity" but I believe that since that complexity has been present for a long period of the design process, and since there are literally dozens of common design paradigms that rely on this being true, I suggest that integer throughput be either added in as a mod, or that non-integer throughput be provided as a first-class, developer-supported mod. I'll be back later tomorrow to respond to any comments on this, and I hope that a productive conversation can be held between people relying on "legacy" features for their designs and the developers, not only for this but for future breaking changes. My dream is that before any breaking changes such as these are implemented, they are debated on the forums to allow the players who will be most impacted by them to decide whether or not they belong in the game, instead of being told "this is how they are, you can complain about it on the forums but we will not revert it since we've already put in the work." as has previously happened.

[weaknespase]

...

"Breaks" in the sense of detecing >4 when on full throughput for as long as the two splitted belts have not been emptied, so for about 2 seconds, after that the normal full belt throughput will again be split into 2* 1/2 full belt and detected as 2* 4 items on the belt

No, it won't recover if input is fully compressed. You can check it in game or just consider that this setup acts as buffer - in order to empty buffer output rate must be greater than input, but in the case of fully compressed input you can't go higher. So, after belt backs up you'll need to manually restart detector. This setup would work if output capacity is greater than input capacity, for example, by using blue belts as output and red as input.

Why not just use clocks and count throughput? Minus the clock you can build throughput computation circuit using only 4 combinators - it's versatile, reliable and requires only one belt in pulse mode to connect. Clock signal can be shared, this allows to multiplex signals from different meters over a single network (by reducing time each signal translated) and any number can be squeezed in by trading off latency.



You should concentrate on what new update brings new, instead of mulling over third rate hacks that would stop working. If that is so specific, why not ask devs to add throughput computation ability in the belt itself?

[SamuelCombrinck]

For everyone interested in measuring Belt Throughput, I hope this helps

beltThroughput.PNG (210.28 KiB) Viewed 7839 times

A signal output of...
<8 is a Supply shortage (<6 for pre 0.17)
=8 is a Full throughput (=7 sort-of works for pre 0.17)
>8 is a Backed up output

Signal output divided by belt capacity(8) gives throughput Percentage.
Percentage multiplied by belt speed gives throughput Items per second.

There is probably a better way of doing it, but this works for me (and does not get clogged)

Edit: turns out there are better ways of doing it

newThroughput.PNG (129.1 KiB) Viewed 7739 times

0eNrVWNuOmzAQ/ZXKjy1UQO6o/YB9aJ72rVohBybBEtjImKhRxL93DLsJyyXB2aSXlyAbz2F8zsx4nCPZJAVkknFF/CNhoeA58X8eSc52nCZ6Th0yID5hClJiEU5TPVKS8jwTUtkbSBQpLcJ4BL+I75bWVWMqmYpTUCy0Q5FuGKdKyAaGV75YBLhiikHtTTU4BLxINyDxIyco7a+iXDWBLJKJHG0F1x4gnj21yAEf6BuJmISwfudZ2lxJkQQbiOmeoS0abFmiQA6wsGdSFThzcqBeYT9r90NRaBrdBhkv1TTn9TdzjeTqHwlRc2MMRxNcyWRYMFUNtW2pyWzt3RvSoLvtWe+2pz2gkxNoBCGLQF7m0/s6M2H0FTPAdxE78bBlMleBKcO13MSfO3qUZlRWPvrkG1qIQmWFOWZ2CCrpgq0UacA4YhBfyQLK8eq5DVZ71PSqSPDGSv8ey3W6YH2hMTVT0fkHVfx+g4pPd1TR7SbhsGyzcRk7u1L4Osq4ZsKcUT+mTcVjDhpjvNFaG4kMUMDKR/LlBgURxECkaTsbrEuqeGYSvsdadLAsspMAvI0zb6esNy425icqUohYkdqQIAMSAyQTCXRDo3GS9bHV69tsXPVYmIbppPYFy0j52MBcNwLzXDts933gfX544LVFNQqtIdqXhhHw2sw4491eXTlOhmJzZdppOK1Goz8q3j4NnG4SCCKW6yfxtzTJ4eyZBBoFMa0lV+haXlfz84q3+XppKiIwomU5sG1Nj1kinPoh54/Wa6Bh3JsZd0iMJ6PEWJp0N+163Xfm9uri3tbeOP93j3rH7mZq2mZeFupy+evKetsJ6XpGsrt/XfXZ6g497fpxPe1wE2PUOS365EPk6qrvN/5WsEhC8djAuedYimIX4yY+/QC8Y+OrPd60K4Hmy4XnLd2Vs/DK8jfjQ7EC

Copy blueprint

The new setup outputs items per second, and can take input from multiple belts.

[J-H]

Train signals also need fixing.

What are you talking about? Signals work perfectly fine. What needs fixing?

"No Path" does not help locate where a problem is along a thousand-unit track with fifteen signal pairs. It takes a lot of guesswork and trial-and-error to fix "No Path." Very new/moderate player unfriendly. I am on my 25th factory and still struggle with this to the point where I had to ditch a nice organized "main bus" rail system for a bunch of parallel in and out lines.
See discussion here:
viewtopic.php?f=5&t=63414

[dog80]

why not add a "blurring" filter when belts are too fast ok xD

[H8UL]

Train signals also need fixing.

What are you talking about? Signals work perfectly fine. What needs fixing?

"No Path" does not help locate where a problem is along a thousand-unit track with fifteen signal pairs. It takes a lot of guesswork and trial-and-error to fix "No Path." Very new/moderate player unfriendly. I am on my 25th factory and still struggle with this to the point where I had to ditch a nice organized "main bus" rail system for a bunch of parallel in and out lines.
See discussion here:
viewtopic.php?f=5&t=63414

I agree it's not very friendly, but does seem off topic to the FFF.

[sparr]

0.17 seems to be breaking a lot of things for the sake of having a fat changelog

I think you would be happier starting to play at v1.0

[sparr]

How much effort was required to change the spacing from 9 to 8? Since there is still a large imbalance between bots and belt throughput at the extreme end, and faster belts are "visually too fast", could a mod add some sort of belt compression research that reduced the spacing? Would it break anything with inserters with spacing at 4 for example?

I happen to think that faster belts in Bobs and other mods are just fine. However, I love your idea, and I'll do you one better:

I want items to have a size-on-belts AND belts to have a compression ratio, so that bigger items take up a lot more belt space, but better belts can pack in more of everything.

8 pixels could be the norm for medium sized objects, all the way down to 4 or fewer pixels per item for the smallest components like wires, and then much higher, maybe 32+, for things like buildings and trains.