mrvn wrote:Switch your load and unloads around so the output of one item is on the same side as the input of the same item for the next stage. E.g. unload the electronic circuits on the side where you load them for the advanced circuits. Or unload iron plates where you load for steel. Makes the belts have far fewer crossings (pre logistic robots, for bots it just reduces the distances).
Also I wouldn't put copper inside the iron/steel loop.
Yeah, basically it was a rough mock-up so to get the basic idea across. The exact "grouping" of departments for profiting "neighbouring" departments for the next stage are something that obviously need to be tweaked.
mrvn wrote:Overall though with this design why use trains at all? Just replace every rail with belts. I think the advantage of rails is that you can move many different goods over the same train line, unlike with a belt where a mixed belt quickly leads to one item deadlocking the belt.
I'd say because each Express belt is limited to a maximum of 2400 Units/Min. So you will have multiple parallel Express Belts for each resource type going from the Depot to the Department and for the finished Product to be moved back to the depot.
A rail track only uses 2 tiles width... a train can load much more and can do the trip several times a minute. So eventually the bulk throughput of the train should hypothetically outperform the belts. Also like you wrote yourself... because you can load the various source items into the same train.
That said I get what you are trying to point out and it might actually not be a bad idea to do a direct comparison between using belts or using trains as "interconnect". Would at least be interesting to see what turns out to be easier or more efficient.
vanatteveldt wrote:- Why concentric loops and not just one loop per product? That should make it a lot easier to expand processors, and you can still locate stations so e.g. green unloading and green loading share chests or at least are close together?
Hypothetically you could only do one loop per product with several loops next to one another... but then you will have to stretch the Depot which acts as crossbar so that every department can connect to the depot. The further you stretch the depot... the longer it takes for bots to travel from one point to another... which requires a lot more bots to keep up with the increasing throughput since a lot of them are just busy traveling around.
It might not be that much of a problem though, except if you are short of energy.
vanatteveldt wrote:- It will be a challenge to write good train timetables. If you want to combine dropping off and picking up, you want to have mixed trains (i.e. resources for blue circuits are green circuits, red circuits, and sulphur), and ideally you would load and unload them simultaneously. This requires good thinking to make sure that trains don't needlessly drive around (i.e. if output cannot be unloaded because buffers are full, train should not go) but at the same time preventing e.g. an overflow of sulfur from blocking the rest of the ride.
Yeah the timetables are an issue, I looked a little bit into it myself yesterday evening but then I was too tired and said "screw it" and went to bed. So it still is an open issue.
I got it to work that trains unload and load simultaneously, but I ran into some obvious problems on how to prevent to overstock a department with a certain resource.
Maybe some kind of circuit network intervention might not be avoidable... but somehow I'd hate that... because wiring up the entire base sucks somehow.
vanatteveldt wrote:- Given how logibots work, it might be worth having multiple depots, e.g. a ore/plate depot, a plate/circuits depot, and a advanced goods depot. I think the ore-plate-circuits could also work fine without logibots, but it would certainly make things a lot easier and more compact.
Well I don't think that splitting the depot really works too favorably, because of how some recipes like concrete even require Iron Ore as resource. So you would have to make a connection between the Ore Depot and this and that and whatnot... and yeah that's why I came to the idea that is one might be better off to dump everything into one large depot and draw from that central spot... then you are guaranteed that you will have what it takes without additional weird side-routing or other bypassing.
Also while drawing from the central depot it is easier to have "priorities" between different departments... since you have a central stock and can make it work so that departments only get resources if a certain threshold of resources are in the central depot, temporarily suspending several low priority departments if other things are more important. That said a local cache in each department wouldn't be a too bad idea... means it can run longer even if the central depot is out of stock in peak demand times.
mrvn wrote:I see two ways to solve this:
1) have cars per good in the ratio needed for the recipe, e.g. 2 iron plate cars and 3 copper plate cars for electric circuits
2) have mixed cars with stacks reserved for all goods in the right ratio. Wastefull since some stacks will be empty going one way and the others empty going back.
Also have the number of loading and unloading buffer chests in the right ratio so that a full set of unloading chests will fill all the loading chests.
1) is nasty with Productivity Modules... the ratios are thrown off.
2) mixed cars is what I went for in the first try.
First I didn't set any filter and rather let the train wait at the depot to load a certain amount of resource items onto the train with "Resource Item > xxx" condition while at the same time waiting for the train to unload the finished good completely with "Product Item = 0" condition.
And in the department I did the same but vice versa... waiting until "Resource Item = 0" and "Product Item > xxx".
Obviously I ran into overstocking problems... and eventually the train couldn't unload/load anymore. Literally my approach went down like this from the Development explained in Gifs Thread when you think that the easy shortcut will do...
As second try I looked into setting a filter for each slot in the train cars... but that's where I lost it and went to bed then. And I agree that might turn out quite wasteful since you also need to reserve slots for the finished product which needs to be delivered back to the depot which are empty while delivering resources to the department and vice versa... decreasing overall throughput.
Trying to control it over the chests is in my opinion a little bit too fiddly.
vanatteveldt wrote:Ratios become a lot less neat with productivity modules added in :-S
E.g. according to helmod, green circuits is copper:iron 1.07:1, blue circuits from ores is sulfur:plastic:iron:copper approx. 1:7:39:46. Of course, if all chains are trivial (i.e. consist of one recipe) this doesn't hold, but not sure I would want to be transporting copper cable etc separately.
Mixed cars with stacks is lot of hassle and lower throughput, but for e.g. blue circuits you could have e.g. 3 copper, 2 iron, and 1 mixed car for input, and output only into the copper car (since input:output for blue is about 30:1, you really don't need a lot of space for output
. Green circuits is less extreme but still 3:2, so you probably have a 'spare' car)
Yeah... trying to work with ratios is basically out of question. The mechanic to prevent overstocking etc has to work without considering any ratios (or at least considering ratios should only be for fine tuning the efficiency, but not to make it depend on it).
But yeah, the Input:Output ratio is better for later recipes... but for easy recipes where Input:Output is 2:1 or 3:2 or something it's quite ugly.
1:1.2 (considering PM3s) is quite easy on the other hand because if you input Iron ore you get almost as much Iron Plates back onto the train.
Overall said... I might think that this is a case where reading the rough Train Contents of the train by connecting the Train Station to the Circuit Network would really help... because if you already have a certain amount of Items in the train then you can prevent inserters from inserting more until they get unloaded the next time. So the train might drive around with a mix of Resources/Products and only loads to fill what has been consumed. Also the Circuit Network numbers can be easier tweaked to match Productivity Module stats much better than it would be trying to do that over a vague slot ratio.
Updated Diagramm adopting the
"one loop per product" idea:
- Central Depot B.png (57.58 KiB) Viewed 6102 times