Factorio Forums

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.

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.

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

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

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

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

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:

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?
Also not sure about miners. But I think they should NOT compress.

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!

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.

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

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.

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

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.

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

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

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.

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.

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.

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.