Unfair train scheduling

[drdozer]

In nearly saturated train networks, it is possible for trains to never get scheduled. Illustrated in this video:

https://youtu.be/Spbf4LOtmc8

The behaviour i expected was for fair or randomly fair scheduling. The behaviour we get is that one or more trains is always blocked by others so never moves.

[Nosferatu]

Why would that be needed?
Trains don't have feelings. They won't be upset if they have to wait forever for their turn.

If you feel different you could try to work against that with some combinator magic

[Zavian]

(Continuing from my comments on youtube. But restating everything here for clarity for people reading this thread).

Your example setup is fairly artificial because it guarantees that only one train can be in transit at any time.
You are also severely short on available empty stations that trains can path to.

I think that anytime an empty train can't leave a station because there is no available destination to path to (or it can't clear the current station station in a reasonable amount of time because of network congestion) then that signals a design issue, and something for the player to solve.

I think that is the main cause of the issue in your example setup. You have multiple trains not able to clear their stations because there is no empty station they can path too, exacerbated by a network that only allows one train in flight at any time.

Here is a more reasonable test setup, that allows 3 trains in flight, and hence opens up more empty stations. With this type of test setup you can test with 1 train, 2 trains or 3 trains in flight at any one time. 1 and 2 train setups have problems, but 3 trains have enough open stations open that everything runs smoothly (at least for me).

train-setup.png (1.92 MiB) Viewed 2794 times

[drdozer]

I made a contrived example to illustrate the edge case. However, I made it because I had hit this edge case entirely by accident in two different playthroughs with entirely normal rail topologies, one was one-way and the other two-way. Trains never getting a turn can block key unload stations that kill the factory and in turn the playthrough.

I believe this would be fixed if the tiebreak applied to trains was wait time rather than train ID. This would give on average fair scheduling in these kinds of situations and a more repeatable and intuitive over-all train network behaviour that didn't depend upon what order bots placed things.

[Nosferatu]

Having random train order would fix your problem for a while. But eventually random will strike and your key unloading station will block itself again.
Good luck debugging your problem with randomness mixed in...
Better use train limits or other tactics to prevent this from happening in the first place.

As far as I know:
Currently no train is aware what the other trains want to do.
What you ask for would make it necessary that all trains do all pathing logic in random order.
Although I don't know a specific problem this would cause, I guess it would make debugging train related bugs harder.

[mmmPI]

In nearly saturated train networks, it is possible for trains to never get scheduled. Illustrated in this video:

the network is saturated already i would say if you have more train than free space for them to go, then it's impossible for all of them to move at the same time which will cause some trains to block others potentially cascading into trouble.

I believe this would be fixed if the tiebreak applied to trains was wait time rather than train ID

I don't think this would solve all cases, when you only have 1 free space for trains to go you ask the game to solve this puzzle but with a more complex setup :

train4isstuck.jpg (343.83 KiB) Viewed 2731 times

You cannot always solve this puzzle by moving the pieces "fairly" if you consider 1 move per piece depending on which pieces you start with, sometimes you can like if you start with the piece 6 but sometimes you can't, if it's the turn for piece 1 or 4 for example

More space available for trains to go is required to allow more train moving at the same time similar to making the puzzle easier by removing some square on the grid or increasing it size.

[JimBarracus]

I believe this would be fixed if the tiebreak applied to trains was wait time rather than train ID. This would give on average fair scheduling in these kinds of situations and a more repeatable and intuitive over-all train network behaviour that didn't depend upon what order bots placed things.

Instead of using wait time the number of unsuccessfull repaths could be used.
After a certain number a notification could appear.
"path blocked" for example.

[MEOWMI]

In most scenarios, the end result would be that most trains just stop as the factory backs up, until that one key train can move again, to supply that last missing part of the production cycle. After that, a similar train cycle might repeat as the factory kicks into action again.

If you claim that the average throughput you get through this rail system is still sufficient, then this behavior you observe shouldn't matter too much. The only issue that could happen is that your instantaneous throughput is too sporadic, which means you need larger buffers, either bigger trains or extra chests at the origins and destinations. Longer trains also helps in the sense that they have higher throughput on a rail compared to multiple smaller trains. In addition, it's also worth noting, that the need for additional buffers in itself is often seen as a hint that something else might be wrong, in this case the design of the rail system, if the train traffic is the limiting factor.

Of course in worst cases, this situation could still mean that a mission critical resource such as power plant fuel is delayed for so long that your entire base stops, but that's still a case of insufficiently large buffers, only if the average throughput is sufficient to begin with. If the average throughput isn't enough, then there's nothing to save that system, it will sooner or later cause the factory to back up due to traffic, or if you're unlucky as in our example, a complete blackout due to a lack of power.

At any rate, this is a situation where you're close to reaching the maximum capacity of your rail system. It's always worth building in a decent amount of leeway into your systems if you haven't carefully calculated it, because otherwise you risk being severely bottlenecked if you wing it and if there end up being multiple unexpected factors that slow it down. Of course, it still takes some experience to know how to actually build-in that leeway, but being able to tell "is this clearly enough?" is easier than answering "is this (almost) exactly enough?"

[drdozer]

Instead of using wait time the number of unsuccessfull repaths could be used.
After a certain number a notification could appear.
"path blocked" for example.

I do like the idea of an unsuccessful repaths warning. I don't have a feel for what a good setting for this would be, but it would be easy to have the threshold in a setting somewhere. While that wouldn't have fixed the issues I was hitting, it would at least have alerted me to them much earlier on.