Train Overview - Only 1 Train Per Schedule

[Skotty]

Based on the new Train Overview, I take it most players don't set up their train networks the same way I do. With the new Train Overview, train "schedules" are shown on the left-hand panel, and all trains for any selected schedule show up in the right-hand panel. This doesn't work out so well for me, as I rarely ever have more than 1 train on the same schedule, so the right-hand panel is mostly wasted space. I thought it might be interested to discuss how I set up my trains, which has always worked well even in a very large base, and see what thoughts others have on it. Can anyone convince me I should do it some other way? Also, you might just find this interesting, if you have never done it this way.

Here is how I set up my trains:

First, some terminology for the discussion. Consider a "site" to be a place where trains come and go from that produces a single item. Thus, in most cases, there are one or more input products to the site (usually more than one), and one output product. However, in the case of a mining site, there are no input products, as the input is coming from the mining drills.

When I set up a site, I set up a lane for each input product (uniquely named), a lane for the output product, and a few sidings for trains in waiting. After the site is constructed, I create one train for each input lane; those trains are uniquely assigned to supply that input lane. That's the core of my network design, and it means I almost never have more than one train on the same schedule, as each train has a unique station it is supplying. Rarely ever do I need more than one train to supply an input; in almost all cases, I find a single train can keep that site supplied with the input product.

When setting up the route for a train supplying an input, it is set to stay at the uniquely assigned input drop off station until it's cargo is empty. When picking up more product to deliver, on those stations there are multiple criteria for leaving the station: one criteria being if cargo is full, but usually at least one other criteria for leaving before cargo is full so that it shares the resource with other trains better if the site is not producing enough product to meet demand.

With this setup, the input lane for an input a train is assigned to supply is essentially that trains parking spot. If the site isn't very busy, the train will remain parked in the input lane, waiting for it's cargo to be empty. That's fine (and normal), because I typically only need that one train on that input, and the train doesn't consume resources while parked. If I really need an extra supply train for one input lane, I will create an extra siding for the extra train to park on when the site slows down. All other sidings at a site are for two purposes only -- to provide parking for trains waiting to pick up supplies from the output lane, and a parking spot for my taxi train when I'm personally visiting a site.

I think this is inefficient in terms of number of trains, as I will have a lot of trains just parked on slow inputs. But the trains aren't really that expensive to build, and they aren't consuming resources while parked, so I don't really have any issue with all the parked trains. I suppose another possible problem is too many trains active at once may be a possibility potentially causing deadlocks on the highways, if I push my mega-factory to it's limit with research, but in practice I've never run into this problem.

So that's it. Each train dedicated to a single input lane on a single site. That's my network. No fancy controls, and it has always worked well. At this point, the only thing that doesn't seem to work well for me is a Train Overview that categorizes trains by schedules, as each train's schedule is unique due to it's input lane assignment.

I suppose if the devs wanted to discourage this behavior, they could make trains far more expensive to build, or make them consume fuel while parked, as those things would make me reconsider my setup. But I kind of like it the way it is. It would be nice, though, if this isn't something devs want to discourage, if they could add multi-select of schedules on the Train Overview (where it shows trains of all selected schedules on the right-hand pane).

[blazespinnaker]

I rarely ever have more than 1 train on the same schedule

I don't see how that could possibly scale unless you have freakishly long trains that you process like belts (which would be cool, as that's how it's done IRL).

For example, say you have an ore patch 256 chunks away. By the time one train gets to the patch and back, it's going to bring a limited amount of ore (or plates / steel / gears if pollution is not a problem, but the problem really is mostly the same). With speed modules and beacons, it's pretty easy to process the entire set of ore for that train in the time it takes to do the round trip. As I go further afield, I have to add more and more trains to a route and queue them up in a stacker - to the point that without the overview it would be nigh impossible to manage.

I suppose you could use a hub/spoke design where you set up temporary factories and then tear them down when local patches run dry. I was doing that for awhile with belts (which were previously better than trains, imho), but with the the latest train additions that is unnecessary, tedious and frankly unfun compared to setting up multiple trains per route.

You could of course get to a point where production bonus is so high and you're patch frequency & richness is high enough to leverage local patches for quite awhile - but why use trains? I'd use belts, especially with the new dragging behavior, very easy to lay out. In that scenario, yes, train complexity is not required.

On top of that, you have a certain pub/sub architecture via the new additions that you can work with here if you felt so inclined. I'll avoid discussing that further as it's optional depending on base architecture.

Also, might I suggest you give railworld a try? It's unfortunate though that we can't dial down the ore frequency even more. Kinda weird that we can't. Railworld could be a lot more railworld. Also, for throughput, try playing around with the train stop Set Train Limit with a decider combinator. Very simple, very clean, very powerful.

[Skotty]

Maybe my sites and overall base are smaller scale than what others are doing. To give you an idea of my base size, here is a link to a screen shot of my first base back when I was playing version 0.17 (can't access it now as it won't upgrade my 0.17 worlds and blueprints, but I still have this old screenshot). This base was running smoothly on the same train setup. My latest base on 1.1 is not as big yet, but I suspect it will end up about the same.

I would guess my bases just aren't as big as others make. This one had 4 rocket silos and I could keep those and research running at a satisfactory pace. Can't tell how many research domes I had from this...maybe 30 domes with some beacons and modules. My base does tend to be somewhat idle at times when I'm out fighting bugs and expanding my borders.

First base (0.17) screenshot: https://flic.kr/p/2kASzwB

[blazespinnaker]

Nice, very tidy. I tend to be a bit more haphazard, but it is DW marathon railworld (with no water) so that's been a challenge. I also like to grid the map with roboports and radar. That's a personal quirk, I guess.

viewtopic.php?f=204&t=96040

It takes about 44M copper ore to tech up artillery range (128K SP). I should use more prod modules.
https://kirkmcdonald.github.io/calc.htm ... oFlHP6P7w=

My big thing right now is trying to create encapsulated city blocks which are supplied solely by train stops/stations. Once I have that, I should, in theory, be able to copy/paste the city block, drop down trains and paste in their routes - automatic added production. The city block train map (in theory) should be fairly copy/pasteable it self as it's just a grid of railways.

The only effort will be seeking out new ore patches and placing down miners, fending off biters from these outland forward posts. As laser damage techs up, that'll probably be less of an issue tho.

So far it's working as planned. The city blocks do work as copy/pasteables, and the train GUI makes managing the supply routes a snap. The issue now is mostly optimizing throughput and dealing with sneaky biters blowing up my trains.

As an example:

rcgc.png (1.49 MiB) Viewed 4202 times

By pasting this into a city block (2x2 chunks), I automatically 'subscribe' to iron / copper plates and plastic, which are being produced by other city blocks. And the block 'publishes' RC and GC. I use a combinator plugged into set train limit to make sure that a block doesn't pull in trains if it has enough / not enough resources. This was overly complex before the train gui. Tracking trains was a pain.

I'm not entirely convinced the 2x2 layout for a block is best, though. I'm reconsidering the optimal layout for the city blocks. Something much wider and shorter (4x2?) may be more optimal to allow for very long trains to drop off. Throughput issues caused by lots of small trains seems like something that could be better dealt with.

And oil, for some reason oil is 3x required versus ore, which is 2x required in expensive mode. I have a lot of oil on the map, but using fluid wagons may add to the throughput issues. Currently I'm piping until my artillery is up enough to wipe the biters off the map, as they are very irritating. I've had to turn off the alert sound as it no longer stops. /evolution is 0.9954, about half of that is pollution and the other half is spawner kills.

I am currently using logistics for a few thing (yeah, I broke down), like train fuel and artillery shells, plus the odd thing here and there. I plan to remove all that eventually to make way for a mod I'd like to create which is explained further here - viewtopic.php?p=533995#p533995

[Skotty]

So, funny thing. I took over a year off from playing Factorio and have started playing it again. I returned to my own habits, and set up my latest base in the same manner as I did over a year ago, and was wondering again about the train overview, how I only have a single train per schedule, and how other people set up their trains. So I searched the web and found this post, and thought, wow, this person sets up their trains exactly like I do. Then I realized I wrote it myself over a year ago. lol.

Anyway, I'm still using the same train set up, and it works just fine. I'm thinking maybe I should try scaling it to an extreme to see if and how it becomes a problem, but frankly, so far, it still works great. But I think I'm going to search around more and see how others are using trains, as the way I'm doing it has to be uncommon given how the UI doesn't work well with it.

Here's another screenshot of my typical train stations, this one from my newest world: https://flic.kr/p/2o2tjta

[shopt]

I'm not sure if you are asking, but here's a common way other people use trains.

For this to make sense, the first thing you need to understand is this:
* Trains navigate based on stop name. They only remember the stop name in their schedule, they don't use an internal stop ID or a map coordinate, the stop name is all that matters. They will navigate to the "closest" stop which has the name of the next stop in the schedule.
* Multiple stops can have the same name. Even if they are in completely different areas of the map.

The next thing to realise is that you don't really care where a resource came from, only what the resource is.

So that leads to a common setup where, for example, all your iron loading stations have the same name (eg. "iron-L"). And all the places where you need to unload iron also have the same name (eg. "iron-U"). And then you just set trains to go full load at iron-L and full unload at iron-U. With this approach you need to use some circuitry to set the train limits at each station based on whether there is enough there to load a train, or enough room to unload a train. So you just set trains to go from "wherever there is iron ready" to "wherever needs iron" rather than from specific sources to specific sinks. And that approach is one that the train overview screen aims to support.

That's not to say that your approach is wrong. Most bases start with your approach of 1 train per schedule. But once you start getting multiple sources of an item and/or multiple places it could go to, then 1 train per schedule starts to become inflexible. If you have slow mines, you can end up with lots of trains idling while they slowly load. Fewer trains could have done the job by naturally alternating between whichever site has a load ready. You may also have a very productive site where 1 train can't make the trip fast enough and it backs up. If you combine those you can end up with one flat out train that is not keeping up while other trains fill up at snail pace somewhere else.