Combining, Splitting, and Balancing Large Numbers of Belts

[Therax]

As far as I can tell from my testing, Factorio uses the collision box only to determine which tiles the entity covers. Setting a tiny collision box on one side of the tile and pointing the inserter pickup/drop_position to the opposite side of the tile will still frequently result in the loader being selected as the pickup/drop target.

This makes me very sad . I guess you tried spawning them in in the "right" order? Or do they reselect new targets even after being built? (And what about if the loader wasn't active when the inserter is placed...)
I think i'm down to wild guessing.

So it turns out that "internal iteration order" isn't strictly build order once you start mixing building and mining. I think there are internal structures where slots are opened up when entities are destroyed, and the first empty slot is used when building, so it's not possible to reliably build things in the "right" order to get the desired behavior.

Let's hope Therax at least succeeds in making the splitter .

If my interface request isn't implemented, your loader-based version would probably be more than sufficient for the OP's purposes.

[eradicator]

So it turns out that "internal iteration order" isn't strictly build order once you start mixing building and mining. I think there are internal structures where slots are opened up when entities are destroyed, and the first empty slot is used when building, so it's not possible to reliably build things in the "right" order to get the desired behavior.

As long as the internal order doesn't change later on you can brute-force it.

1. Build all the things you need for the complete structure. This will "reserve" the slots you need.
2. Destroy them all.
3. Rebuild them in the correct order.

Though...if that approach worked it should really work in step one already.
And a slot-based system kinda doesn't sound like a good internal structure. Didn't they say it was a ring in some ancient FFF? If they only purge empty "slots" from the ring once a tick that might still behave as you observed i guess.

My loader based cross-splitter does have some benefits yea. Amongst all...it's easy to implement :p.
At least if you don't want a custom 4-way filter gui. Or multi-item support. If you use an unfiltered chest: Imagine if you have a two sided ore belt coming in. Now you filter ore1 north and ore2 south. But if ore1 isn't used at the same rate as ore2 one of them will fill up the internal buffer and eventually block all transfer.

screenshot_11620.png (213.85 KiB) Viewed 6137 times

[eradicator]

So. After testing many things i've come to the conclusion that 1x1, 3x1, or anything else with width Nx1 seems to be unfeasible. 3x2 or 3x3 might still be possible.
Did anyone else have more success?

[eradicator]

I think i've found a diamond on the bottom of a lake of despair. It's pretty dirty and looks fragile, so i hope it doesn't break during polishing. Because it'll need a lot of polishing. Does not use on_tick, and works somewhat like a normal splitter (except filtering is required not optional, and priority is impossible).

loop.gif (1.01 MiB) Viewed 5845 times

[Therax]

As long as the internal order doesn't change later on you can brute-force it.

1. Build all the things you need for the complete structure. This will "reserve" the slots you need.
2. Destroy them all.
3. Rebuild them in the correct order.

Though...if that approach worked it should really work in step one already.

Unfortunately I don't think this will work because as soon as you build an entity in a pickup/drop location, it is immediately "adopted" by the inserter as its pickup/target. So for this use case in particular, where there are 3 inserters, a chest, and two loaders in the same tile, whichever is built last becomes both pickup and drop target for every inserter.

And a slot-based system kinda doesn't sound like a good internal structure. Didn't they say it was a ring in some ancient FFF? If they only purge empty "slots" from the ring once a tick that might still behave as you observed i guess.

It's fairly common to have such a ring have each segment of the ring contain multiple items, to amortize the cost of managing the ring structure. I.e., if you need more room, you allocate an array of 32 slots, and put that into the ring, and then you can track another 31 objects before another allocation and insertion into the ring is required. I'm just speculating though.
[quote="eradicator"If you use an unfiltered chest: Imagine if you have a two sided ore belt coming in. Now you filter ore1 north and ore2 south. But if ore1 isn't used at the same rate as ore2 one of them will fill up the internal buffer and eventually block all transfer.
[/quote]

filtering is required not optional

How are you getting around the backlog problem? Are you using a car entity to get filtered inventory slots?

[eradicator]

filtering is required not optional

How are you getting around the backlog problem? Are you using a car entity to get filtered inventory slots?

Over all the things i tried i actually forgot about cars in the middle of it all. Also i read somewhere that cars are significantly (more than factor 100(?)) more expensive than chests. So for now it uses ordered construction. But i've already hit some weird throughput problems which may force me to make the thing wider than 1 tile. So i'll definetly give cars a try.

Can anyone explain to me how exactly performance testing works? @Optera had those "this vs that" for x ticks numbers.

[Therax]

Can anyone explain to me how exactly performance testing works? @Optera had those "this vs that" for x ticks numbers.

The only access to real time is via log() messages, so the basic technique is something like

Code: Select all

game.speed=10000 -- run as fast as possible
script.on_nth_tick(10000, function() log("--- MARK ---") end)

Then in factorio-current.log you'll see the succession of these log lines with their timestamps, which tells you how long it took to process 10000 ticks worth of game time in real time.

[Optera]

Can anyone explain to me how exactly performance testing works? @Optera had those "this vs that" for x ticks numbers.

Make a savegame and start factorio.exe with parameters --benchmark "%SaveFile%" --benchmark-ticks 10000

I made a batch file writing several passes of the same save to a logfile. Then I manually pick the times and normalize them to filter out noise from background activity.

Code: Select all

set FactorioPath=D:\Factorio_0.16
set SaveFile=bench_save.zip
"%FactorioPath%\bin\x64\Factorio.exe" --mod-directory "%FactorioPath%\mods" --disable-audio --benchmark "%SaveFile%" --benchmark-ticks 10000 >> "%FactorioPath%\Bench 10k - %SaveFile%.log" 2>&1
"%FactorioPath%\bin\x64\Factorio.exe" --mod-directory "%FactorioPath%\mods" --disable-audio --benchmark "%SaveFile%" --benchmark-ticks 10000 >> "%FactorioPath%\Bench 10k - %SaveFile%.log" 2>&1
"%FactorioPath%\bin\x64\Factorio.exe" --mod-directory "%FactorioPath%\mods" --disable-audio --benchmark "%SaveFile%" --benchmark-ticks 10000 >> "%FactorioPath%\Bench 10k - %SaveFile%.log" 2>&1
"%FactorioPath%\bin\x64\Factorio.exe" --mod-directory "%FactorioPath%\mods" --disable-audio --benchmark "%SaveFile%" --benchmark-ticks 10000 >> "%FactorioPath%\Bench 10k - %SaveFile%.log" 2>&1
"%FactorioPath%\bin\x64\Factorio.exe" --mod-directory "%FactorioPath%\mods" --disable-audio --benchmark "%SaveFile%" --benchmark-ticks 10000 >> "%FactorioPath%\Bench 10k - %SaveFile%.log" 2>&1

if you don't know what the pipes mean
>> redirect stdout to a gven file in append mode
2>&1 redirects stderr to stdout

[VisualCSharp]

Hey, all. First of all, I built a new gaming rig just to play this game, so you can tell how excited I am about it! Factorio is awesome and is my new addiction. However, I am noticing one huge quality-of-life issue with the game: balancing lanes and gigantic balancer designs.

I realize that balancer designs are impressive feats of in-game engineering, but to me they are a huge time-waster and expensive resource sink, making my base needlessly large and my bus super drawn-out to accommodate the balancer designs. In my opinion, this could all be simplified by introducing a new item: the Balancer.

https://imgur.com/a/Msut7R3

Here's how it works: The Balancer is a 1x1 item that can be placed anywhere and acts the same as a Splitter in that it has an input and an output. However, the big difference between the Balancer and the Splitter is that Balancers can be placed next to each other and work in concert as a result. Additionally, the player can click the arrows you see in the image (or via some other appropriate mechanism) to turn on and off inputting and outputting from the associated lane. This allows any number of input lanes to balance to any number of output lanes.

Balancers also have an additional mode when in 1x1 configuration: balancing a single lane.

https://imgur.com/a/UgXmaD2

For 1x1 balancing, each belt lane could be balanced independently, or, if that is too complex, the Balancer could simply balance the two lanes' contents. Theoretically (although the UX for this might be far too cumbersome), one could go as far as assigning individual lanes on all input belts to split to specific output lanes on output belts. It's all a matter of how far the developer would want to take the idea.

I realize this would fundamentally alter an aspect of gameplay loved by many, but for me, lane balancing is a real pain and definitely detracts from my enjoyment of the game. I think such an item makes sense in the "lore" of Factorio when you consider that Splitters already sort-of accomplish the opposite function. Balancers can also be thought of as "Combiners" if that makes more sense.

Curious to hear everyone's thoughts.

[Koub]

More or less like this : https://mods.factorio.com/mods/msu320/compoundsplitters ?
Also [Koub] Merged into older topic with similar/same suggestion

[Hannu]

I realize this would fundamentally alter an aspect of gameplay loved by many, but for me, lane balancing is a real pain and definitely detracts from my enjoyment of the game

Devs have rejected many times this kind of ideas. Factorio's core philosophy is to build complex things from simple standard blocks.

What if you just do not balance your lines, if you hate to build it? In most situations there is not technical reason to balance and priority splitters gives better, simpler and cheaper options to handle many belt buses. Assemblers and furnaces do not care if some of them work more than others at partial load situations. Those huge balancers are mostly aesthetic things and I think most of players who use them would not like simple trivial solution. It is nice to watch how material flows through a complex balancer.

[VisualCSharp]

I realize this would fundamentally alter an aspect of gameplay loved by many, but for me, lane balancing is a real pain and definitely detracts from my enjoyment of the game

Devs have rejected many times this kind of ideas. Factorio's core philosophy is to build complex things from simple standard blocks.

What if you just do not balance your lines, if you hate to build it? In most situations there is not technical reason to balance and priority splitters gives better, simpler and cheaper options to handle many belt buses. Assemblers and furnaces do not care if some of them work more than others at partial load situations. Those huge balancers are mostly aesthetic things and I think most of players who use them would not like simple trivial solution. It is nice to watch how material flows through a complex balancer.

It's unfortunate you so readily dismiss the idea. Perhaps if the devs have rejected this kind of idea "many times," there may be some people who want it? I know I'm not alone in my distaste for managing balancers. I disagree that Balancers somehow conflict with the game's core philosophy. These things are all matters of taste and scale. Frankly, your strawman is in bad faith and discourages me from further participating on these forums. That's sad, really.

If other players like balancers, they can use balancers; what did I suggest that would prevent that?

[Zavian]

It's unfortunate you so readily dismiss the idea. Perhaps if the devs have rejected this kind of idea "many times," there may be some people who want it? I know I'm not alone in my distaste for managing balancers.

Factorio still gives you choices, you can design a base that doesn't need massive balancers. Personally I almost never use balancers wider than 4 belts eg this 32 belt unload station only uses 4 belt balancers (and if you manage the takeoffs properly, you don't need more balancers).

32BeltUnload.jpg (869.49 KiB) Viewed 5417 times

Or you can do as Hannu suggested and use priority splitters, and not bother with balancers.

I realize this would fundamentally alter an aspect of gameplay loved by many, but for me, lane balancing is a real pain and definitely detracts from my enjoyment of the game.

Unless you are deliberately blocking lanes with undergrounds, or loading belts in an unbalanced fashion, or wanting to downgrade the speed of a belt after an unbalanced draw, or combining multiple belts into one after an unbalanced draw, you almost never need lane balancers. If you are using lane balancers for anything else, then you can probably probably simply remove most of them. The major exception is wanting the belts to look balanced, which is an aesthetic choice. (Even then, if you keep your supply and demand inherently balanced across lanes, you even achieve belts that are inherently lane balanced, without using lane balancers).

[Darinth]

Honestly, I'm right there with you CSharp. Lane balancers are one of those things that I simply have no actual interest in. I simply went and downloaded a blueprint book of x to x balancers to deal with the rare occasion they're useful for a technical reason (in order to make sure multiple train cars get unloaded as quickly as possible, you need to perform balancing at some point in the process.) Beyond that, I actually use splitters in priority mode to funnel belts down into as condensed a format as I can manage rather than balancing lanes which is actually often pointless or worse detrimental to production.

However, I also recognize the psychological flaw in telling people 'if you don't like it, just don't use it'. The game's general difficulty needs to be setup in such a fashion that if you use all of your tools, it hits an appropriate challenge for some most of it's users. If such a feature were to be implemented, I'd want an option to see it *entirely* disabled during world creation. But that also opens up a whole can of worms in determining what should have such options, what shouldn't, what is disabled by default, what is enabled by default, etc... My base inclination on this issue is to actually recommend downloading a set of balancers. The space taken up by balancers can easily by justified from a game-play difficulty perspective as 'balancing lanes uses x quantity of land', and just keeping a belt balancing book removes the tedium of designing balancers yourself.

[mysticdreamer76]

I'd love to see splitters that were customizable. Starting off as they are, as a two lane, then allowing for many more lanes by combining them in more expensive recipes.

It would be nice to have a 6 lane splitter, where you could filter 6 things, with only a single (or up to 6) input belts.

For example, if you have coal, iron, copper, stone, and uranium coming into a single splitter, and being able to split it
iron iron copper copper stone uranium uranium or something, that would be amazing! instead of having 39 (or however many) current splitters to do this.

[Koub]

[Koub] Merged into older topic with same suggestion.
Unlikely to ever happen, but there's an abandonned mod for that : https://mods.factorio.com/mods/msu320/compoundsplitters
You might want to take it over and update it for 0.18.

[Optera]

[Koub] Merged into older topic with same suggestion.
Unlikely to ever happen, but there's an abandonned mod for that : https://mods.factorio.com/mods/msu320/compoundsplitters
You might want to take it over and update it for 0.18.

Compound splitters does everything in tick. The performance is terrible even compared to base splitter builds.
For decent performance use (mini)loader + large chests.

Since Eradicators way of placing loader - chest - output loader on the same tile no longer works, there is no reason to even make this a dedicated mod.

[ssilk]

I see that similarly. Any reasons against moving this to won't implement?

[mysticdreamer76]

There's another active mod for it also: viewtopic.php?f=87&t=4822

[eradicator]

Since Eradicators way of placing loader - chest - output loader on the same tile no longer works, there is no reason to even make this a dedicated mod.

That was never save-stable btw. - completely unusable in multiplayer. I've done some experiments with inserters too, but they don't balance inheritly. And they can't be speed-controlled at runtime so that approach would require pre-generating a large amount of speed-fractions for all possible belt-count combinations and even then it would only work for fully compressed belts. Aka a perfect even-count splitter isn't moddable without active scripting (as far as i understand not even wide-chest+loader can do it for starved belts). For weird or very large splitting/joining problems that the user wants to solve with perfect ratio circuit based splitters probably work best. Ofc this is not a "modding" thread and it would certainly be possible on an engine level, but...

I see that similarly. Any reasons against moving this to won't implement?

Devs have stated often enough that they don't intend to introduce "shortcuts" to the logistic puzzle. So go ahead and move it.