A recent thread prompted several interesting designs with the goal to unload 4 saturated blue belts per wagon. But it was eventually clarified by the OP that he was only interested in the raw unload step, thus the designs can fail if the demand on the output side isn't perfectly balance (viewtopic.php?f=194&t=58728). While interesting, it is not viable for the most common player train unload need, to feed the smelter array that supplies the main bus (since demand on the main bus belts is by definition uneven and can change over time).
This thread's main goals:
- 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.
Design criteria:
- Throughput must be sustainable, not die out due to unbalanced demand (i.e.: what happens when the unload chests become unevenly filled and trains end up blocking the station waiting to unload one last wagon).
- If you can, make it compact. But not all designs will be compact.
Posting format:
- Post the Throughput as saturated blue belts per wagon. I.e.: Throughput: 2.5
- If you tested over time with both excess supply (trains waiting to unload) and insufficient supply (station empty waiting for trains), place TESTED next to the throughput number. If you only did partial testing place PARTIAL TEST.
- Post a screenshot of your design, and if possible a blueprint.
- As your design will likely be for the specific train configuration you use, give hints if you can (and maybe links) on how to adapt it to a different number of wagons.
Likely design pieces :
(together they make a complete design)
- Bare unload. (could be some of the 4-saturated-blue-belt designs from referenced thread or something new)
- Input-balanced Compressor/Balancer. (will likely be the source of throughput drop)
- Train unload management (rails, stop, signals, stacker) - DO NOT INCLUDE. This is an essential element to feed trains to the unload mechanism at a fast enough rate, but it would be best covered in a separate thread to avoid distractions.
My personal interest at this time is for 1-2 trains, but I am not limiting the thread as this thread is targeted to serve all average players not just me.
EDIT: I am waiving the "input chests must remain balanced", so long as 4 or nearly 4 saturated blue belts per wagon can be sustained regardless of how unbalanced the demand might be. The only reason for that requirement was to ensure that we could maintain the throughput. But frankly, if 4 saturated blue belts per wagon can be sustained no matter what... it doesn't really mater how it is achieved.
Challenge: Generic max-speed train unload
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Challenge: Generic max-speed train unload
Last edited by zOldBulldog on Sat Jul 28, 2018 9:30 pm, edited 1 time in total.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Challenge: Generic max-speed train unload
Thank you disentius.
Are you pointing to your last post/screenshot in that thread?
If you are pointing to that one, it sure looks very clean and I have a couple questions:
- How many saturated belts does it output - after adding an input-balanced compressor/balancer?
- Which compressor/balancer do you recommend using?
- Since I don't see any circuits, do the chests ever drift from perfect balance and if they do, does the normal ebb and flow of supply and demand keep them from getting too far out of balance so that trains are never delayed?
-
thedarkbunny
- Inserter
- Posts: 46
- Joined: Mon Oct 23, 2017 10:46 pm
- Contact:
Re: Challenge: Generic max-speed train unload
Based on the layout and some back-of-the-napkin math, all six belts should be fully compressed. 24 inserters should theoretically be able to saturate seven belts, but that would require a more complex setup.zOldBulldog wrote:Thank you disentius.
Are you pointing to your last post/screenshot in that thread?
If you are pointing to that one, it sure looks very clean and I have a couple questions:
- How many saturated belts does it output - after adding an input-balanced compressor/balancer?
- Which compressor/balancer do you recommend using?
- Since I don't see any circuits, do the chests ever drift from perfect balance and if they do, does the normal ebb and flow of supply and demand keep them from getting too far out of balance so that trains are never delayed?
There's effectively zero balancing on this setup, so you'll need to either carefully balance (and lane-balance) your belts, or add circuitry to balance things at the station.
-
eradicator
- Smart Inserter
- Posts: 5206
- Joined: Tue Jul 12, 2016 9:03 am
- Contact:
Re: Challenge: Generic max-speed train unload
For very short trains robot-based balancing is very powerful as long as you keep it seperated from your main network, which shouldn't be too difficult for a train station. Just make the belts to the factory slightly longer.
Outputs 4 fully compressed blue belts per wagon (4% less than the theoretical maximum for one-sided unloading) until about 5 seconds before total buffer depletition. But is unfeasible for longer trains due to increased robot charge requirements (unless you have a mod that allows you to build seperate networks per wagon). Requires about 50 logibots on average and about 200 for peaks. Also requires full stack inserter bonus.
Outputs 4 fully compressed blue belts per wagon (4% less than the theoretical maximum for one-sided unloading) until about 5 seconds before total buffer depletition. But is unfeasible for longer trains due to increased robot charge requirements (unless you have a mod that allows you to build seperate networks per wagon). Requires about 50 logibots on average and about 200 for peaks. Also requires full stack inserter bonus.
- robobalancer.jpg (573.14 KiB) Viewed 23303 times
The real questoin is...why do you want to balancer before the smelter array. To fully utilize a smelter array you'd optimally want to balancer after the array, so that uneven demand does not translate into the smelter array (impacting array utilization) or before.zOldBulldog wrote:to feed the smelter array that supplies the main bus (since demand on the main bus belts is by definition uneven and can change over time).
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.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Challenge: Generic max-speed train unload
Nice compact design. I assume it keeps the unload chests even too, especially under uneven downstream demand. I will definitely try it, it should work great for some of my builds.eradicator wrote:For very short trains robot-based balancing is very powerful as long as you keep it seperated from your main network, which shouldn't be too difficult for a train station. Just make the belts to the factory slightly longer.
Outputs 4 fully compressed blue belts per wagon (4% less than the theoretical maximum for one-sided unloading) until about 5 seconds before total buffer depletition. But is unfeasible for longer trains due to increased robot charge requirements (unless you have a mod that allows you to build seperate networks per wagon). Requires about 50 logibots on average and about 200 for peaks. Also requires full stack inserter bonus.
The real questoin is...why do you want to balancer before the smelter array. To fully utilize a smelter array you'd optimally want to balancer after the array, so that uneven demand does not translate into the smelter array (impacting array utilization) or before.zOldBulldog wrote:to feed the smelter array that supplies the main bus (since demand on the main bus belts is by definition uneven and can change over time).
To answer your question, when building a megabase or building all of the smelting arrays first... it probably makes sense to balance after the smelters. On the scenarios that I (and probably most people focused on bases going to the 1st rocket), it is quite possible to build for the "long term" (i.e.: use the full capacity unloader) but initially minimize the pollution footprint with only one line each of copper, iron and steel until after getting yellow science. Then use artillery to wipe bug nests from the zoomed out visible map, scale up (causing wild oscillations on demand) until the point where the unloaders are under full demand. In such a variable demand approach having the balancer at the unload end makes it easier to build once and forget. I hope that makes sense to you.
Anyway, the discussion about "why" falls outside of the purpose of the thread, so please use PMs if you have further questions about that bit.
Re: Challenge: Generic max-speed train unload
I like the bot unloading example but, by unloading from only one side, there is no time left to replace the train. As is, you would have the output belts alternating between compressed and empty, which defeats the purpose of a compressed belt design.. they need to be sustainably compressed. I think simply unloading to buffer chests on the right solves this problem.
I disagree with the comments on train length. If you can justify the cost of this setup for short trains, then the scaling to long trains too must be justified as the cost is per wagon. Also, this is overkill for short trains (see below).
Where this design shines, in my opinion, is very strictly in the fact that you can have four compressed belts cleanly stretching out to one side of (or perpendicular to) the station independent of train length. This is not the case with DaveMcW and timeshifter’s otherwise very excellent designs which, as the train gets longer, force belts farther and farther out to both sides before turning 90deg to stretch out parallel to the station - there is no room within the bounds of a wagon to jump the track with the other belts if there are four or more wagons. Or I suppose one side could route down and then across the track in one place to keep it perpendicular to the station. I don’t think this fact is sufficient to favour the bot unloader, and a parallel output can be designed around just fine. (With three wagons, two belts cross above, two belts cross below, and two belts cross through the central power poles.)
Unless I’m missing something, I think I’d stay away from wagon->bot->belt setups. Too inefficient.. too many moving parts.. too little gain.
Edit:
It occurred to me that I was doing my math with a 100 stack size. For raw ores, perhaps the four lanes is sufficient, though five to six is still likely better in a manner similar to what I show below.
In any case, just a thought, but if you are going to go with bots four compressed lanes seems to be an insufficient goal but six may make it worthwhile. Six gives about 4.6s to replace a train given a stack size of 100, if I have the math right. Is that sufficient given max tech, an occupied stacker, and nuclear fuel? If so, this parallel unloading station (unlimited wagons), merging a couple designs, may be what you're after. With raw ore (stack size 50) you'd have only about 2.3 seconds to get a replacement train, so this may be a bit ambitious for that use. On the other hand, if you're unloading red/green circuits (stack size 200) you have even more time and can consider a seventh lane.
I disagree with the comments on train length. If you can justify the cost of this setup for short trains, then the scaling to long trains too must be justified as the cost is per wagon. Also, this is overkill for short trains (see below).
Where this design shines, in my opinion, is very strictly in the fact that you can have four compressed belts cleanly stretching out to one side of (or perpendicular to) the station independent of train length. This is not the case with DaveMcW and timeshifter’s otherwise very excellent designs which, as the train gets longer, force belts farther and farther out to both sides before turning 90deg to stretch out parallel to the station - there is no room within the bounds of a wagon to jump the track with the other belts if there are four or more wagons. Or I suppose one side could route down and then across the track in one place to keep it perpendicular to the station. I don’t think this fact is sufficient to favour the bot unloader, and a parallel output can be designed around just fine. (With three wagons, two belts cross above, two belts cross below, and two belts cross through the central power poles.)
Unless I’m missing something, I think I’d stay away from wagon->bot->belt setups. Too inefficient.. too many moving parts.. too little gain.
Edit:
It occurred to me that I was doing my math with a 100 stack size. For raw ores, perhaps the four lanes is sufficient, though five to six is still likely better in a manner similar to what I show below.
In any case, just a thought, but if you are going to go with bots four compressed lanes seems to be an insufficient goal but six may make it worthwhile. Six gives about 4.6s to replace a train given a stack size of 100, if I have the math right. Is that sufficient given max tech, an occupied stacker, and nuclear fuel? If so, this parallel unloading station (unlimited wagons), merging a couple designs, may be what you're after. With raw ore (stack size 50) you'd have only about 2.3 seconds to get a replacement train, so this may be a bit ambitious for that use. On the other hand, if you're unloading red/green circuits (stack size 200) you have even more time and can consider a seventh lane.
Re: Challenge: Generic max-speed train unload
Which is why I find this whole thread pointless.
You want more time between trains. So one or 2 blue belts per wagon at maximum and that is a simple problem. Need more belts, use more wagons. Or more train stops.
You want more time between trains. So one or 2 blue belts per wagon at maximum and that is a simple problem. Need more belts, use more wagons. Or more train stops.
Re: Challenge: Generic max-speed train unload
Sounds kinda like you're arguing for massive steel furnace arrays when OP wants a slick beacon design. Neither necessarily wrong, but apples and oranges?mrvn wrote:Which is why I find this whole thread pointless.
You want more time between trains. So one or 2 blue belts per wagon at maximum and that is a simple problem. Need more belts, use more wagons. Or more train stops.
Re: Challenge: Generic max-speed train unload
Not really.Durentis wrote:Sounds kinda like you're arguing for massive steel furnace arrays when OP wants a slick beacon design. Neither necessarily wrong, but apples and oranges?mrvn wrote:Which is why I find this whole thread pointless.
You want more time between trains. So one or 2 blue belts per wagon at maximum and that is a simple problem. Need more belts, use more wagons. Or more train stops.
OP wants sustainability and usability. We could unload the buffer chests faster and fill more belts and make balancing the belts complex. But imho that cuts down on the usability. Getting the trains in fast enough into a single station is just to hard to be usable.
What is sustainable, usable and easy to build is simply to go bigger. More cars or more stations and less belts per wagon.
If you want to simply build the fastest train unload possible then throw out usability and viability. But then you have the original thread with a balancer attached to the output.
-
eradicator
- Smart Inserter
- Posts: 5206
- Joined: Tue Jul 12, 2016 9:03 am
- Contact:
Re: Challenge: Generic max-speed train unload
Yes, thanks to buffer chests. Uneven demand isn't any different than total buffer drainage here.zOldBulldog wrote:Nice compact design. I assume it keeps the unload chests even too, especially under uneven downstream demand.
Uhuhu. Feel it yet?zOldBulldog wrote:Anyway, the discussion about "why" falls outside of the purpose of the thread, so please use PMs if you have further questions about that bit.
Also your answer doesn't sound like you understood the point i was trying to make, but if you don't want to discuss that part i don't care either way.
Train-cycle-time is infact a major contraint on any high speed design (see also my thread [Experiment] Unloading 4 compressed blue belts per wagon.]). Doing the math again..., when unloading 4 belts you have a whooping 0.2seconds (3.2s if you use 12 unloading inserters) to get the next ore train parked [((20*50)/(40*4)) - (20*50)/(27.7*6)] because the inserters are only barely faster than the belts. With two belts (or double stack size) per wagon you get 6.48seconds (9.5s with 12 inserters), which is still quite difficult for "average" players.Durentis wrote:I like the bot unloading example but, by unloading from only one side, there is no time left to replace the train. As is, you would have the output belts alternating between compressed and empty, which defeats the purpose of a compressed belt design.. they need to be sustainably compressed. I think simply unloading to buffer chests on the right solves this problem.
"Burst" style factories aren't that bad actually. Assemblers require (almost?) no UPS when input starved, so a factory style where they're sleeping half the time, and high-speed when the burst comes isn't entirely useless, though probably out of the scope of the "average" player that the OP is speaking of. Lastly you want passive providers on the other side, not buffers.
The cost is not per wagon, and the design can not be scaled to arbitrary sizes with just one logistic network. This is because bots are largely inefficient at finding the "shortest" path and will waste too much power flying around in a larger network. With the increased power demand you need even more roboports, etcpp. Google any thread about something like "whole base network" vs "per product network".Durentis wrote:I disagree with the comments on train length. If you can justify the cost of this setup for short trains, then the scaling to long trains too must be justified as the cost is per wagon.
I must have missed that criterium in the OP :p. It is just the simplest design with good speed that i could come up with. "Simple" in the sense that it is somewhat easy to understand even to beginners (the only magic used being stack-size-override) and uses no circuits. Belt balancers are pretty much black boxes to beginning players as far as i can tell.Durentis wrote:Also, this is overkill for short trains (see below).
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.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Re: Challenge: Generic max-speed train unload
It isn't though. That's the easy part. You create a stacker and, signaled properly (a basic signal every couple wagon/engine lengths so trains can accelerate into the station from the stacker while the empty one is leaving), you can replace a train in a station in a couple seconds even from the furthest point in the stacker. All you have to do is keep at least one train in the stacker ready to go at all times. How is that hard? That's what trains do when they're directed to a single output station from multiple input stations! Your stacker just needs to be large enough to hold all the trains coming from your input stations to feed the output station.mrvn wrote:Getting the trains in fast enough into a single station is just to hard to be usable.
What's the difference between moving your "more cars" to a stacker in one station or to multiple inefficient stations as you would have them go to? Except that your way takes up more space and routes trains over a larger area (traffic congestion) to do (eventually) the same thing? And now, depending on how you lay out your multiple stations, your belts and smelters/assemblers are potentially spread out.mrvn wrote:What is sustainable, usable and easy to build is simply to go bigger. More cars or more stations and less belts per wagon.
I get it though.. I used to use multiple local output stations with the same name and a small stacker to feed them. They worked. They took up a lot of space. They weren't ideal.
A large stacker into a single very efficient output station is far more space efficient and traffic friendly than multiple inefficient output stations. Stackers facilitate simplified modular rail design.
I don't think fast unload stations are at all in conflict with or come at the cost, in any way, of usability and viability.mrvn wrote:If you want to simply build the fastest train unload possible then throw out usability and viability.
If I can get trains in fast enough from a stacker after a moment's prototyping, maybe it's not so hard after all? I tried a stacker with 3-6 trains.. random numbers, but worked great. Hell, even a 1-8 train accelerated a bit slowly, but still got there in a few seconds.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Challenge: Generic max-speed train unload
Correct. That is the single most important factor for this thread.mrvn wrote: OP wants sustainability and usability.
To feed a "1st rocket" base with the same unload station from the early stage where you might have a single smelter line to the rocket production stage where you are fully utilizing the unloader and possibly more than one unloader per ore creates special challenges. Challenges that most players who are playing at that level aren't quite experienced enough to handle successfully. My hope is for this thread to give them a few tried and true designs they can choose from.
That is why I focused on "the design must keep the unload chests balanced". By ensuring that a train won't be delayed waiting to unload due to a still full chest while the others already emptied, it allows flexibility in the base design sequence and let's players try different approaches as they develop their skills.
You also correctly point out the importance of moving the next train in before the chests empty. In my personal design I solve that problem by using short 1-2 trains and putting a regular signal behind the unloading train and chain signals up to the stacker, that way there can always be a train waiting and ready to move in at minimum distance. Plus I move up to better fuel once I can, so that trains are faster once I reach the stage where the unloader is running at full force. If I need more than 8 belts of an ore then I use a 2nd stop running in parallel (i.e.: first iron stop goes to main bus and Green Circuit bus, while 2nd iron stop goes to steel for main bus). Of course, there are other ways to achieve it, so it is good to discuss it.
Of course, the faster the unload the better, but TBH, 8 saturated blue belts (with the bot design) for a 1-2 train is more than I hoped to be possible. The only concern it gave me was that it requires reaching yellow science (for the buffer chests) before running out of local ores, but viable depending on your base building approach.
All possible designs that meet the criteria are valuable, different people will have uses for different ones. Keep them coming.
Re: Challenge: Generic max-speed train unload
Essentially the same math I did, except a cargo wagon has 40 slots, not 20. (Or is that a mod changing things on me?)eradicator wrote:... [((20*50)/(40*4)) - (20*50)/(27.7*6)] ...
"Burst" style factories aren't that bad actually. ... Lastly you want passive providers on the other side, not buffers.
And I pulled out the common factor to simplify changing variables:
(wagonSlots * stackSize)*(1/(beltUnitsPerSecond * numBelts) - 1/(stackInserterUnitsPerSecond * numInserters))
Burst style factories are fine if you can't manage to saturate.. I don't disagree at all. But not what was asked for so I'm trying to stick to that criteria.
Passive providers? Perhaps. Unless it's helpful to those belts to have them receive some from time to time. I haven't tested it that thoroughly. I don't think the buffer chests hurt anything and they cost the same. If a bot ever has to fill one, it was necessary.. otherwise they'll completely ignore them except to draw from them as passive providers. It would be bad if they drew everything out of passive providers and the belts dried up as a result. Or I completely misunderstand how buffer chests work. /shrug
I would agree if a station were anywhere near a full base in size. Despite allowing for "arbitrary size" I don't expect people would have trains so long that a station's local botnet couldn't be adequately supplied despite their limitations.eradicator wrote:The cost is not per wagon, and the design can not be scaled to arbitrary sizes with just one logistic network. This is because bots are largely inefficient at finding the "shortest" path and will waste too much power flying around in a larger network. With the increased power demand you need even more roboports, etcpp. Google any thread about something like "whole base network" vs "per product network".
Anyway, I'm not really criticizing the bot build. It's really good for what it does. I do really like it and that's why I tried to expand on it. It excels at getting four saturated belts off of one side but I see that as a stepping stone not an endpoint. My point was just that a station needs to do more than the four belts if it can. Your bot build enables this. If you don't exploit that advantage and stick with four lanes, my opinion is that the bot build is just too costly over other simpler options - in resources (and UPS?). Otherwise, I generally don't consider cost to be a factor. That's why I kept the bot build in my merged design despite its cost and bumped the station up to six lanes per wagon. Is it not a best of both worlds working together to achieve more?
Re: Challenge: Generic max-speed train unload
You can accomplish the same speed with longer trains in much the same way. Just put the basic (not chain) signals every couple wagon/engine-lengths starting at the station. As the long train pulls out of the station, its tail frees up one short block after another. This allows the next train to start accelerating into those blocks as the empty train leaves the station. By the time the empty train is clear of the station, the new train is coming to a stop.zOldBulldog wrote:In my personal design I solve that problem by using short 1-2 trains and putting a regular signal behind the unloading train and chain signals up to the stacker, that way there can always be a train waiting and ready to move in at minimum distance.
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Challenge: Generic max-speed train unload
Very cool trick, I would have never thought of it.Durentis wrote:You can accomplish the same speed with longer trains in much the same way. Just put the basic (not chain) signals every couple wagon/engine-lengths starting at the station. As the long train pulls out of the station, its tail frees up one short block after another. This allows the next train to start accelerating into those blocks as the empty train leaves the station. By the time the empty train is clear of the station, the new train is coming to a stop.zOldBulldog wrote:In my personal design I solve that problem by using short 1-2 trains and putting a regular signal behind the unloading train and chain signals up to the stacker, that way there can always be a train waiting and ready to move in at minimum distance.
-
eradicator
- Smart Inserter
- Posts: 5206
- Joined: Tue Jul 12, 2016 9:03 am
- Contact:
Re: Challenge: Generic max-speed train unload
That's what i get for doing it from memory. Also explains why my number in the other thread was different :D. So roughtly 9 seconds for 4 belts and dual-sided unloading. Not too bad i guess. With robots it might even be feasible to have a second paralell station with only passive chests to serve as a "backup" when the real train doesn't arrive in time (i.e. is a few seconds too slow).Durentis wrote: Essentially the same math I did, except a cargo wagon has 40 slots, not 20. (Or is that a mod changing things on me?)
That was meant for the chests on the other side of the wagon, where no inserters/belts are. I.e. where the infinity chests are in my picture. Passive providers have higher "input" priority than buffer chests as far as i know. And if you want somewhat even unloading they hopefully work better due to that. Dual-sided unloading generally has the problem that - unless you use a rather complex circuit to set the request amount on buffer chests - you're likely to get unevenly filled chests if the draw is uneven (which is what the OP was complaining about in my thread...).Durentis wrote: Passive providers? Perhaps.
I remeber an old MP map where we had a similar unloading station for L2C8-ish long trains. And two rows of ports were barely enough for that. So, just saying that it doesn't scale well for vanilla ports. If you have a mod that adds ports with smaller networks and can build a seperate network i.e. for each 4 wagons it would presumably work with a lot less bots and ports and electricity :). Also the requirement for robot speed/cargo research makes it not really good in early-game. No offense taken btw.Durentis wrote:I would agree if a station were anywhere near a full base in size. Despite allowing for "arbitrary size" I don't expect people would have trains so long that a station's local botnet couldn't be adequately supplied despite their limitations.
Personally i prefer more wagons over more lanes per wagon. The factory that the belts go to doesn't scale as well size-wise anyway, so if i'm gonna build a huge belt tree i might as well use more wagons instead. UPS wise i don't think the bots are an issue. Bots were pretty good before UPS wise, and splitters are still somewhat bad for UPS. But...OP says he only wants one of these stations, and use it for a starter factory, so UPS cost is moot anyway.Durentis wrote:If you don't exploit that advantage and stick with four lanes, my opinion is that the bot build is just too costly over other simpler options - in resources (and UPS?). Otherwise, I generally don't consider cost to be a factor.
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.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Re: Challenge: Generic max-speed train unload
Durentis wrote:It isn't though. That's the easy part. You create a stacker and, signaled properly (a basic signal every couple wagon/engine lengths so trains can accelerate into the station from the stacker while the empty one is leaving), you can replace a train in a station in a couple seconds even from the furthest point in the stacker. All you have to do is keep at least one train in the stacker ready to go at all times. How is that hard? That's what trains do when they're directed to a single output station from multiple input stations! Your stacker just needs to be large enough to hold all the trains coming from your input stations to feed the output station.mrvn wrote:Getting the trains in fast enough into a single station is just to hard to be usable.
Getting the train from the stacker to the station in 0.2s is impossible. Doing it in 3.2s is hard. I think you have to have a stacker, then a stretch where a single train can wait and then the station. The extra delay to get out of all the junctions in the stacker is too much. Unloading only takes something like 6 seconds. So you need to have a train arrive at the stacker every <10 seconds.eradicator wrote:Doing the math again..., when unloading 4 belts you have a whooping 0.2seconds (3.2s if you use 12 unloading inserters) to get the next ore train parked [((20*50)/(40*4)) - (20*50)/(27.7*6)] because the inserters are only barely faster than the belts.
Try doing all that with 4 or 8 car trains. Hmm, was scalability a factor for you?
Re: Challenge: Generic max-speed train unload
I know what side you were referring to. My response was referring to my build where they have stack inserters pulling from them. Pretty sure they're better as Buffer Chests in my build. In yours, yeah definitely insert into Passive Providers on the infinity chest side to give your train more time to cycle out provided it doesn't unbalance things too much for you given how the bots empty the chests.eradicator wrote:That was meant for the chests on the other side of the wagon, where no inserters/belts are. I.e. where the infinity chests are in my picture. Passive providers have higher "input" priority than buffer chests as far as i know. And if you want somewhat even unloading they hopefully work better due to that. Dual-sided unloading generally has the problem that - unless you use a rather complex circuit to set the request amount on buffer chests - you're likely to get unevenly filled chests if the draw is uneven (which is what the OP was complaining about in my thread...).Durentis wrote: Passive providers? Perhaps.
As for the imbalanced unloading thing. You can use a combinator trick to unload evenly but i don't think it's necessary and slows the unloading. Worse, it's not the unloading that's the problem, since it's already technically balanced, so much as how the chests are drained. There's obviously an imbalanced draw on chests in my build.. four lanes going out on one side and only two on the right. The Buffer Chests should balance somewhat on their own, I think, but likely require a higher number of requested items to do so (and more bots in the station) as bots don't like crossing the track unless they have to. This could also be a good reason to require Buffer Chests in your build.
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.
This is where the last build I posted in the orphan train problem thread comes into play:
Backed up output stations must have a sufficient local stacker to hold all trains assigned to them to keep the trains off of the network. When resources are in heavy demand again, the station will naturally recover. If the system runs out of resources (too many mines have dried up), trains will collect in the main stacker and the output station's unbalanced chests will drain (becoming balanced at 0).
Anyway, it's hard to say with infinity chests providing input just how messed up the station can potentially get with real train usage.. I'll try to hook it up to a train network sometime and see what happens. But I suspect the worst case is that the buffer chests just need to request more items (like 4k) to stay balanced.
I fully intend to use this in actual games going forward. I suspect I'll start with both sides using DaveMcW's 2-lane unloader on both sides until I reach bots and then transition into this.
Re: Challenge: Generic max-speed train unload
Yes. And not necessary.mrvn wrote:Getting the train from the stacker to the station in 0.2s is impossible.
No. Do it as I suggested above with the close signals. You can have a stretch but it's not necessary. A train can be right behind the one in the station but still mostly in its stacker lane if necessary.mrvn wrote:Doing it in 3.2s is hard. I think you have to have a stacker, then a stretch where a single train can wait and then the station. The extra delay to get out of all the junctions in the stacker is too much.
Sounds reasonable. And not difficult to accomplish given enough mines.mrvn wrote:Unloading only takes something like 6 seconds. So you need to have a train arrive at the stacker every <10 seconds.
Yes. With adequate mines, the number of cars, within reason, becomes irrelevant. Scalability is definitely a factor for me. That's partly how this design (and what I posted in the orphan train problem thread) have come about. And if you take the time to figure out how they tie together instead of saying over and over again how things are impossible or too hard to attempt, you may learn something that will change the nature of your future games. Or not. I dunno. /shrugmrvn wrote:Try doing all that with 4 or 8 car trains. Hmm, was scalability a factor for you?
The trick is not to make the output station require 8 car trains before having the mines to fill them quick enough. No cart before the horse nonsense. The whole system has to scale up together. Train size, mines / input stations, smelters / output stations, the main stacker, rail network bandwidth/lanes. (See Avoiding Orphan Trains.)