Challenge: Generic max-speed train unload

Post all other topics which do not belong to any other category.
Post Reply
Copy link
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

Durentis wrote:But I suspect the worst case is that the buffer chests just need to request more items (like 4k) to stay balanced.
That's the point where i disagree, and after a quick experiment i'm quite certain. (Also the experiment says that priority seems to be irrelevant, bots take whatever is closest)

The problem is:
If you set the buffer chests to an arbitrary high amount the bots will fill them at an equal rate. But as bots empty them based on what's closest the output rate of each buffer chest will be different. That means the bots will first empty whatever chests is closest to where they want to go. Meaning in my example, that if you put chests on the right side, they'd only be used after all the chests on the left side are empty. And that means you loose the unloading speed benefit of the right-side chests most of the time, because they're already full. Yea, there's lots of variables. But "just setting requests to 4k" is unlikely to work imho.

Which is why i said it needs a complicated circuit. The idea being that it would be optimal if each buffer chest requests the average of the total content of all buffer chests (this is a common unloading station pattern). But as you can't directly measure the content of buffer chests in that situation, you'd have to "measure" the content of the chests based on a counter that weights-inserted items vs belted-out items.
Durentis wrote:But if it's important to have compressed blue belts, I expect a sustained and sufficient drain on resources such that there will always be room in the chests to unload a train in a reasonable time. If there isn't room in the chests (they ever become unbalanced because/or the system has backed up - same effect and inevitable), it now falls to the train network to fail gracefully until the system recovers.
OP was very... vocal... in my thread about wanting the unloader to balance chest drainage, even if most of the output belts have stopped completely. Otherwise we wouldn't be here ^^. "Why" i don't know. It's a somewhat interesting problem but seems unreleated to "average" players.
bufferinteraction.jpg
bufferinteraction.jpg (345.15 KiB) Viewed 6618 times
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
zOldBulldog
Smart Inserter
Smart Inserter
Posts: 1161
Joined: Sat Mar 17, 2018 1:20 pm
Contact:
Contact zOldBulldog

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

eradicator wrote:wanting the unloader to balance chest drainage, even if most of the output belts have stopped completely. Otherwise we wouldn't be here ^^. "Why" i don't know. It's a somewhat interesting problem but seems unreleated to "average" players.
I was hoping to avoid derailing the thread discussing the "why", but here it goes. This is not the only reason but the most obvious: Because of unbalanced drain, I had situations in the past with this type of "gradual build of the base" where the overall output throughput had dropped by a lot. When I investigated I found some chests empty, some almost full, and the train stopped dead, waiting to unload... it had emptied one wagon and the other was almost full. This had apparently built up over time until it reached this extreme.

Yes, I know I could always put a time limit and let another train come and fill things up. But that means half-empty trains going back to the mine... quite a waste. Better to keep things balanced and trains unloading until empty.

Slapping an 8-8 balancer upon exit from the station helped, but didn't completely solve the problem. That is where the main concern for balancing those unload chests comes from... to avoid stuck trains.
Top
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

zOldBulldog wrote:I was hoping to avoid derailing the thread discussing the "why", but here it goes. This is not the only reason but the most obvious: Because of unbalanced drain, I had situations in the past with this type of "gradual build of the base" where the overall output throughput had dropped by a lot. When I investigated I found some chests empty, some almost full, and the train stopped dead, waiting to unload... it had emptied one wagon and the other was almost full. This had apparently built up over time until it reached this extreme.
Ugh. So you want unload balancing for the whole train, not just per-wagon. That is a completely different problem and hardly some minor unimportant detail that would "derail" the thread. The robots might be able to do it up to a certain degree like described above. But you can't use smaller per-wagon networks to optimize flight-times anymore. It's also a problem that scales badly with train length. This sounds all the more like my thread + a huge balancer slapped at the end.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
zOldBulldog
Smart Inserter
Smart Inserter
Posts: 1161
Joined: Sat Mar 17, 2018 1:20 pm
Contact:
Contact zOldBulldog

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

Yes eradicator, it is not a minor detail. Maybe I wasn't clear? I thought I said to balance all unload chests. I don't think I ever said to balance just one wagon.

But knowing that you didn't notice that "detail" makes me understand your objections.
Last edited by zOldBulldog on Tue Jul 24, 2018 9:45 pm, edited 1 time in total.
Top
Durentis
Fast Inserter
Fast Inserter
Posts: 107
Joined: Mon Jun 27, 2016 3:55 pm
Contact:
Contact Durentis

Re: Challenge: Generic max-speed train unload

Post by Durentis »

@eradicator: probably right on the Buffer Chests. Wishful thinking on my part that bots would play nice trying to satisfy their demand by pulling from the over-full ones into the unsatisfied ones. According to the wiki, buffer chests won't even request from other buffer chests at all. I think a request + active provider chest, call it an Active Buffer Chest, where it behaves as an active provider chest unless its request (including from other buffer chests) would be unsatisfied would probably do what I want but it doesn't exist.. at least not in Vanilla. Passive Chests on the 2-lane side as you suggested might work best given what's available but I still don't like that they could be completely drained by the bots. Perhaps at that point it really doesn't matter though.

@zOldBulldog: The "why" is an important part of any problem description because even though you're pretty sure you need X to be part of the solution and ask for it, those who understand the "why" may have other ideas that solve the core problem in a completely different way not involving X.

Anyway, would be nice but I don't think the output station chests themselves really need to be balanced if you handle the trains well, though I could be wrong. Do balance the input station chests as best you can (still not that important, imo) and disable the input stations if they don't have enough resources per wagon (this is the most important bit).
Top
Kalandrul
Manual Inserter
Manual Inserter
Posts: 2
Joined: Tue Jul 24, 2018 2:59 am
Contact:
Contact Kalandrul

Re: Challenge: Generic max-speed train unload

Post by Kalandrul »

Hi guys, new to the forums, but I've been playing around with train stations in creative while prepping blueprints for 1k SPM.

Doing some closed loop stress testing of long term distribution by bots @eradicator hit the nail on the head, and with any sort of actual buffer in the system, distribution by bots will not be even from the provider chests. This led me to see the early steps of @zOldBulldog's primary issue. Bots DO NOT pull evenly from chests. This WILL lead to chests filling up. This fill up usually occurs towards the center of the build in my experience (original tests were for 6-12 single direction stations). This causes one or two inserts on a central wagon to not move items and slow down overall unloading which leads to your station not actually able to provide the throughput it was designed for.

Absent @eradicator's suggestion of a balancer after the unload, an alternative solution would be to simply provide a high output bandwidth than trains can logistically support. I found that train to station delivery time on my 6-12 setup would let 6 lanes per car empty their buffer and never have a backup slowing down cargo wagon unload time.

Updating @Durentis design to duplicate the 4 lane per side onto both side of all wagons is tile-able, will fully saturate 8 belts per wagon with a creative cargo wagon provider, but will run dry for short periods when using a fast delivery 1-2 nuclear powered train. By outputting MORE than the input can possibly run, the bots keep this a balanced output, and you'll never run into a bottleneck of full storage chests. (using a duplicating cargo wagon from creative mod actually STILL build a buffer starting in the 4 active provider chests which will lead to eventual slow down. I do not believe trains can be delivered fast enough to create this buffer overflow issue.)

TLDR: IMHO if you can deliver items faster than you can ship them off via belt, you'll run into OPs problem absent fancy circuit conditions. My solution, output more belts than can concieveably be supported by train station throughput.

Blueprint attached for the 8 belt per wagon unload
PQLG4MN[1].jpg
PQLG4MN[1].jpg (236.69 KiB) Viewed 6571 times


Edit: img tag didn't work so I pasted the imgur link. Also ignore the splitter shennanigans on the right.
Last edited by Koub on Wed Jul 25, 2018 5:28 am, edited 1 time in total.
Reason: Fixed image
Top
Koub
Global Moderator
Global Moderator
Posts: 7955
Joined: Fri May 30, 2014 8:54 am
Contact:
Contact Koub

Re: Challenge: Generic max-speed train unload

Post by Koub »

Sorry to interfere, fixed your image (uploaded it to the forum, it's so much better than imgur ^^)
Koub - Please consider English is not my native language.
Top
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

Kalandrul wrote: This fill up usually occurs towards the center of the build in my experience
Well, obviously. The outside chests have inserters pulling directly from them :). Might be possible to sacrifice lots of beauty and space to attach inserters to the middle ones too.
Kalandrul wrote:Absent @eradicator's suggestion of a balancer after the unload, an alternative solution would be to simply provide a high output bandwidth than trains can logistically support.
Let me be VERY clear on this. A balancer after the unload is NOT my suggestion, it is what the OP demands. My original thread is firmly on the "just don't let the output belts stop" side.
Kalandrul wrote: By outputting MORE than the input can possibly run, the bots keep this a balanced output, and you'll never run into a bottleneck of full storage chests.
Well, you still gotta put the stuff somewhere, unless you want to run a (semi-)"burst" style factory. As OP explicitly demands a design that works with an "average players growing starter base" guaranteed output speed is pretty much off the table. (If anyone wants to tell OP about the realism of his conditions be my guest...)

Also can 6 roboports really support 16 belts? Intuitively i'd say that's not enough charging ports.

[Hi Koub. Good to see your watchful eye ;)]
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
nog
Inserter
Inserter
Posts: 32
Joined: Wed Mar 04, 2015 12:13 pm
Contact:
Contact nog

Re: Challenge: Generic max-speed train unload

Post by nog »

Without bots but using the splitter trick, maximum throughput for one wagon is about 8228 units per minute, ~3.43 blue belts, or more exactly 240 electric furnaces (8*30) without modules.

Image
Top
Kalandrul
Manual Inserter
Manual Inserter
Posts: 2
Joined: Tue Jul 24, 2018 2:59 am
Contact:
Contact Kalandrul

Re: Challenge: Generic max-speed train unload

Post by Kalandrul »

@eradicator regarding the center backup, I meant that more generally even with my original 72 belt output from 12 wagons using wagon>active provider>bots>requester chest>belt (aka bots only from unload chests) it was the middle 2 active chests unloaded from wagons 6 and 7 that tended to fill up first causing the delay. (I can provide screencap/BP for that unload tonight when I'm not n mobile.)

Insofar as the 6 roboports is concerned. I'm at an hour using creative infinity wagons with no issue. I do have speed 5 and cargo cap 3 (using speed 5 as a more standard/sable bit speed since it's pre rocket science) this 6 have held up without delay. Using 300 bots in network, but only 150-200 get used at burst.

I also don't think you need to run a semi burst style factory, just compress the uncompressed 8 lanes from my output down to however many your real throughput is depending on train delivery speed. e.g. train throughput is 6.7 belts, unload onto 8 with gaps and compress down to 7 with the 7th not fully compressed and feed those to the smelting arrays. This actually does provide a built in expandability as train delivery speeds up you can go from filling 2 or 3 full belts from the 8 per wagon to filling 6 or 7 belts late game very easily with filter splitters.

PS.thanks for the Ninja fix Koub <3

Edit: Adding a screen cap and BP for 6-12 train station unloading 72 belts or 6 per cargo. Again I haven't gotten nuclear powered trains to move into it fast enough to permanently compress all 72 belts sticking with the "move more than you can unload" philosophy. I will also note that when i did experience OP's issue while stress testing a 60 belt unload for the 6-12, All belts stayed saturated even if one or two cargo wagons were taking longer to unload. Which means that the bots balancing into requester chests technically solves OPs issue as the slowed unloading only happens with an abundance/buffer of delivery, but shouldn't ever impact throughput on any given belt. The bots guarantee equal throughput on all belts it seems.

I also have a short video of this in action. If anyone's interested I'll try and figure out how to upload it here.



42 roboports and approx 2k logistic bots required at speed 5 and cargo size 3
Attachments
6-12 Train Bot Based 72 Blue Belt Unload
6-12 Train Bot Based 72 Blue Belt Unload
6-12 unloader 72 belts.PNG (1.91 MiB) Viewed 6505 times
Top
mrvn
Smart Inserter
Smart Inserter
Posts: 5969
Joined: Mon Sep 05, 2016 9:10 am
Contact:
Contact mrvn

Re: Challenge: Generic max-speed train unload

Post by mrvn »

eradicator wrote:
Durentis wrote:But I suspect the worst case is that the buffer chests just need to request more items (like 4k) to stay balanced.
That's the point where i disagree, and after a quick experiment i'm quite certain. (Also the experiment says that priority seems to be irrelevant, bots take whatever is closest)

The problem is:
If you set the buffer chests to an arbitrary high amount the bots will fill them at an equal rate. But as bots empty them based on what's closest the output rate of each buffer chest will be different. That means the bots will first empty whatever chests is closest to where they want to go. Meaning in my example, that if you put chests on the right side, they'd only be used after all the chests on the left side are empty. And that means you loose the unloading speed benefit of the right-side chests most of the time, because they're already full. Yea, there's lots of variables. But "just setting requests to 4k" is unlikely to work imho.
You shouldn't set the buffer chests to 4k items but the requester chests. Or actually both.

In theory what happens is that the train unloads into all chests equally. Then inserters take from the buffer chests and bot also take from the buffer chests to fill the requester chests (since they are nearest). So the buffer chests request more items. Nearest are the two provider chests on the same side so they empty first. Then the provider chests on the other side of the train would get tapped, the two middle chest get emptied last.

So the buffer chests for the train empty out one after another. Totally what you don't want. BUT the bots, if you have enough, can empty them out far faster than the inserters can fill them. And the bots will fill the requester chests and buffer chests to their maximum amount and then keep them there. So the actually buffering should happen in the buffer and requester chests while the chests at the train should be mostly empty.

All theory but worth testing.
Top
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

mrvn wrote:So the actually buffering should happen in the buffer and requester chests while the chests at the train should be mostly empty.
Yes, but this only works reliably if the inserters don't directly take from the chests that the train unload into (which they do in my original design). If you seperate the chests that the train unloads into and the chests that the inserters take stuff out it becomes much easier to set up the required dynamic-request-size circuit, though you'd have to kinda do a rolling-average style because you still can't measure the content of a requester chest that you're setting a request on.
Kalandrul wrote: The bots guarantee equal throughput on all belts it seems.
OP wanted a guarantee on the unload speed of the train too though i think (in any case it would be a nice feature). As long as there's still buffer space left obviously. That you can scale it up that far with barely any roboports is certainly beyond my expectations though :).
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
mrvn
Smart Inserter
Smart Inserter
Posts: 5969
Joined: Mon Sep 05, 2016 9:10 am
Contact:
Contact mrvn

Re: Challenge: Generic max-speed train unload

Post by mrvn »

eradicator wrote:
mrvn wrote:So the actually buffering should happen in the buffer and requester chests while the chests at the train should be mostly empty.
Yes, but this only works reliably if the inserters don't directly take from the chests that the train unload into (which they do in my original design). If you seperate the chests that the train unloads into and the chests that the inserters take stuff out it becomes much easier to set up the required dynamic-request-size circuit, though you'd have to kinda do a rolling-average style because you still can't measure the content of a requester chest that you're setting a request on.
Not necessary. The buffer chests will be emptied at roughly the same rate as the requester chests, right? The bots will then keep all chests at roughly the same amount. If a train is unloading into the buffer chests it will exceed that amount and bots will fill only the requester chests. So you need enough extra space in the buffer quests to unload 1/12th of the train. After that the buffer chests should get drained down to the requested amount again. With 4 buffer chests and 8 povider chests there should be no problem getting the buffer chests drained.
Top
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

mrvn wrote: With 4 buffer chests and 8 povider chests there should be no problem getting the buffer chests drained.
Well, it depends on how long you want to guarantee the unloading time. If it needs to guarantee the time only up to i.e. 50% full buffer and can slow down afterwards that'd probably work. But if you want to guarantee unloading times up to 90%+ full buffer situations it won't. So...what premise are we operating at here @OP?.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
mrvn
Smart Inserter
Smart Inserter
Posts: 5969
Joined: Mon Sep 05, 2016 9:10 am
Contact:
Contact mrvn

Re: Challenge: Generic max-speed train unload

Post by mrvn »

eradicator wrote:
mrvn wrote: With 4 buffer chests and 8 povider chests there should be no problem getting the buffer chests drained.
Well, it depends on how long you want to guarantee the unloading time. If it needs to guarantee the time only up to i.e. 50% full buffer and can slow down afterwards that'd probably work. But if you want to guarantee unloading times up to 90%+ full buffer situations it won't. So...what premise are we operating at here @OP?.
What must not happen is a buffer or requester chest being empty. That would leave gaps in the belts. If there is unbalance but none of the chests are empty then all is still good. Trains might block and take longer to unload because chests are unbalanced but that is unavoidable. If trains come in faster than you take away items then they have to block eventually. The important point here is that that case only ever happens while the requester and buffer chests are not empty.

And given enough bots the buffer chests can only get empty when all the provider chests are. And the requester chests can only get empty when all other chests are. In any case all chests next to the train have space to unload the train until there are too many items buffered everywhere.
Top
Durentis
Fast Inserter
Fast Inserter
Posts: 107
Joined: Mon Jun 27, 2016 3:55 pm
Contact:
Contact Durentis

Re: Challenge: Generic max-speed train unload

Post by Durentis »

I have made some adjustments, both major and fine tuning, to my initial build as follows:
  • Changed the 2-lane outputs to one of @timeshifter's designs, as DaveMcW's was skipping occasionally
  • Unloading the 2-lane outputs into Passive Chests, inserters pulling from Requester Chests but not pulling from Passive Chests
  • Adjusted various numbers in the Buffer (500) and Requester (200 on the 4-lane side, 100 on the 2-lane side) Chests
  • Increased to 3 roboports per wagon to help with peak loads
  • Moved Substations into 4-lane build to tidy it up - they miss three inserters on the top and bottom with this 2-lane design, but better than running power lines along the track, imo
  • Signals in the unloading station are one per car, not two, as it works much better. Cycling trains is so smooth.. :)
Todo:
  • Replace Steel Chests with a single Requester Chest and remove inserter array leading to it or otherwise simplify the 2-lane output side given the flexibility of Requester Chests
  • It's the central two Passive Providers of each group of six on the 2-lane side that fill up. Making these Active Providers may be useful though I think it only slows the inevitable where all the chests fill up.
For 100 stack size items, this now seems to sustain six compressed blue belts indefinitely, after the first several trains while it reaches equilibrium. When I cut the track to starve it after running a while, the output belts stayed compressed for about 45 seconds! What this tells me is that even if the chests themselves are unbalanced (and they were), slowing train unload time, the lines will not be starved as a result of the imbalance. Slowing train unload time, given that trains are adequately handled, is not a bad thing. In fact, I'd argue that it's a good thing as it frees up the input mines for other trains delivering to other output stations. These slowed trains are not congesting the main rail system.

For 50 stack size items, it sustains five compressed blue belts indefinitely. (I doubled the logistic requests and merged the 2-lane sides to only output one lane.) I also set the inner Requester Chests to not request from Buffer Chests to take some of the load off of the Buffer Chests. Need to add a few extra Roboports since the bots are moving a lot more volume and will otherwise spend some time waiting to recharge (there's lots of room in the belts).

The blueprint uses Infinity Chests as an input station and fuel supply, as well as void belts from the Spawn Belt mod to remove resources.

Create 3-5 trains in the stacker with the following schedule:
  • output (Wait until Empty cargo inventory)
  • input (Wait until Full cargo inventory)
Unloading Station 2.jpg
Unloading Station 2.jpg (859.29 KiB) Viewed 6449 times


@nog: That looks like it might be great to start with prior to getting bots.

@Kalandrul: I think I'd rather constrain the output station than let it run free and then somehow clean up the lines after. I see this sort of thing as running into a 1:1 smelter so the compression is important to me. I'm interested in that super long train one though and curious if nuclear powered trains can get in fast enough. I now know 3-5 trains work but those numbers were totally arbitrary.. no math behind them whatsoever.

@eradicator and @mrvn: You're right on about the bots and chests.. was theorizing but didn't really know the specifics on how they work. I tended to make thousands in a large base and let them go. ;) I think this fine tuning works very well now though.
Top
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

Built a first concept of a "guaranteed unload time" station. Will always unload a train in exactly the same amount of time. If output belts partially slow down it'll slow down the unloading of the whole train accordingly. Thus the buffer is always equally distributed to all outputting lanes, from all inputting wagons. Has slightly less output capacity than the previous one for purely asthetic reasons. (I wanted to try the splitter thing). Uses only two combinators (much less than i anticipated). One to dynamically set request size, and one to dynamically slow down the unloading inserters.
compactbots1.jpg
compactbots1.jpg (718 KiB) Viewed 6439 times
compactbots2.jpg
compactbots2.jpg (610.72 KiB) Viewed 6439 times
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
vanatteveldt
Filter Inserter
Filter Inserter
Posts: 947
Joined: Wed Nov 25, 2015 11:44 am
Contact:
Contact vanatteveldt

Re: Challenge: Generic max-speed train unload

Post by vanatteveldt »

I love the designs posted above, but I'm with mrvn's earlier argument here.

The goal of the OP was:
- To identify the highest performing and reliable designs to unload and feed the smelters that deliver to a base's main bus.
- To make such designs available to average players. The designs should be usable and viable for the general population, not just experts.
Performance can be measured in a lot of ways, but maximizing the performance of a single unloading bay comes at the price of increased complexity and footprint and makes it extremely important that the trains arrive in quick succession. For the "general population", if we assume coal fired engines and regular stackers, there's quite a delay between trains even with lots of signals, making it difficult to sustain throughput.

It's so much easier to double capacity by just adding another unloading bay. Unloading a single blue belt per wagon is trivial, and 2 is also very easy using two sides. So, if you need 16 blue belts for your smelters, why not have 2 8-wagon stations or 4 4-wagon stations? Especially if you add limited-capacity buffer chests this adds so much redundancy that you can mess up your station design pretty badly and still get sustained maximum throughput...
trivial 8 lane station
Top
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5211
Joined: Tue Jul 12, 2016 9:03 am
Contact:
Contact eradicator

Re: Challenge: Generic max-speed train unload

Post by eradicator »

I don't think the bot design above is particularly complex. It uses only straight-forward mechanics, albeit at heigh density. Side-loading of things onto belts, requester chests, nothing fancy. I did(?) say that the circuit is probably out of scope there, even though it is very simple as far as circuits go. Also shrinking it down to one belt per wagon is easy, i'll leave the exercise to the reader ;).

Also a high-throughput station does not require lots of trains. It works just fine with just a few trains. And i don't even agree with the OP about the "for average players". Any design you don't build yourself is always somewhat of a black-box. And a basic station as you describe sounds like it can easily be designed by the average player by themselfs. And i don't even believe that "average players" come to the forum to get a solution they understand. They come here to find a solution that is optimal for their problem and works. Understandability might be a good bonus...

Also OP explicitly demanded that the whole train is unloaded in a balanced way. Which is a ridiculously high hurdle as far as any-length unloading goes. And definetly not doable in any way that the "average player" understands.

Also i thought OP said he wanted only one unloading bay... can't find a quote on that atm.

About your "trivial" design...let's see. It uses half-underground belts to split things, which is definetly black magic for "mr average". And with four inserters you're not filling a whole belt unless you use stack-size-override magic. Not even speaking of the 8-lane balancer. Because even experienced players couldn't tell if it works or not at a glance.

That said, i'm not "with" anyone. I just post nice designs and wait if OP thinks they meet his contradictory conditions. OP seems to be absent though. To me OP is the black-box so to speak ;).
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Top
zOldBulldog
Smart Inserter
Smart Inserter
Posts: 1161
Joined: Sat Mar 17, 2018 1:20 pm
Contact:
Contact zOldBulldog

Re: Challenge: Generic max-speed train unload

Post by zOldBulldog »

My idea for the thread is that while a good design might be tough for an average player, it is easy enough to see a screenshot and grab a blueprint that works well without much thought. So if we get a few good designs posted that an average (or beginner) player can copy and use without much further thought, that is going to work well until their skill improves.

The bot design looks cool and easy to use. Sure, it requires already having yellow science, but that can be achieved before the train stage.

Additional designs will help too, especially for those who need trains earlier.

I have a design or two that I plan to share too, but I want to refine them and stress test them first.

As for my personal use, I expect to settle on a mix of designs depending on the purpose, including the bot one.
Top
Post Reply

Return to “General discussion”