Friday Facts #221 - 0.16 is out

[StoneLegion]

I'm fat and you did not have fat man sizes!

[thecatlover1996]

As for the chest situation, I would advocate for 4 types of chests: (Active/Passive) (Provider/Requester) chests.

I like that idea, then buffer chests could be a combination between active requester and passive provider chests

[ssilk]

When I started with Factorio 4 years ago, belts had been core-feature! They where so complex. You built belts and thought "WTF????"
But some moments later you looked more exactly, zooming in and then you though "Ahhhhh, that is possible, too! Nice. I could use that for....". That was, cause the belts behaved like real physics.

So, yes: Complex in not such a good way.
That behavior had been changed in 0.16 (or was it 0.15?) or so into a good way so that it reduces that complexity a lot to only some WTF moments.
Not perfect yet. But there was still this thinking of "This should behave like real physics - more or less". And I think they do this job really well.

Now devs want to change the behavior for compression, inserting with inserters into full belts, when I understand it correctly. I think when implemented an inserter behaves more or less as a splitter (used as joiner, one side is the belt, the other the inserter). Similar techniques with side-loading.

EDIT:
After reading along I thought "What the heck, how long did it take me to do that kind of puzzle in my last game, and how long did I play? Simple answer: Too long.
So I changed my mind in this way:

There should be a research: "Insert without gaps". After researching that the inserters and side-inserts will insert into the belts without gaps.


Before that research they should behave like so:


- Inserters *could* be able to insert into a belt, if there is a gap, that is as big as the item or maybe a little bit smaller. Maybe half the size of an item. Or less. But not zero.
This behavior is good enough for normal players, but if you want to use 100% of a belt you need very different techniques. I still like that part of the gameplay a lot, it is a neverending search for an optimal solution.

- Similar to that is the side-insertion.

So: Filling up more gaps I would say yes, but not making a belt fully compressed just by inserters. That is a 90% solution, but to fit for the remaining 10% is a big struggle. That is also not the game target (puzzling) to make it that way. Would be wrong game direction. IMHO of course.


And what the belts are missing is a graphical feedback, of how to use them and not to make them so simple that you can put items onto everything.

[ThorsDragon]

You guys are amazing!! Nice work on the t-shirts!! I LOVE FACTORIO!

[kane.nexus]

tl;dr +1 vote for inserter compression

I feel that inserters should be able to drop onto belts to allow for best possible compression because new players wouldn't understand why the inserters aren't filling up the belts and could possibly get frustrated before understanding the combined operation of the splitter. The reason I say combined operation in regards to splitters is because the name only implies the ability of taking an input and making it two outputs and not the reverse. Seeing as there are already combinators in the game for the wired math and deciding, changing the name of the splitter wouldn't work. To me having the inserter perform its namesake function with priority onto the belt is the most intuitive operation for the inserter.

[rolfl]

For compression, I like the idea of "priority Inserters", which "block" the incoming lane and insert the item(s) before unblocking the lane. i.e. it always inserts "before" the next item on the belt, instead of waiting for a big enough gap "after" the next items.

I can see this as being:

- a new type of inserter
- a feature of stack inserters
- a 'toggle' of an inserter (like the item-count is a feature) - including circuit-network selectable.

My preference would be a new type of inserter that extends the stack inserter.... make it black.

[Engimage]

I am a fan of the belts. I do consider bots just waaay too cheaty and simple.
Even in 0.15 state almost everyone tried their best to get to bots to switch to them completely and forget the trouble with belts.
Nerfing belts is a really bad idea as a whole. So I would not do that if posible.

Regarding changes themselves.
I am totally fine with removal of underground belt compression. It was really unintuitive trick.
However sideloading was so extensively used that I for example just refused to play 0.16 until it will be fixed. Not only compression - lane balancers, priority injectors etc - all are based off sideloading.

Regarding inserters - I have created a proposal to use them for belt compression. I think that belt compression is not something worth extra design. Seeing how belts are inferior to bots I would personally love to see the simplification in compression. I can tell that many players don't even understand what compression is. And these holes between items on belts do only confuse people.

Underground belts were used for compression because of lack of other means for it. Using splitters not only increases the build cost drastically but does increase space and other stuff. While splitters are kinda viable as a whole but I think simple things like smelting columns should stay simple.

[thatguyagain]

Thanks for all the great work you do to streamline and make this game as fantastic as it is!

I, like many others have mentioned, am not in favor of removing side loading compression. I've been playing the game for quite a long time now and to me the challenge of compressing belts has always felt like it was due to a bug or incomplete belt mechanics, not an actual feature. I can understand the philosophy behind it; if the inserters are placing things down on top they can't just jam things into spaces that are too small. However, if you consider real life logistics (perhaps think about the warehouse for the delivery service that will be handling your t-shirts ) items flowing on conveyors will compress when you merge them. They will find a way because they will have angles and corners and whatnot. The weight and force of the items on the side belt would be able to temporarily stop an item on the uncompressed belt, allowing for an item to fill the empty spot. I feel removing side loading is akin to stating that the objects on belts don't have such physics, and if that's the case you may as well remove the idea of underground belts stopping one lane of items. Splitters are wonderful tools but as others have said they can be convoluted and bulky. While it's nice to have big, neat factories there's something satisfying about trying to make compact setups and removing sideloading would require and additional 2 or more tile spaces for what feels like no reason based on real life mechanics.

[Vandroiy]

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"

I agree. Early compression also makes Anti's speedruns even more satisfying. But, as I tried to explain, it's also about late-game balance, especially an inline compression method once space, performance, aesthetics, and game balance vs bots become more relevant.

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.

I'm not sad about the underground belt specifically, but rather the total lack of inline compression in 0.16. Some expected that belts would be patched to behave like underground belts, not the other way around. That sounds a lot nicer.

Just before 0.16 was released, I had designed a beaconed green circuit factory that pretty much exhausts belt/tunnel space for in- and outputs, reasonably compressed. This kind of layout is way too dense to fit extra structures just for compression. I haven't gotten to the point where I can test it in 0.16 yet, but if compression messes up the way I've seen elsewhere, the whole thing might go straight to the trash, possibly to be replaced by bots. (And before ever being used in a proper game. )

In any somewhat optimized layout for large factories, is splitter compression for outputs really an option? How does this even work? There are a gazillion constraints already in place. And even if it were to work somehow, there's the UPS cost. I just don't see how I'm supposed to do this, other than shrugging and accepting that belt factories got nerfed.

For compression, I like the idea of "priority Inserters", [...] ...make it black.

Oooh! Black Belt Tech!, with the priority stack inserter, and how about the deep underground express belt too! No problem if these are expensive, and the "black belt" pun is included in the package!

Whichever way this goes, please keep the belts beautiful and up to the challenge to the end! BELTERS! OPA! Err, y'know.

[MrGrim]

I think people are getting confused about the two cases of side loading.

1) Side loading should retain the "compression" of the incoming belt. If A fully compressed lane is being fed into the side of a new belt, then that compression should be retained. In my limited testing of 0.16 so far, this works just fine. All of my lane balancers and side loaders that depend on this are still working, so that seems fine to me.

2) Side loading a single item in 0.15 would sometimes "squeeze" into a slot too small for the item by pushing the entire belt lane back enough to fit. This is what doesn't work in 0.16. It also wasn't terribly reliable in 0.15. Getting it to work depended a lot on the specific lane being used in the side loading belt and its orientation in relation to the target belt, and even then depending on the exact configuration of items on the target belt it would never be "perfect".

Due to method 2 above and the inserting into underground belts not being 100% reliable and not generally producing perfect compression, I stuck with splitters all through the 0.12, 0.13, 0.14, and 0.15 versions. It always worked and was perfectly reliable. I honestly don't know why people used any other method. Using the merge feature of a splitter was also perfectly intuitive. If the combined throughput of the two incoming belts was >100% of a single belt, then a single output belt will always be 100%. Simple.

As for the buffer chest, it always seemed obvious to me that requesters would get priority. It's even in the name, "buffer" chest. It buffers.

EDIT: Oh ya, as for the idea of inserters being able to compress, that makes no sense to me at all. It's a dumb arm dropping an item onto a belt. If there's enough space for 1.3 items and an inserter drops an item there, than that .3 space left is lost. Let the splitter merge further down the lane compact those errors, or maybe try one of those super fancy perfectly timed inserter circuit systems.

[Avezo]

- a new type of inserter

Please no, there is too many of them already IMO, I would much rather have few basic ones with options to be used as filters and such.

[TheRaph]

I'm not much experienced with logistic network ... I'm just learning.
But as far as I see, the problem with buffer chest is very similar to the problem I have in general with passiv provider chests.
I have learned that passive provider chests are the last ones in order to pick things up. But that is not as the name says.

I think an storage chest should do what it's name says : Store things until needed. So the bots should pick items there at least.

Passive provider chests should also do what it's name says: provide things but not active - therefore bots should pick up needet things first from this chests because they provide it and at least from storage.

Active provider and requester chests work as expected.

Now if buffer chest would filled after requester chests and on the other hand provides passive as described above it may solve half of the issue.
But then the may also have an action radius to work for to prevent loop backs.

[Doomquill]

Please just make sideloading fully compress onto a side of the belt, and make inserters fully compress belts without gimmicks and splitters. Having to use a splitter or underground belt or any other shenanigans to achieve full belt compression has always seemed insane to me.

[jonatkins]

Buffer chests: requesters have priority, always - as others have said. That's the only way I thought it would work from the description.

Belt compression: something I've been thinking about suggesting for a while now - a "belt merger/compressor" entity.
* a 1x1 item
* Has three belt inputs and one belt output
* Can accept items from inserters or mining drills too
* It accepts items from all input sources at equal rates
* it outputs items on both lanes of the output belt evenly, and fully compressed if there's enough inputs

It could be placed on a belt to keep input lane usage balanced even when output lanes are unevenly used.

It could be used in front of each assembler/miner to compress and balance the belt lanes.

Costs would be similar to the existing splitter - it would come in yellow/red/blue speeds.

Thoughts?

[pib]

I would like inserter and side loading to both compress belts.

I think underground compression is a bit strange, only because inserters do not already compress on their own. If you allow inserters to compress, there is no question about the strangeness of underground belt compression.

If you consider robotic arms today, it seems that can already place an object onto a high speed belt with great precision. So why not allow them to do so in the game? It's probably good for balance reasons also, to allow for belts to remain a good option compared to bots in more situations.

[Ekelbatzen]

I just want to say that I feel kind of sorry for posting so many bugs and want to thank you all for your amazing work, so much dedication when I see you guys responding in the middle of the night and making new patches so fast.

[Dragony]

I also can't play 0.16 because I am using belts only. I just don't like a screen full of hectic flies all the time. That would makes me nervous...

Let me make a suggestion how to solve this problem a completely different way and tell me what you think.

Right now you are all talking about belt compression. But I asked myself "what is the root of all problems"? If the items were not being placed on the belt in half-steps, we would not need to discuss on how and where to make place to shove something between them. So whats about the idea to place them in a way so that no half-steps appear anymore?

Pro: You would never have to shove some items apart to put a new one between them.
Contra: It might look less realistic.

What do you think?

I personally am a perfectionist. Thats a real problem. I am only satisfied when a) utilization is 100% and b) it doesnt look ugly. Splitters DO look ugly, especially when you have to use them in a way a normal human in a real-life factory never would do, like here: https://wiki.factorio.com/Balancers

[Froilen]

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.

100% is not a fun thing to do.
similar to how underground belts were needed for compression.
I was like: "whait... how? why?!?!. " when I figured out you needed undergrounds, and the way they worked seemed like a bug.

[IronCartographer]

Compression Sources

• Splitters: Naturally.
• Side-loading: While technically odd that incoming items from the side may or may not take priority (just enough to insert into gaps, but not enough to replace existing flow), I am very attached to this behavior. It has seemed like a very good feature/improvement ever since this announcement. Many designs rely on it, as it allows belt-sidedness swaps, and takes less space than splitter-merging not only because of the splitter but also maneuvering the belts through (into/out of) the splitter. Belts won't be the same without it side-loading compression.
• Underground insertion: This was silly and not even 100% effective (it gave priority, but not true compression). It can go.
• Inserters: No. Full belts block inserters from dropping items. Making inserters compress belts would require that they take priority over items already on the belt. It might be worth trying...for science...but it just seems wrong.

Not addressed in the FFF: Super-compression from rotation of a belt with incoming items. (Another, perhaps better example.) This bothers me and seems like an inevitably recurring source of confusion / "look at this!" behavior.

Suggested change: Corners always holding the same number of items as straight belt segments. This would cause constant minor overlap on the inside of the corner, which would be predictable, consistent behavior, rather than allowing items to stack on top of each other without limit.

[redl_l_lolf]

IMO i like some of the current/fixed bugs. Somethings are unintuitive (like underground belt compression)and are either stumbled on (if a new player)after many hours of play or learned while playing multiplayer from other players. I would argue there should be more unintuitive mechanics along with the straight in your face approach. To me It gives the gameplay mechanics some depth. When you discover a new way to use an item you didnt know existed it can breathe new life into the same o' scenario of setting up machines and layouts. You start sterilizing the belt compression, it removes that depth and character of the game. You keep walking down that path of "What you see is what you get" approach for intuitive sakes, we go down the path of the boring AAA title games that hold your hand every step of the way. Wheres the replay value in that. I love this game because the more you play and discover the characteristics(or bugs) of items, the more it changes your designs. Each time i play it feels like an evolution or sorts thats earned by either experience(real exp not exp points) or by interaction of others. That in itself is a great game mechanic. The game is straight forward enough for new players from beginning to end, why start nurfing characteristics of the game because its not intuitive for new players mean while taking away experience from others, we are not competing nor need to make it fair between new and experienced. I once read that minecraft inspired the devs to make this game. Keep in mind one of the main characters was derived from a bug and is now immortalized into the titles logo.

Again, IMO

Love the game you guys, keep it up!