Factorio Forums

TL;DR

I believe the train scheduling system could benefit from the ability to optionally apply boolean logic operators to stop selection, just like how it can be applied to wait/interrupt conditions, to allow players to heavily optimize train networks in ways that currently either aren't possible or require an unreasonable amount of circuit network manipulation.

What?

By default, the train schedules will have "then" selected, just like how conditions have "and" by default. In this state, trains act as they do now. However, clicking it will cycle it between "then", "and", and "or" (or bring up a selection menu).

I am not suggesting that this is where you should actually put the button. I am not a UI designer. OR operator:
When multiple stops are linked with OR, the train will just choose between them as if they were all stops with the same name. AND operator:
When multiple stops are linked with AND, the train will visit all of them in any order

Why?

OR Operator:
I've found in many instances there were certain schedules I wanted to make that were seemingly impossible without it, mainly when dealing with trains of mixed sizes. If I wanted an "iron unload" station that could accept trains of different sizes, and another that only accepted small trains, as it is, I can't have the smaller train treat both sizes of station the same. Another case I've ran into was when wanting to mix 2-headed and 1-headed trains; I would like 2-headed trains to visit both pull-through stations and back-out stations while 1-headed trains only visit pull-through stations. Ultimately, it boils down to the fact that in 2.0, this setup, which at least for me is desired surprisingly frequently, isn't possible without horrendous double-headed train pathing abuse:

• Train A sees Station A and Station B as the same
• Train B doesn't

However, that's not all. As of right now, this less common but still common thing isn't possible:

• Train A sees Station A and Station B as the same when choosing next destination
• Train A waits for condition A at Station A, but waits for condition B at Station B

That is, unless you want to break out the circuit network and use it to emulate your desired wait condition—or shove all possible wait conditions for each optional station into the single wait condition while reading a constant combinator signal ID for each station to disambiguate the and decide between them and then translate all of that into conjunctive normal form (which means comparing with the station ID in every term of the expression, which is incredibly annoying). I feel both of these are overkill and too inflexible to be a good solution for such a simple task, especially once multiple trains get involved.
Closely related are interrupt conditions. While not as prominent, as players don't always check what station a train is at when using them, it's still something that would be made more flexible and easier to set up when it's relevant.

AND operator:
While this doesn't technically allow for schedule types that aren't possible now aside from some really esoteric ones that I'm not sure are practical, I personally have found that the addition of interrupts has made it so my trains are a lot less predictable and are more susceptible to:

• being unexpectedly and significantly closer to the station it's going to next than the station it's going to currently
• having to wait for other trains to leave the station it's currently going to while the next station in its schedule is completely open.

This isn't an issue for trains which just move single resources around because order matters in that instance, but the second a train starts carrying around resources to and/or from multiple stations at once, suddenly it would be much more efficient to be able to rearrange the order while guaranteeing all still get visited.

Unlike the functionality of the OR operator, I'm not entirely sure this behavior is even possible to recreate reliably in 2.0, circuits or not. If it is possible to make a circuit network that tracks where trains are and signals to them to reorder their dispatch, it would would absolutely be unjustifiably complicated for something so incredibly simple conceptually and would not be expandable at all, requiring manual tweaks every single time the rail network was changed whatsoever.