patent whale
Game version: 2.0.9
OS: Win
Steps to reproduce:
Wrong behavior:
multiple branches show up with [1] over time due to traffic. Some end up never routing.
Expected behavior:
All queued branches should clear based on time triggered in order queued.
Map:
Prague - standard map
rugged rivet
The [1] on the signals at all times is because the block (your platform 4) is always occupied. To fix this you would need to add more blocks between you yard and the platform or shorten the path between them. You give your trains 5 minutes to get rfom the yard to the station, but due to the distance it takes them ~6 minutes. You need to remember that trains in shunting mode can go only 30km/h so your 200km/h yard does nothing. To fix it you need to shorten the tunnel and add signals, leave 7 minute gap between trains, or redo the yard as a whole. Example of a fix is in the attached save (I redid the yard).
patent whale
The [1] on the signals at all times is because the block (your platform 4) is al...
Thanks for explanation and example, my concern was with the fact that when 2 trains tried to leave at roughly the same time, it would queue up and only the 1st would actually leave. In that time a 3rd train would queue up and leave, but the 2nd train still would not even though it had the [1]. This would get progressively worse with a 4th train and 5th train until multiple trains would be ignored all showing [1]'s finally ending in a total jam with all tracks blocked.
I ended up working on various other solutions until I managed to get what I thought was the fastest way. Instead of using the Stabling sensor at the station I keep the train speed high until just before entering the yard with Shunting sensor. Worked well enough to drive 30 trains per hour (tier 3 unlock)
weak gustBOT
Issue RR-4344 has been assigned to this thread.
https://bitrich.youtrack.cloud/issue/RR-4344
Ahmad Zaher Alhafi
keen dome
.
muted niche
@patent whale Indeed if there is some bottleneck in the network, so the capacity is lower than the need, delays start to rise and the overall delay (sum of the delays) rises as well. The question here is how the delays are distributed to the trains.
In each internal cycle of the game we iterate over the Signals and check if they have a queued route that can be executed. As this iteration is always the same, some signals are preferred over the others. So the delay distribution favores some trains while others are in a special situation called starvation.
Indeed it would be better if the way how we check the routes prevented this situation but it pops up only when things are going really bad. Moreover, this part of the network would get stuck anyway, but in a different way and maybe slightly later. The overall delay is the same no matter how it is distributed among the trains.
So, if the capacity of the stabling yard is sufficient, minor delays may occur but they resolve themselves eventually.
If the capacity is insufficient, delays rise until a deadlock in any case.
I would say the better rebalancing of the delays is not worth the complexity it would bring, the risk of errors it may cause and the performance impact it would bring.
As we have a penalization cap (no train gets more penalty that its reward), from the game perspective it is better to have one badly badly delayed train than to have all trains uniformly delayed.
