Friday Facts #221 - 0.16 is out

[Vandroiy]

(...) most inserters shouldn't automatically compress. Most. But STACK inserters should. They are expensive, resource intensive, and they way they work (dropping a constant stream of items onto a belt) really suggests that they should be able to fill those gaps. It's just good gameplay.

I feel strongly about compression.

Yes! That would be a good solution too. It would also make stack inserters useful in places where they weren't before.

In case it's not obvious, I feel strongly about compression too!


On a more general note, we've now had pro-compression arguments concerning:

• Newbies who get confused or frustrated (Why are there holes on my belt?)
• Powergamers who want to have rewarding gameplay in belt megafactories (UPS, size, throughput, game balance)
• Aesthetics, also for let's plays / speedruns (uncompressed or splitter spam look imperfect, not satisfying!)

A big point against having inserters compress seems to be that it's not realistic. Come on guys, we can fit whole buildings on these conveyor belts that don't need power... is a tiny difference in realism really relevant, compared to three of the most important aspects of a good game?

If a belt isn't really full, there should be a way to output onto it, without a need for extra space and contraptions.

[Engimage]

I'd love to see underground belts have their compression functionality back, or perhaps a separate item, a "belt compressor" -- perhaps a 1x1 or 1x2 belt-related item that would allow items to be fed in from the top by inserters, and it would compress the output, basically giving the same functionality as the old underground.

I have made a suggestion to fulfil this idea (a bit extended)
Belt buffer device

[Zavian]

Well from a realism point of view, if an inserter can somehow signal the piece of belt just upstream of the insertion point to pause for a few ticks, it can create a gap it can then insert something into. That section of the belt just upstream will also tend to compress whilst it is paused.

Personally I'm on the fence about inserters compressing, and undergrounds. I liked having an inline method of inserting onto a belt that was almost full. Many of my beaconed and moduled belt based layouts relied on inserting into underground belts. If you have assembly machines squeezed between 2 rows of beacons, it's often going to be a struggle to find room to try to compress belts with splitters. (Besides in earlier version splitters were computationally expensive. I'm not sure how how expensive they are in 0.16, but I expect they will still cost more cpu cycles than 2 pieces of belt).

It's also ugly. From an aesthetic point of view inserting into undergrounds gave a nice clean design. Trying to merge with splitters in between 2 rows of beacons is likely to be an ugly mess. Many of my existing layouts won't work without some way to compress belts. I have a nice belt based green circuit build that does 20 compressed belts of green circuits in 0.15 (48000/minute). It does 43500 in 0.16, because it's designed to output onto underground belts. Can I fix it? Well only in ways I an ugly mess with the current belt mechanics.

On the other hand, not all products need to be compressed when they are produced, Many of them are slow enough that you aren't going to get a full blue belt out of a reasonably sized layout of assemblers anyway. For things like that you can always merge 2 output belts afterwards anyway. For other products as long as your production exceeds your consumption, then belts will backup, which aesthetically is effectively a compressed belt.

I'm also concerned about sideloading. Assuming you have enough input, then sideloading onto an empty lane should be able to give close to full compression. I can live with occasional hiccups. (I consider sideloading onto a partially full lane to be a different matter. I've never assumed I can fully compress a lane that way). But some of the gifs and videos shared by other players show sideloading only achieving 50% of a lanes throughput, which is concerning. Also the order that belts are built seems to matter. I think it shouldn't. Players can't control the order bots build things, so we need designs to work regardless of build order.

[Hazzart]

I also don't want to see the compression and side loading things removed. It felt like an achievement when i saw a fully compressed belt.

[loup-vaillant]

Beating on the compression dead horse, I was surprised and disappointed to learn that compression became harder than it was before. I expected it would be easier. As far as I know, there are 3 ways of putting stuff in a belt: inserter, side loading, and miners. First, there are a few consistency considerations:

• Underground belts and regular belts should work the same way…
• …except maybe that blocked lane when side loading a belt to an underground.
• Side loading and miners should work the same way, because that's how it looks likes.

Gameplay wise, beginners are routinely surprised that inserters don't compress belts (I know I was). Advanced players either use bots, and don't engage with belt related puzzles; or they use belts, and would repeat the same tedious compression patterns over and over. Unless the devs have thought this through, I don't believe anything interesting will come out of splitters-only compression.

Inserters, miners, and side loading should all compress belts reliably.

[Darci of Mountain]

What is the meaning of increased performance from belts if now we are going to use bots because belts sucks?
Come on! Even miners not compressing belts? How do you feel about splitters between miners? I feel sick.
Using splitters feel cheaty just like underneathies, so, if we aren't to use them udergrounds any more, there should be something designed specifically for that, non cheaty.

Don't get me wrong, I love the game and you devs.

[Tallinu]

Giving requester chests priority over buffer chests until their requests are fulfilled is the behavior that I thought you were describing when I first read about them. It seems like pretty much an obvious, no-brainer decision to fix it so they do, in fact, work that way. Whether or not you add any extra configuration options, that should at least be the default behavior.

And now on to the subject of belts.

1. When side-loading onto belts was changed to its latest pre-0.16 behavior some time ago -- forcing items into gaps that would otherwise be not quite big enough and pushing back the items behind them -- that behavior was, according to what I'd read at the time, absolutely 100% intentional and not a bug in any way. I clearly remember reading (probably in an old Friday Facts) about how it was being made to work better. Pouring additional items onto a belt like that absolutely should cause items to shuffle around to fit more in if they have room to do so, if only because that's more intuitive in terms of physics, not to mention being very useful in terms of gameplay. (Not to mention that when even mining drills can't load a belt beyond 50-60% capacity without complicated splitter shenanigans, even though they should be literally dropping items on top of the belt where gravity should help them fit in, you know something's really gone wrong.)

2. While I don't believe it was altered in 0.16, I know that side-loading onto the aboveground portion of an underground belt entrance/exit is pretty controversial. As far as I know it was not an intentional feature, but I've never seen a dev call it a bug, either. That capability has existed for a long, long time, and it's a tool that can be incredibly useful in many ways. Saying it "doesn't make sense" is silly. Just for starters, look at the graphics. The hood does not quite extend all the way to the surface of the belt, and you can see the aboveground part of the belt, and the edges of some types of items on the belt, moving into or out of the hood. And even if you discount the graphics by claiming they're "glitchy," the fact is that half of the underground belt entrance/exit is still above-ground -- and inserters can place or pick up items there! If inserters can reach through the solid overhead part of the hood to add or remove items there, then that portion should be capable of accepting items from the sides, as well... Unless you think inserters shouldn't be able to put items there, either (and just look how upset some people are that doing so won't compress belts anymore -- now imagine trying to take that away, too). Finally, considering the fact that there is literally no other way to pull one lane off of a belt (regardless of that lane's compression or mixture of content -- filter inserters are not a viable replacement for this) while completely blocking the other lane, this does not seem like a capability that should be removed, regardless of what the people who dislike it say -- if they don't like it, they can simply continue to not use it, as they always have.

3. On the other hand, simply for the sake of consistency if nothing else, dropping items onto an underground belt entrance/exit should follow the same rules as dropping an item onto a normal belt, regardless of which way the decision goes on inserters compressing belts. If inserters end up being able to compress belts all by themselves (which would be perfectly okay by me), then (and only then) that should occur on underground belt parts as well. And if they can't, then it shouldn't happen on any type of belt, normal or underground. It doesn't make sense for them to be treated any differently (that is, being able to insert even when there are no gaps, as in pre-0.16 behavior) just because of implementation details that should remain hidden from the player. Since inserters have never been able to fully compress a belt by themselves, I have no strong preference on which way that particular decision swings, except that (as I said) it should, for the sake of consistency, be applied equally to all kinds of belt parts -- normal, undergrounds, and even splitters.

In general though, I would strongly suggest that you avoid making belts harder to use or less capable than in previous versions. As others have mentioned, late game tech and "megabase" performance issues alike are already pushing you forcefully enough in the direction of "less belts, more bots." While performance improvements are great, having them come at the cost of huge usability nerfs which end up requiring you to use more belts to make up for those nerfs is just going to chip away at those hard-won performance gains. And it needlessly over-complicates many pretty standard setups, not to mention making some of the more complex use-cases completely impossible.

TLDR: If you don't want inserters to be able to compress a belt by themselves, that's fine (although it would certainly be nice if they could), but combining that with the other usability changes is just way too much nerfing for something that is still in need of buffing to be competitive with logistics bots in late-game.

[Rokani]

About Belt Compression: Are you aware of this bad boy: https://gaming.stackexchange.com/questi ... rting-work

How much of that design is intentional?

This explains so much @.@, well the black magic side thread in there at least does.

I vote side loading and a high tech high cost merger, side loading would be cheap but not as compact as a splitter and the merger would be a more compact splitter with only 1 use so still balances things out.

[Aardwolf]

Imho:

Belt tricks that make some physical sense are nice to have and discover.

Belt tricks that make no physical sense but are weird side effects of the internal belt engine are not nice to have and should have a more proper way of solving the problem they try to solve.

Some things that are left out of factorio should be in it as extra building/belt types imho, this are things that should be simple and full speed, not a huge senseless contraption.

Eg swapping 2 lanes of a belt should have 1 simple 1x1 building, and swapping two neigboring belts a 2x1 building.

[Engimage]

I have proposed an idea of Belt buffer device and at the same time Klonan has already developed a mod with the same functionality
https://mods.factorio.com/mods/Klonan/belt_buffer
This is what belt compressor could be (graphics aside)

Reddit thread https://www.reddit.com/r/factorio/comme ... uffer_mod/

[RoCCommander]

I have proposed an idea of Belt buffer device and at the same time Klonan has already developed a mod with the same functionality
https://mods.factorio.com/mods/Klonan/belt_buffer
This is what belt compressor could be (graphics aside)

Even though this is awesome, I would either want this item (with besser graphics) to be in the core game or sideloading, inserters, miners and slitters to be able to compress belts. This is in particular way more newbie friendly.

Besides what makes it in the game in the end, there should be a nice mini tutorial on all the common ways of compressing belts.

[squeaky_ferret]

I would vote for:

• Side loading should compress (full yellow belt should fully compress half a red belt)
• Miners should compress
• Inserters should not automatically compress, but I wouldn't be super upset if they did
• Assuming inserters do NOT compress, then inserting onto underground should also NOT compress

To me, this seems like the best balance of the behavior making some "physical" sense that is reasonable, and also allowing enough variety in the ways you can achieve belt compression. What I think is critical in Factorio is that multiple ways to achieve the same behavior results in people getting creative and finding lots of individual solutions to any particular problem. Take away too many of these ways, and creativity is stifled. I want lots of ways to solve belt puzzles, because I love belts. Please don't make them LESS capable.

[meganothing]

Even though this is awesome, I would either want this item (with besser graphics) to be in the core game or sideloading, inserters, miners and slitters to be able to compress belts. This is in particular way more newbie friendly.

Besides what makes it in the game in the end, there should be a nice mini tutorial on all the common ways of compressing belts.

newbie friendly? tutorial of ways to compress belts? Can anyone enlighten me why a beginner should absolutely need the knowledge of belt compression?

Lots of post made it look like compression is fundamentally important, but I have played Factorio without that knowledge for a long time.

I can think of two applications:
1) If you need a belt to supply resources *exactly* at the upper limit of its capacity
2) If you have a setup (with control circuitry) that demands supply of multiple resources at a specific ratio so that the circuitry works

Both seem to me to be advanced setups. Is there something else or is this storm in the teacup just about "making it look good"?

[Koub]

Without theorycrafting about tactics to achieve perfect compression, even as a beginner, I instinctly wanted to make full use of my belts, and therefore I wanted them to be "full of stuff". Calling that compression is OK, it's just giving a name to the "I want my belts used to their full capacity", in the same manner I "want to use my assembling machines to their full capacity".

This should be (imho) natural, without having to resort to tips and tricks : If I feed my assembling machines with enough stuff, I don't have to do anything else to use them to their full capacity. Should be the same for the belts.

[loup-vaillant]

That belt buffer mod look awesome! This might just be the buff we need.

See, one big problem with belts (compared to bots) is the reduced throughput of inserters: currently, inserters need to wait for all the items to drop on the belt. When they transfer to (or from) a chest, they just drop (or pick) all items at once. This could be significant with fast enough assemblers such as beaconed gear makers, or train loading and unloading (especially unloading). And the compression thing, of course.

If this goes mainstream, I no longer care inserters can't compress normal belts.

[meganothing]

This should be (imho) natural, without having to resort to tips and tricks : If I feed my assembling machines with enough stuff, I don't have to do anything else to use them to their full capacity. Should be the same for the belts.

Belts and Inserters move things, assemblies make new things, both feed each other alternately. If you don't calculate the exact ratio of belt supply capacity to the assembly line it feeds then either the belt or the assembly line will have to wait from time to time for the respective other to finish. In the case of belts that means the resources will back up and the belt will have enough resources all the time, irrespective of complete compression.

Most people will try to make the assembly machines produce at full speed and just make sure the belts and inserters have ample capacity to supply the machines.

[Mango]

For me it's like this

Side loading : yes
Miners : yes
Normal inserters : no
Stack inserters : yes
Undergroun belt : no

[ikatsuke]

My vote is for:

Sideloading: yes
- Including miners, since they are effectively sideloading.

Normal inserters: no
- We can just assume these are not very smart since they don't cost a lot of resources.

Stack inserters: yes
- More expensive inserters are smarter? Sounds like an ok enough reason to allow them to compress. Not a huge deal if not though.

Underground belt: no
- I admit I found this trick quirky, to say the least.

Alternatively, if sideloading will no longer be a thing. How about implementing a type of belt gadget that would allow sideloading? Say something prettier than this horrendous photoshop job? https://i.imgur.com/z1Vwq7u.png Just a thought, heck maybe the number of belts it can merge is locked behind research lol.

[xng]

Sideloading: YES
Miners and future items that unload: YES
Yellow inserters: No
Stackinserters: YES
Underground: No

[AlienZoo23]

I think this was the most disappointing FFF post I've read, which is a shame since most FFF's generate some kind of interest and excitement for me.

Removing all the belt compression "tricks" adds nothing to gameplay. That belts didn't compress automatically was a complete surprise when I first "discovered" it. Nothing in any tutorial or item description makes any mention of compression. So expecting players to "discover" that splitters will compress seems no different from players discovering that undergrounds did. In my view inserters should have compressed in the first place, and if they are not going to then all the current "tricks" should continue to work. Forcing many designs to be wider to cram in extra belts that get joined with splitters is not, for me, any kind of progress. Or any kind of fun.

Requesters chests not working for the logistic network is pretty awful too. Right now the whole logistic thing kind of works but not very well. Being unable to control where items are stored and having bots fly half way across the base to deposit an item when there is a storage chest right next door feels more like an "illogistic" network rather than something that provides the goods where and when they are needed. From the original FFF, requester chests seemed like they would be a significant improvement and reading the comment that they were broken because bots flew an item across a base and then back again my only thought was "just like they do now in 0.15". In the end I'm not at all clear what problem you thought you were trying to solve.

I for one will not be upgrading to 0.16 any time soon. I'm glad that you are being honest about the problems and I hope that they can be resolved without upsetting too many people. But I also can't help thinking that the right time to sound out players about belt compression was BEFORE embarking on massive code changes rather than after.