Friday Facts #221 - 0.16 is out

Regular reports on Factorio development.

vedrit
Filter Inserter
Filter Inserter
Posts: 293
Joined: Sun Aug 03, 2014 2:25 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by vedrit »

Why yes, yes it is.
Really liking the update - except for the graphical changes to concrete.
Also, there are some modding changes that don't seem to have made it into the changelog, such as changing get_circuit_connector_sprites

I have to agree with the others in the office, in that sideloading should be able to fully compress a belt, assuming there are enough items on the incoming belt to fill the other belt.
Last edited by vedrit on Fri Dec 15, 2017 9:47 pm, edited 1 time in total.

Zeblote
Filter Inserter
Filter Inserter
Posts: 973
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by Zeblote »

Side loading and inserters should definitely compress belts! Otherwise you would have to put big, unnecessary splitter setups after everything that is supposed to handle a compressed belt of stuff. That wouldn't be an interesting mechanic, just annoying repetition once you figured it out.

noliVe
Filter Inserter
Filter Inserter
Posts: 327
Joined: Tue May 24, 2016 7:46 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by noliVe »

and i thought splitters causing lags so sideloading and compressed tunneling seemed good for me ;)

i wanted to see your face after 12 hours packaging the tshirts... send more pictures of you please

torham
Fast Inserter
Fast Inserter
Posts: 187
Joined: Sun May 25, 2014 1:40 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by torham »

+1 for inserters and side loading to compress belts.

With underground belt compressing out of the picture, this leaves us with just splitter compressing, which can be convoluted at times.

PS: not a big fan of that concrete texture. A minor issue. Everything else looks awesome.

batorfly
Long Handed Inserter
Long Handed Inserter
Posts: 55
Joined: Mon Oct 23, 2017 2:57 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by batorfly »

But but but bbbut, things and stuff...
it's getting better and better every fucking FFF and even minor update! HOW? Dev's just pamper us ( ͡° ͜ʖ ͡°), with this amount of goodies, just top notch stuff <3

User avatar
madpav3l
Long Handed Inserter
Long Handed Inserter
Posts: 81
Joined: Sat Oct 31, 2015 10:24 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by madpav3l »

I think side loading should compress belts but not inserters or the trick inserters/underground belts.

ili
Long Handed Inserter
Long Handed Inserter
Posts: 88
Joined: Thu Apr 14, 2016 6:19 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by ili »

So many bug fixes so fast it's amazing!

It's good that you removed using underground belts to compress belts, it felt cheaty to do it and it's unintuitive.
But I think side loading is a legitimate way to compress a belt

This is not cool and I don't like it:
Last edited by ili on Fri Dec 15, 2017 9:58 pm, edited 1 time in total.

chris13524
Fast Inserter
Fast Inserter
Posts: 207
Joined: Thu Jun 04, 2015 12:20 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by chris13524 »

Underground belts should NOT compress belts. (doesn't make sense)
Side loading belts SHOULD compress belts. (makes sense, they are being forced into there)
I'm not sure about inserters. On one hand it makes sense that they would compress it (in a similar fashion as side loading). But on the other hand, it seems a bit too easy. Perhaps only stack inserters can compress? Or maybe a research? :D
Also not sure about miners. But I think they should NOT compress.

User avatar
<NO_NAME>
Filter Inserter
Filter Inserter
Posts: 295
Joined: Tue Aug 02, 2016 9:52 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by <NO_NAME> »

I don't have opinion about side-loading but inserters should not compress belts. Don't tell me that I designed my complicated, splitter-filled furnace layout for nothing!
I am a translator. And what did you do for Factorio?
Check out my mod "Realistic Ores" and my other mods!

User avatar
riking
Long Handed Inserter
Long Handed Inserter
Posts: 54
Joined: Thu May 05, 2016 5:35 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by riking »

Give requester chests priority over buffer chests. This means, that nothing would go to buffer chest request unless that item is already satisfied for all requester chests
When I read the first buffer chest article, I thought this would be obvious. After all, the whole point of buffer chests as a logistic system component (as opposed to a construction system component) was to avoid the requester-provider loops, so "of course" they would need to have lower priority than requester chests!

Now that I think about it, the "providing priority" also seems unintuitive...

1. Definitions
A "trash action" is generated by the player trash slots, active provider chests, and deconstruction orders.
An item is "provided to the network" when it is sitting in a passive provider, buffer, or storage chest; or it is the subject of a trash action with no assigned robot.
An item is "requested" by construction orders, player logistic requests, requester chests, and buffer chests.
An item request is "standing" if there is no material available to satisfy the request. This is represented in the logistic network contents as a 0 or a negative quantity, depending on TODO.
An item is "newly provided" when it becomes provided to the network while there is a standing request for the item.

It seems like the best priority order when an item is requested would be
(1) Trash actions
(2) Storage
(3) Passive or Buffer, based on distance (Buffer chests are ineligible for fulfilling requests generated by buffer chests)

(Note: some people are arguing passive & buffer being given equal priority.)

The best priority for newly provided items would be
(1) Construction / Player
(2) Requesters, allocated by request amount (current behavior, I think)
(3) Buffer (Only when not provided by a buffer chest)
(4) Storage (Only when item being trashed, and not provided by a buffer chest)

So buffer chests only receive materials if all other requests are satisfied (counting in-flight materials as already being in the chest).

Edit: Missed a "not" there, hah.
Last edited by riking on Sat Dec 16, 2017 5:38 am, edited 7 times in total.

User avatar
thecatlover1996
Long Handed Inserter
Long Handed Inserter
Posts: 59
Joined: Sun Sep 18, 2016 12:50 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by thecatlover1996 »

The FFF are truly great, they answered my biggest two questions about the 0.16 release today :D

My opinion on the buffer chests:
- To me, it seems intuitive to give requester chests higher priority than buffer chests. The contents of requester chests are mostly directly used in the assembly line, which sounds more important than filling a buffer. Also, a "buffer" in a more general context has the meaning of temporary overflow, so then the buffer should be filled only after the requester chests have been filled.
- To make the dedicated storage chests, I think it's better/easier to change the current storage chests. The current storage chests could have a little GUI to choose which items should be stored in them.

My opinion on the side-loading: I like making use of this bug, a lot. :lol:

Vandroiy
Burner Inserter
Burner Inserter
Posts: 18
Joined: Fri Dec 15, 2017 9:54 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by Vandroiy »

Belt compression is also about late-game balance!

This nerfing of belts, combined with the constant buffing of bots (and trains), is resulting in a late-game where flying things around competes with the throughput of a conveyor belt! It feels like on every hard belt problem, the game is telling me to give up and use bots already. They are easy to use, efficient enough, and don't invite the numerous kinds of troubles and constraints belt insertion brings.

And uncompressed belts are ugly! Not satisfying at all. Random splitters cost performance, are ugly too, and very often are impossible to place in beaconed factories without a serious downgrade of the layout.

Therefore, I side with auto-compression for inserters. Personally, I'd like late-game belt buffs on top, like an express deep underground belt (10 range, interleaves with express tunnels), or expensive load/unload tools, or any other way to keep late-game belts competitive.

(Sorry for being the guy who registers just to complain. There are lots of great changes in 0.16 that I feel don't need a mention 'cause everyone knows they're great! 8-) )
Last edited by Vandroiy on Fri Dec 15, 2017 10:34 pm, edited 3 times in total.

fiery_salmon
Fast Inserter
Fast Inserter
Posts: 128
Joined: Wed Dec 13, 2017 1:20 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by fiery_salmon »

Underground belt compression was unintuitive, but sideloading seemed to be obvious. Personally, I would keep sideloading and splitter compression and do not attempt to replicate underground compression bug.

Priority of requester over buffer seems quite obvious in hindsight, though I am not sure whatever I would notice it if I were implementing this feature.

Zeblote
Filter Inserter
Filter Inserter
Posts: 973
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by Zeblote »

<NO_NAME> wrote:I don't have opinion about side-loading but inserters should not compress belts. Don't tell me that I designed my complicated, splitter-filled furnace layout for nothing!
So just because you wasted time making something that should not be necessary, everyone else must do that aswell?

deef0000dragon1
Long Handed Inserter
Long Handed Inserter
Posts: 67
Joined: Fri Jan 02, 2015 11:46 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by deef0000dragon1 »

On Compression:
Imo, all forms of input onto a belt should compress IF there is enough space to push the rest of the items back within 1 or 2 belts. In this manner, you can deal with compression issues to something like 95% compression without needing a splitter, but complete compression would require it.

Also, question: Has the mod pack auto detect and install been implemented? I saw it in assigned and on the road-map, but not on the change log.

Relevent post:
viewtopic.php?f=66&t=49355

mh_
Inserter
Inserter
Posts: 45
Joined: Thu Dec 14, 2017 3:15 am
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by mh_ »

Sideloaders should be able to compress a belt somewhat: Loading one fully compressed double sided yellow belt to one side of a red belt should end up in a compressed one sided red belt. If this does not work, I consider it a bug.
Sideloading a half full belt where there are spaces for 100% of an item should work. Sideloading a belt where there are spaces for 90% of an item should not work. This means in essence that I think you should items considered to have square bounding boxes or something. This would also be the option that is not a total waste of computation time.

Inserters should NOT be able to compress a belt. What should happen to the items already on the belt? Ok, if there is like a space of 8 between each item on the belt you could just move one item. But that only gets discussion how many items can be moved etc. If you really want to do this the only viable option would be to try to push the items back as far as needed. This would end up in a problem of horrendous complexity. Also it would be totally counter intuitive. The only coherent option is to say: Items on a belt just stay at their position on the belt. No compression if not with backing up or splitters.

But if I could advise the devs, I would say: Do whatever hurts performance the least but is still as consistent as possible.

As for the chest situation, I would advocate for 4 types of chests: (Active/Passive) (Provider/Requester) chests.
Active providers try to get rid of the item (just as a trash slot of the player)
Passive providers offer to supply an item.
Active requester try to get an item, preferred from the active providers.
Passive requesters offer to take an item. If no item is specified as requested it would take all items, meaning it is the plain old storage chest.

The player takes the role of an active provider/requester.

Further I would allow linking two boxes with a circuit cable so that they share their contents thus forbidding transfer of items between the two. This way you could have a buffer chest. You cannot get around the problem of short term intermediate storage, at least not without implementing some minimal storage time or something, which would hurt performance.

User avatar
Brathahn
Fast Inserter
Fast Inserter
Posts: 128
Joined: Sat Aug 02, 2014 1:50 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by Brathahn »

Vandroiy wrote:Belt compression is also about late-game balance!
I beg to differ.
Compressing belts is a pretty early game issue. when you making your furnace lines and a bus you want "full belt in/full belt out"

Also aye for sideload compressing,
nay for inserter/underground compressing.
Last edited by Brathahn on Fri Dec 15, 2017 10:50 pm, edited 1 time in total.

wvlad
Fast Inserter
Fast Inserter
Posts: 215
Joined: Thu Jul 13, 2017 9:55 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by wvlad »

I expected belts to be compressed automatically with both inserters and side loading, I even didn't think that they could be "not compressed" until read about it. The belt compression is not intuitive mechanics, I imagine that noone actually designed it this way, it just happened that after implementing we got sometimes not fully compressed belts.
Last edited by wvlad on Fri Dec 15, 2017 10:52 pm, edited 2 times in total.

Avezo
Filter Inserter
Filter Inserter
Posts: 454
Joined: Fri Apr 01, 2016 3:53 pm
Contact:

Re: Friday Facts #221 - 0.16 is out

Post by Avezo »

Truth be told, it would be intuitive that inserters DO compress belts, the fact they don't seems counter-intuitive to me.

Also, using splitters as a 'mergers' seems yet another trick that belongs in the same category as earlier tricks like underground-compressing for me.

Post Reply

Return to “News”