Friday Facts #221 - 0.16 is out

[FasterJump]

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

I agree with that. Inserters should be able to insert.

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?

Interesting idea. It would be "reserved" spots in the belts with positions like 1, 2, 3. Inserters couldn't place items at position 1.473, it would wait to place it at position 2. But I wouldn't like it, i find ℝ belts prettier than ℕ belts.

[AcolyteOfRocket]

Well if the design philosophy of your buffer chests didn't work out, let us help you

Buffer chests should draw from storage and passive provider chests at a higher priority than requester chests, but then they can only supply requester chests within a certain range. This will allow them to function as a sort of backbone function for the logistic distribution network.

Alternatively the range parameter could be set at the chest by the user. A simple choice would be to put the range choice on the buffer chest, but putting it on the requester chest might allow more finessse in designing logistic network systems. Or just make it a fixed global variable to keep things simple.

It would be nice if all of the requester chests that can be fed by a buffer chest could be highlighted on the map, and likewise for all the buffer chests that are within range (and item specification) to feed a requester chest.

Thanks for implementing the artillery gun, trying to build a base to fire one right now

[GuiltyBystander]

It was before my time, but from what I hear, belts use to lose compression just going around corners. People had to come up with crazy splitter contraptions or upgrading just the corners. But you guys fixed that and it was great. Nobody would ever say that belt corners had great "emergent-gameplay" by destroying compression.

When trying to unload onto a belt, people expect it create a nice clean belt. It's especially frustrating to new players who can see very visible gaps where it seems items can fit.
1 2 3

Besides, wouldn't it be more UPS friendly to not have tons of extra belts/splitters/sideloading to trying and squeeze items for full compression?

TL;DR: I think inserters (on normal, underground, and splitters) and side loading should compress a belt automagically.

[Mathwayb]

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?

I was just about to suggest a similar item to solve the problem of belt compression. Using a splitter has the issue that you need to have 2 belts with slightly more on them than a normal belt of the same color can carry to completely compress it. This is fine but it forces all your builds to take a "wide" approach. For example instead of having a smelting column that is in-line and "long", you need to split it in half and make it wide and "short", which seems unnecessarily constricting. Since we can already use a splitter to compress a wide array of belts I'd be nice if we had an option to compress a belt in an in-line configuration.

A belt compressor was my idea. An item in each of the 3 belt speeds that could be 1x1 or 1x2 or whatever, that will compress the belt when input is fed into it. An inserter or miner, or perhaps even side loading, feeding into one of these items would function sort of like the old underground trick, but could get 100% compression. It could even have its own research tied to each belt speed to unlock each level.

[Zeblote]

Just a thought, there wouldn't be any of these compression problems if items snapped to slots on the belt that are exactly 1 item apart. No weird half gaps - no problems.

[zombieroboninja]

I think that sideloading not causing perfect compression is bad because it is unintuitive and causes bad gameplay when you have to go out of your way to do unconventional, bulky, and obscure workarounds to combat it. The current state with sideloading being bad is in my mind a very similar situation to losing compression on corners in previous versions in that it doesn't make sense gameplay-wise and the solutions are not fun. This is the only change in my time with factorio that hasn't made the game better. I truly hope this change is just an unintentional side effect of the belt optimization and will be fixed.

[Zaflis]

I'm just dropping this here... Hope it helps some of you while they work out how compression should work:

[DarkHelmet]

I personally would prefer all the compression hacks stay removed. Instead, make a belt compression/insertion device. Something like a single-width splitter that you place in-line in a belt and can point an inserter to.

The idea being anything that is inserted into this device is merged onto the belt, potentially compressing it. Make it explicit. Anything that would place things on the ground (inserters, miners etc) could use this to interleave their items onto the belt.

[Nexarius]

I personally would prefer all the compression hacks stay removed. Instead, make a belt compression/insertion device. Something like a single-width splitter that you place in-line in a belt and can point an inserter to.

The idea being anything that is inserted into this device is merged onto the belt, potentially compressing it. Make it explicit. Anything that would place things on the ground (inserters, miners etc) could use this to interleave their items onto the belt.

I'm against that ...
This would just be a replacement belt that would be used EVERYWHERE.



There is no gain from using the splitter everywhere instead of sideloading.

It doesn't look better.
There is no "creative" design / thinking.
It uses more space.
It uses more processing power (extra splitters). (bad for big worlds / multiplayer)

[golfmiketango]

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:

So... side loading is legitimate, but then you say you don't like this contraption.... but that's a side-loading design (which just happens to be side-loading onto an underground)... not sure which of us is confused, probably both

Normative judgements about game-engine dynamics like this are highly subjective (I kinda think the above device is a clever, compact way to overcome potential limitations of side-loading and compress a belt-lane... at a glance it seems pretty inscrutable, perhaps, but it is ultimately possible to figure out why it does what it does through careful reasoning and inspection).

Even if there's no "right" answers to how underground belts and inserters should interact in factorio, there could be more rigorously "wrong" answers, if the proposed mechanisms had unintended negative consequences. I guess for the present discussion, the negative consequences in question would be one of these two:

• By tragically allowing the player to trivially compress a belt with a few inserters, the underground belt trick makes factorio too easy
• By tragically preventing the player from trivially compressing a belt with a few inserters, the underground belt trick makes factorio too hard

Speaking of this, maybe this is obvious but it seems likely that, particularly in moments just after a big change in factorio, like the present one, some non-negligible bias will exist in favor of people deciding that "things should continue to work the same as how they used to work," due to sunk costs fallacies (the sunk cost being people's hard working designing various blueprints and building techniques)....
.... Or, in English, many folks probably want their pre-0.16 builds to keep working and might therefore be irrationally inclined to disfavor otherwise game-improving prospective changes.

[ledow]

Aw.

0.16 just crashes on the loading screen for me.

The only time I ever had a problem on 0.15 was with huge stupendous bases (e.g. 1000 roboport-ranges tall, etc.), but that was always in-game or when loading in the save after a long session. This is just... Loading sprites, 89%, crash.

Off to file a bug, I think.

[Nexarius]

Aw.

0.16 just crashes on the loading screen for me.

The only time I ever had a problem on 0.15 was with huge stupendous bases (e.g. 1000 roboport-ranges tall, etc.), but that was always in-game or when loading in the save after a long session. This is just... Loading sprites, 89%, crash.

Off to file a bug, I think.

I had the same and this fixed it.

Got another reproducable crash after steam upgrade 16.2 -> 16.3 while loading screen displays "Loading Sprites 89%" This may be related to viewtopic.php?f=182&t=54843&hilit=facto ... dInitThunk when I try to compare the logs.

Update: Workaround until fix:

Same here. Crash at 89%. For me this seems to be related to texture compression. If i set texture-compression back to false in C:\Users\<username>\AppData\Roaming\Factorio\config\config.ini game starts up normal.

[alefu]

Great work with the update, thank you devs!

On belt compression:
I personally would like to make belt compression as easy and intuitive as possible, because
a) I would like belts to stay competitive to bots as long as possible in the late game
b) it is an unnecessary hurdle for new players to figure all that stuff out.
So please reenable at least the side loading and even better the compressing with inserters as well. If you do that, the underground hack will not be necessary anyway.
Actually, everyone that uses the undergrounds to compress belts at the moment is just using inserters to compress the belt, anyway.

On buffer chests:
The first solution, that buffer chests are only filled when there are no unsatisfied requests seems easy and logical to me, can't imagine a situation where that could cause problems.

[golfmiketango]

Sorry, I can't resist sharing one more insight about side-loading.

It makes sense that two belt-lanes of fully compressed stuff side loaded onto one belt lane would tend to cause a big mess. Clearly, in "real-life*" the items would get in each other's way and you'd end up with a muddle.

By contrast, I think it makes much less sense to imagine that one belt-lane of fully compressed stuff, side-loaded onto one empty belt lane of equal speed, would tend to cause the items to get uncompressed, since in this particular example of side-loading, there is no "crossing of the streams" (of items) to impede the free flow of the items.

* Obviously I'm talking about a hypothetical real-life in which items can never displace each other laterally into the other lane of a transport belt, which anyone who's ever waited for their luggage at the airport might be inclined to question

[Nexarius]

Finally after all those updates we have the "higher speed belts in corners to fix compression" for sideloading.

I missed that so much.

[Engimage]

I wanted to mention "supercompression" causer by belt rotation.

First of all I do consider this a real problem.
To solve it as well as a problem with picking up items when overwriting belts I think that every belt no matter if it is straight or turn should have equal amount of slots per side. While decreasing number of slots for inner side of a turn makes itemp flow more equally spaced it creates several problems:
- Inconsistency with turning/overwriting belts
- No physical explanation. The belt moves with a constant speed and its side "leafs" do slide on top of each other to facilitate turns. So outer side should increase spacing and inner side should decrease. Now it acts like belt sides are totally independent which is totally unrealistic.

So maybe it is better to drop visual feature and focus on application?

Anyways belt supercompression should go away no matter what. I would say that spilling extra items on the ground is a better solution than supercompression.

[cpy]

I still don't know why offshore pumps still don't need power
Does anyone know which mod made offshore pumps use power?

[Optera]

Finally after all those updates we have the "higher speed belts in corners to fix compression" for sideloading.

I missed that so much.

And in case there is no faster belt we see the return of

Double belt to retain compression fix

[RoCCommander]

Great work with the update, thank you devs!

On belt compression:
I personally would like to make belt compression as easy and intuitive as possible, because
a) I would like belts to stay competitive to bots as long as possible in the late game
b) it is an unnecessary hurdle for new players to figure all that stuff out.
So please reenable at least the side loading and even better the compressing with inserters as well. If you do that, the underground hack will not be necessary anyway.
Actually, everyone that uses the undergrounds to compress belts at the moment is just using inserters to compress the belt, anyway.

I agree completely.

I still don't know why offshore pumps still don't need power
Does anyone know which mod made offshore pumps use power?

One thing has to be there first: Power or Water. Right now the offshore pump give you water without power. Using this water we can get power by steam engines. If offshore pumps need power then we need something to get the water or a different way of getting power without water.

But I guess a burner offshore pump would be nice.

[Koub]

Like many others, I feel compression should be a natural standard thing. Not being able to insert (by side loading or inserter) even though I can see there is room for it feels like an artificial game mechanic. It's the same reason why I thing removing the "magic" compression via inserting into underground belt is a good thing.

I'm not all for IRL realism : we're playing a game, and as such, I agree to temporarily pause my incredulity to accept unexplained "magic" (like lossless poser transmission, powerless belts, or stacks of locomotives in my pockets), but an inserter not being able to drop something on a belt because "achieving compression on a belt should be part of the puzzle" feels off to me (and same for side loading unable to push an item into a gap) : it doesn't make the game better or more rewarding, just makes it a PITA to use fully the very core item of the game (the belt).