Friday Facts #276 - Belt item spacing & Script rendering

Regular reports on Factorio development.
Post Reply
User avatar
raiguard
Factorio Staff
Factorio Staff
Posts: 449
Joined: Wed Dec 13, 2017 8:29 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by raiguard »

J-H wrote: ↑
Fri Jan 04, 2019 6:55 pm
Train signals also need fixing.
What are you talking about? Signals work perfectly fine. What needs fixing?
Don't forget, you're here forever.

James K
Burner Inserter
Burner Inserter
Posts: 5
Joined: Thu Jan 11, 2018 9:51 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by James K »

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.
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
Inserter
Inserter
Posts: 30
Joined: Fri Jul 01, 2016 2:03 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

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

User avatar
QGamer
Fast Inserter
Fast Inserter
Posts: 213
Joined: Fri Apr 14, 2017 9:27 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by 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. :)
"Adam fell that men might be; and men are, that they might have joy."

Koub
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by 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.
Koub - Please consider English is not my native language.

nog
Inserter
Inserter
Posts: 32
Joined: Wed Mar 04, 2015 12:13 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by nog »

Klonan wrote: ↑
Fri Jan 04, 2019 3:02 pm
"Rebalancing belt throughput to 2^n"
Love it so much, as most of OCD obsessed. :)
Klonan wrote: ↑
Fri Jan 04, 2019 3:02 pm
"Hitbox reason"
I would never thought it was this reason.
Last edited by nog on Fri Jan 04, 2019 8:42 pm, edited 2 times in total.

dee-
Filter Inserter
Filter Inserter
Posts: 414
Joined: Mon Jan 19, 2015 9:21 am
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by dee- »

Allaizn wrote: ↑
Fri Jan 04, 2019 6:40 pm
dee- wrote: ↑
Fri Jan 04, 2019 6:11 pm
Zavian wrote: ↑
Fri Jan 04, 2019 4:37 pm
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.
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
Long Handed Inserter
Long Handed Inserter
Posts: 79
Joined: Mon Aug 03, 2015 5:46 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by miturion »

TearOfTheStar wrote: ↑
Fri Jan 04, 2019 3:31 pm
Just imagine the mix of Factorio and Tiberian Sun... :!:
Look for the AAI mods https://mods.factorio.com/user/Earendel

pleegwat
Filter Inserter
Filter Inserter
Posts: 255
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by pleegwat »

dee- wrote: ↑
Fri Jan 04, 2019 8:38 pm
"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
Fast Inserter
Fast Inserter
Posts: 225
Joined: Sat Nov 21, 2015 1:40 am
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by Nidan »

pleegwat wrote: ↑
Fri Jan 04, 2019 9:19 pm
dee- wrote: ↑
Fri Jan 04, 2019 8:38 pm
"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
Fast Inserter
Fast Inserter
Posts: 149
Joined: Tue Oct 02, 2018 5:44 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by 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
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sat Sep 22, 2018 10:29 am
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by 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
Inserter
Inserter
Posts: 26
Joined: Tue May 15, 2018 8:40 pm

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by 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
Long Handed Inserter
Long Handed Inserter
Posts: 59
Joined: Sat Mar 24, 2018 8:19 am
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by weaknespase »

dee- wrote: ↑
Fri Jan 04, 2019 8:38 pm
...

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

Image

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?
Last edited by weaknespase on Sat Jan 05, 2019 8:26 am, edited 1 time in total.

SamuelCombrinck
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sun Apr 02, 2017 9:35 am
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by SamuelCombrinck »

For everyone interested in measuring Belt Throughput, I hope this helps
beltThroughput.PNG
beltThroughput.PNG (210.28 KiB) Viewed 6739 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) :D

Edit: turns out there are better ways of doing it
newThroughput.PNG
newThroughput.PNG (129.1 KiB) Viewed 6639 times


The new setup outputs items per second, and can take input from multiple belts.
Last edited by SamuelCombrinck on Sat Jan 05, 2019 12:10 pm, edited 1 time in total.

J-H
Long Handed Inserter
Long Handed Inserter
Posts: 69
Joined: Fri Apr 21, 2017 11:48 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by J-H »

Raiguard wrote: ↑
Fri Jan 04, 2019 8:18 pm
J-H wrote: ↑
Fri Jan 04, 2019 6:55 pm
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

User avatar
dog80
Filter Inserter
Filter Inserter
Posts: 278
Joined: Thu Dec 08, 2016 11:57 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by dog80 »

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

User avatar
H8UL
Fast Inserter
Fast Inserter
Posts: 114
Joined: Mon May 15, 2017 4:02 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by H8UL »

J-H wrote: ↑
Sat Jan 05, 2019 12:41 am
Raiguard wrote: ↑
Fri Jan 04, 2019 8:18 pm
J-H wrote: ↑
Fri Jan 04, 2019 6:55 pm
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.
Shameless mod plugging: Ribbon Maze

sparr
Smart Inserter
Smart Inserter
Posts: 1327
Joined: Fri Feb 14, 2014 5:52 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by sparr »

SpiffyTriffid wrote: ↑
Fri Jan 04, 2019 11:32 pm
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
Smart Inserter
Smart Inserter
Posts: 1327
Joined: Fri Feb 14, 2014 5:52 pm
Contact:

Re: Friday Facts #276 - Belt item spacing & Script rendering

Post by sparr »

Burninator wrote: ↑
Fri Jan 04, 2019 10:45 pm
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.

Post Reply

Return to β€œNews”