Request: 12 Belt Balancer

[mrvn]

I think it's placing only output underground belts, without having to plonk the input part first.
I actually think you can do it by hand, I just tried in a sandbox game, and it was easy :

Factorio - contiguous side loading underground belts.JPG

Wow, nice... so, how did you do it, exactly? Still not sure I get it.

Factorio - contiguous side loading underground belts - howto.JPG

First, plonk the underground belt "entrance" on the left.
Then plonk exit I labelled 1
Then rotate twice, plonk exit I labelled 2
Rince and repeat until number 5
Then delete the entrance, and build one a little on the left
Add the 6th (not on this capture).
Remove the "entrance".

For few exits or when there is no space for the temp entrance:
Plonk down exit 1, press q to clear the cursor, hover over the undergound belt and press r to reverse direction.

[golfmiketango]

Factorio - contiguous side loading underground belts - howto.JPG

First, plonk the underground belt "entrance" on the left.
Then plonk exit I labelled 1
Then rotate twice, plonk exit I labelled 2
Rince and repeat until number 5
Then delete the entrance, and build one a little on the left
Add the 6th (not on this capture).
Remove the "entrance".

You don't actually need to do that either though. You can simply place each UG in the required orientation, and then use the rotate function to reverse their direction of movement as needed, no trickery required.

The only real restriction (and I'm not aware of any way around it) is that complementary UG's in range of each other automatically link together and any attempt at reversing one end's direction will be mirrored at the other end as well. But since the shown rail unloading mechanism doesn't involve any possibility of linking UG's, that's not as issue at all.

Not quite so. This may have changed as I don't remember it being quite this way in the 0.13-0.14 era, but in 0.15, as soon as you put an underground down that is potentially linkable to an existing orphaned underground in any 180 degree rotation from how you "meant" to put it, it is automatically -- and, afaics, non-optionally -- linked to it. Hard to explain, but this is why Koub's technique employs all that back-and-forth-ery. Give it a try and you'll see what I mean.

[Mehve]

Honestly, I just did. For the earlier rail unloading pattern, I can lay down each UG independently, in any sequence, with absolutely no attempts by the game to override or link up with existing ones. Once the UG has been placed down, attempting to rotate it merely reverses the belt movement direction, without rotating the actual shroud.

[golfmiketango]

Honestly, I just did. For the earlier rail unloading pattern, I can lay down each UG independently, in any sequence, with absolutely no attempts by the game to override or link up with existing ones. Once the UG has been placed down, attempting to rotate it merely reverses the belt movement direction, without rotating the actual shroud.

Really? That's decidedly not how I remember it ... for now I'll have to "trust but confirm." Maybe the "auto-linking" behavior is deactivated once you rotate away from it?

Unfortunately my workstation doesn't want to run factorio at the moment (not playably, at least), and I can't fix it for a good while, due to a big backup operation I dare not interrupt.

[golfmiketango]

Honestly, I just did. For the earlier rail unloading pattern, I can lay down each UG independently, in any sequence, with absolutely no attempts by the game to override or link up with existing ones. Once the UG has been placed down, attempting to rotate it merely reverses the belt movement direction, without rotating the actual shroud.

Really? That's decidedly not how I remember it ... for now I'll have to "trust but confirm." Maybe the "auto-linking" behavior is deactivated once you rotate away from it?

Unfortunately my workstation doesn't want to run factorio at the moment (not playably, at least), and I can't fix it for a good while, due to a big backup operation I dare not interrupt.

Well, I finally got factorio running. But I don't think this is quite correct. When you lay down the first underground, it always wants to be an entrance. I was able to do it quite easily though -- just lay down a first "burner" entrance, and then exit-entrance-exit-entrance-exit, all right next to each other, in order, and then tear up all the entrances. I think what I must have been trying to do before was to lay down the exits when the perpendicular line was already in place... but that is possible too, just a little trickier.

Anyhow, one thing is clear -- I was dead wrong, it's quite doable without robots.

[mrvn]

Why an underground belt at all? Is it because you can fill up the internal storage of the underground belt with the inserter quickly and have it come out over time?

[Mehve]

Depends on the exact layout. The buffering is important if you're concerned about maximizing compression. In the earlier post, you can see that a pass through method is used under the rail wagons, so obviously the UG is needed for that. Also, when dropping on to a curve, inserter always drop on the inside, so using a UG to make a mandatory straight belt section can make the inserter drop on to the desired lane.

[mrvn]

Depends on the exact layout. The buffering is important if you're concerned about maximizing compression. In the earlier post, you can see that a pass through method is used under the rail wagons, so obviously the UG is needed for that. Also, when dropping on to a curve, inserter always drop on the inside, so using a UG to make a mandatory straight belt section can make the inserter drop on to the desired lane.

I'm talking about just the side feeding underground belts. A simple side feeding belt would be just the same or not?

[Mehve]

More or less. An exiting UG doesn't buffer the way an entry side does, but there's still a little benefit. But yes, it's not essential in that particular setup.

[golfmiketango]

Correct, it's very possibly superfluous and not tested whether it makes any difference. If I replace the side-loading UG's with belts, it "seems" to work about the same. However it looks prettier and I thought it "might" conceivably be slightly better for compression as Mehve suggests -- I figured the peace of mind was well worth the 10000 gears or whatever

[golfmiketango]

By the way I did some sleuthing about this side-loading unload trick. As best as I can tell it was first "invented" by GoldenShadowGS, in this reddit post: https://www.reddit.com/r/factorio/comme ... _stations/, so, kudos to him for a very clever idea.

[Mehve]

I'm not sure that can be said to have been "invented", since all it's really doing is using a UG to create a straight belt, rather then the default curve - I've been doing that for a long time in my production setups to make lane switchers in a minimal amount of space. But the idea in regards to train stations has come into prominence recently, ever since the UG's reach was extended far enough to pass right under an entire train wagon.

On a related note, maybe it's not worth the trouble after all.


The straight belt actually (very slightly) edged out the UG, emptying a steel chest of ore while the UG one still had ~50 left to go. Save your gears, I guess?

[golfmiketango]

I'm not sure that can be said to have been "invented", since all it's really doing is using a UG to create a straight belt, rather then the default curve - I've been doing that for a long time in my production setups to make lane switchers in a minimal amount of space. But the idea in regards to train stations has come into prominence recently, ever since the UG's reach was extended far enough to pass right under an entire train wagon.

Indeed -- however without those pesky chests in the way even the 4-tile undergrounds are enough (if you can find a way to put decent signals on rails this close together )

On a related note, maybe it's not worth the trouble after all.


The straight belt actually (very slightly) edged out the UG, emptying a steel chest of ore while the UG one still had ~50 left to go. Save your gears, I guess?

Maybe... quite a surprising result, isn't it? I wonder if this means that for i.e., smelters using undergrounds to achieve compression, only the inlet undergrounds are doing their job, or even that the undergrounds trick only works correctly at certain stack bonus sizes? Maybe I'll do some science about this and see what I can figure out -- this matters for the max-moduled smelting array design I'm working on, since, as it turns out, splitters can't currently achieve full compression due to a wontfix-till-0.16 issue.

[Mehve]

Yeah, I've experimented with designs that doubled up on UG's so that each smelter could unload into an entry UG, but I'm not sure the output result was really doing anything that couldn't be done already. Maybe let you run one or two less smelters in a row (and correspondingly fewer T3 modules), which would put you slightly ahead.

Is there an issue with splitters right now? I hadn't noticed anything strange about them lately...

[golfmiketango]

Yeah, I've experimented with designs that doubled up on UG's so that each smelter could unload into an entry UG, but I'm not sure the output result was really doing anything that couldn't be done already. Maybe let you run one or two less smelters in a row (and correspondingly fewer T3 modules), which would put you slightly ahead.

Is there an issue with splitters right now? I hadn't noticed anything strange about them lately...

Yes, see my post here: viewtopic.php?f=58&t=49180. The effect is subtle in the bug report, but in my early smelter designs, where I was attempting to use splitters and balancers, instead of undergrounds, to achieve compression, the effect was much more pronounced, so much so as to ruin throughput. Perhaps I should have mentioned that in my bug report, since the impression that this was a subtle problem with only very minor gameplay impact may have contributed to its being wontfix-ed.

I have also heard "grumblings" to the effect that something changed in splitter behavior which causes feedback loops to no longer work correctly in balancers; but that may or may not be compression-related, and, anyhow, I have not yet found a clear explanation or obvious in-game issue to confirm that this is really so.

[mrvn]

Maybe... quite a surprising result, isn't it? I wonder if this means that for i.e., smelters using undergrounds to achieve compression, only the inlet undergrounds are doing their job, or even that the undergrounds trick only works correctly at certain stack bonus sizes? Maybe I'll do some science about this and see what I can figure out -- this matters for the max-moduled smelting array design I'm working on, since, as it turns out, splitters can't currently achieve full compression due to a wontfix-till-0.16 issue.

The difference to smelters is that there you have items flowing through the underground belt and the inserter squeezes an items into a gap every now and then. The benefit of the underground belt is that even a 1 tick gap will allow the inserter to drop it's item and halts the input to make the gap one item big. That "halts the input" part is what compresses the output. It would be more accurate to say the input is compressed.

[golfmiketango]

Maybe... quite a surprising result, isn't it? I wonder if this means that for i.e., smelters using undergrounds to achieve compression, only the inlet undergrounds are doing their job, or even that the undergrounds trick only works correctly at certain stack bonus sizes? Maybe I'll do some science about this and see what I can figure out -- this matters for the max-moduled smelting array design I'm working on, since, as it turns out, splitters can't currently achieve full compression due to a wontfix-till-0.16 issue.

The difference to smelters is that there you have items flowing through the underground belt and the inserter squeezes an items into a gap every now and then. The benefit of the underground belt is that even a 1 tick gap will allow the inserter to drop it's item and halts the input to make the gap one item big. That "halts the input" part is what compresses the output. It would be more accurate to say the input is compressed.

That would certainly explain why there might be no benefit to using a UG exit in my unload design. It would also suggest any benefits of the UG "trick" would only apply to every second inserter in my design. This should not introduce a lane imbalance in my particular implementation since I have inserters on both sides of the rail car; but it also would probably mean that a six-lane version without this side-loading trick would be marginally superior (in terms of throughput and compression dynamics). This would also suggest that the one-sided version of this unload trick would have a minor lane imbalance, as it exploits side-loading to compress the left lane but the UG trick to compress the right lane.

I'll have to do some testing, but I suspect you're exactly right mrvn, since I've noticed that in my unload stations, the trains toward the "top" (nearer the exit into the big ridiculous balancer) tend to slow down unloading of trains at the bottom (actually, if they get big enough, what ends up happening is the middle trains get the biggest slow-down, and the top and bottom get the most throughput, but the top gets more throughput than the bottom; I have seen this phenomenon with daisy-chains of mining drills outputting into parallel undergrounds as well).