Train station priority to complement train station limits.

[Sopel]

TL;DR

Ability to define "producer" and "consumer" station priorities.

This outlines the general direction. I expect to have some discussion here on improvements and potential problems that could arise.
Note that this feature may not have been considered before because it doesn't make sense without train limits.

What ?

The proposition is to add 2 independent priority values to each station. "consumer priority" and "producer priority". They should default to the same value (say 0). They could be togglable and disabled by default, if disabled then use the default value. They could be circuit controlled but it doesn't seem essential.

1. consumer priority
Whenever a train looks for a station named C to path to it considers all the stations named C in order of descending values of "consumer priority" (i.e. higher priority served first). If two priorities are equal then the order is implementation defined. This would have observable effects when there is shortage of trains going to C - only the stations with highest priority will be served.

2. producer priority
Let L be the list of all trains trying to leave (before pathing) any station named C at any given moment towards any station named P (in other words, all trains currently potentially competing for a destination). The trains from the list L shall be processed in order of decreasing "producer priority" of stations where they are stationed. If two priorities are equal then the order is implementation defined. This would have observable effects when destinations are saturated with trains - trains from stations with lower priorities will not be dispatched.

Why ?

"consumer priority" may aid in reducing the risk of running of out resources at places critical for base operation, for example power stations. Currently the solutions not involving global circuit networks or mods like TSM/LTN are either to have dedicated redundant lines for critical places, or using 3-item schedules that first visit prioritized stations. These solutions are not ideal because they reduce the throughput and increase rail traffic.

"producer priority" is essential for handling byproducts. This is not as much of a problem in vanilla, where only oil processing can be considered to have [avoidable] byproducts, but is a very real problem with mods like bob's, angel's or pyanodon's (they are more or less impossible to play comfortably without either TSM or LTN) where byproduct recycling is critical. Not prioritizing byproducts can result in increased resource voiding or even deadlocks/blackouts. Currently the only way to prioritize byproducts over the rail without having a global circuit network (or a mod like TSM/LTN) is to have dedicated reloading stations that use pumps/splitters to prioritize one input over the other. This approach creates a choke point for all resources of a given type as they have to be funneled to a reloading station for priority management - doesn't scale. Some more distributed variations like for example doing the priority splitting at endpoints by having two consumer stations for each resource wherever it's needed are possible and do scale, but in the worst case they result in twice the amount of stations and a lot of buffered resources.

Mods like TSM/LTN would continue to have functionalities important to a small set of people, but vanilla would allow easy and intuitive railway management sufficient even for the most complicated mods.

[boskid]

Producer priority is of an issue because the train could repath while being already on route, so for this to work properly train would have to copy this value and keep it when traveling. It would require some form of central management of trains and coordination so when a train with a producer priority of X is on route and another train with priority X+1 wants to leave a train stop, first train would be... rerouted to somewhere else?.. only so the second train with higher producer priority gets a priority... i do not like this idea.

Consumer priority has some hidden costs related: first of all, trains pathfinder as currently implemented does not allow to add a target train stop penalty. All the penalty sources can be only due to rail segments or due to junctions between two rail segments. This would require doing some changes to the trains pathfinder itself. Second hidden cost would be that by having train stops A and B (of course with the same station name set on both of them) but with different consumer priorities like A and B (lets assume A < B). If for any reason B would not be reachable from a given position, trains pathfinder would be able to find a path to the train stop with priority A, but since it is not the highest one, it would have to keep searching through the whole rail network because maybe there would be a path to the train stop with priority B. This would give quite a lot of performance impact.

Current "hacky" solution is to use multiple dummy train stops in front of the target train stop to artificially increase the penalty to this train stop, however this also has its performance impact because the trains pathfinder will be overexpanding the rails network "because maybe there is a path that avoids penalty from those train stops".

[Sopel]

Producer priority is of an issue because the train could repath while being already on route, so for this to work properly train would have to copy this value and keep it when traveling.

I guess travelling trains could have the highest priority. Otherwise they could end up stopping anywhere on a repath if they are beaten by a higher prioritity train.

It would require some form of central management of trains and coordination so when a train with a producer priority of X is on route and another train with priority X+1 wants to leave a train stop, first train would be... rerouted to somewhere else?.. only so the second train with higher producer priority gets a priority... i do not like this idea.

When a train is travelling already it would not be concerned with priorities anymore. In particular new trains would respect the current state regardless of priorities. Priorities would only be relevant when making a decision, they would not be able to influence previous decisions.

Consumer priority has some hidden costs related: first of all, trains pathfinder as currently implemented does not allow to add a target train stop penalty. All the penalty sources can be only due to rail segments or due to junctions between two rail segments. This would require doing some changes to the trains pathfinder itself. Second hidden cost would be that by having train stops A and B (of course with the same station name set on both of them) but with different consumer priorities like A and B (lets assume A < B).

I was thinking more in line of "perform N pathfindings, one for each priority in use for given station name". This does have additional costs when multiple priorities are concerned indeed. Not sure what could be done about this. One could speculatively launch multiple pathfindings [for different priorities] concurrently to alleviate that at least somewhat.

If for any reason B would not be reachable from a given position, trains pathfinder would be able to find a path to the train stop with priority A, but since it is not the highest one, it would have to keep searching through the whole rail network because maybe there would be a path to the train stop with priority B. This would give quite a lot of performance impact.

Are the reachable stations not known in advance?

Current "hacky" solution is to use multiple dummy train stops in front of the target train stop to artificially increase the penalty to this train stop, however this also has its performance impact because the trains pathfinder will be overexpanding the rails network "because maybe there is a path that avoids penalty from those train stops".

This should either have an elegant solution or none at all.

[Sad_Brother]

Current "hacky" solution is to use multiple dummy train stops in front of the target train stop to artificially increase the penalty to this train stop,...

Why use "hacky" "dummy" solution when you can allow signal to add needed penalty to the path directly?

Producer priority is of an issue because the train could repath while being already on route, so for this to work properly train would have to copy this value and keep it when traveling.

As far as I understood Producer priority to be used only if "on the way" trains are not enough to fill destination's limit.

Consumer priority has some hidden costs related: first of all, trains pathfinder as currently implemented does not allow to add a target train stop penalty.

Priority is not penalty.
Train need a station:
1.Get list of stations
2.Exclude wrong names, limited, unreachable...
3.Exclude not highest priority
4.Select best route.
If need to reroute repeat all steps.

I do not think myself as smarter than you or anything. Just trying to explain.

[boskid]

I guess travelling trains could have the highest priority. Otherwise they could end up stopping anywhere on a repath if they are beaten by a higher prioritity train.

I think i know what was that i did not like in this: in general it would work only when multiple trains repath at the same tick and in that case the trains would have to repath in a specific order. In general that would be a bad idea but it could work in case of a limited train stops when all train stops are full (so there may be multiple trains screaming "destination full") and when the slot opens, the trains would repath in their producer priority order. That could be done... i will think about this.

I was thinking more in line of "perform N pathfindings, one for each priority in use for given station name". This does have additional costs when multiple priorities are concerned indeed. Not sure what could be done about this. One could speculatively launch multiple pathfindings [for different priorities] concurrently to alleviate that at least somewhat.

This is worst possible implementation possible, because if pathfinder would be running for every priority once, it could visit the whole rail network multiple times which is bad for performance. It would be far better to make trains pathfinder aware of priorities so in worst case it would visit the whole rail network only once, and a/ if goal with highest priority was reached, stop pathfinder as nothing better will be found b/ if highest priority is unreachable, every reachable rail segment would be visited once and after all of those, choose the train stop to which there was a possible path that has highest priority. Not good but also not tragic.

Are the reachable stations not known in advance?

Reachable train stops are not known in advance. That would be a lot of unnecesary data to store for every rail+direction to keep the information about all the train stops if they are reachable from a given rail, and a lot of update logic to keep in consistent. All of those would be useless anyway as the only penalty of having unreachable train stop in the possible targets list is the penalty of overexpanding in that direction due to heuristic guiding expansion in that direction, but the trains pathfinder will tell "no path" anyway if that would be the case - visiting every rail network node at most once.

Why use "hacky" "dummy" solution when you can allow signal to add needed penalty to the path directly?

This is a separate idea in itself. What i am not sure about is if signal extra penalty value would be provided by the circuit network: when the value would be changed, some repath events would be required or the trains would behave a weird: any other repath event could change the path to be completly different and because those repath events could happen a lot later of the penalty change it would be not obvious to attribute those path changes to the signal penalty value change.

Priority is not penalty.
Train need a station:
1.Get list of stations
2.Exclude wrong names, limited, unreachable...
3.Exclude not highest priority
4.Select best route.
If need to reroute repeat all steps.

What you described is exactly telling that priority is a penalty. If a priority P (lets assume they would be from 0 to 10) would be given a penalty of (10-P)*X where X is a value larger than any possible penalty of a path inside of rail network, then the priority is just a penalty: if the train stop with priority P=6 (meaning penalty of 4X) is reachable, then the train stop with priority P=5 (meaning penalty of 5X) would never be reached (no repeat all steps in your list) due to the higher penalty.
It would work just as penalty but could be implemented in a specific way to avoid some sources of performance penalty (like searching whole rail network to find a path that avoids this unavoidable penalty) - normal pathfind would be performed until the path to highest priority train stop would be found or when the whole rail network was visited, it would return the path to the train stop with highest available priority.

--

Looking at this idea in general it looks the "consumer priority" would be relevant only when there is less trains on route than possible slots: in that case it would shift the trains to go to the higher priority train stops first.
The "producer priority" would be relevant only when there are more trains than possible slots: when a slot would open, repath order would be determined by the priority so the if there are lets say 3 trains trying to leave but in "destination full" state, the one in the train stop with highest producer priority would be first to repath to the newly opened slot and would be first to leave.
Possible issues would be when transitioning from the "producer priority" to "consumer priority": when all the train stops would be full and a single train would be saying "destination full", this would be a state for the prioducer priority to work, however if a train stop limit would be increased (lets say by circuit network) by 2, this single train would be able to find a path but now there will be a one empty slot that could be of higher priority than some of the others train stops. This would require introduction of a new repath event for some trains so one of the trains going to lowest priority train stop would be forced to repath to the highest priority train stop to fill the gap.
In general it would have to have a train stealing repath event when a train stop with higher priority would get an empty slot, so one of the trains going to a lower priority train stop would be forced to go to the train stop with higher priority.

[Sad_Brother]

Why use "hacky" "dummy" solution when you can allow signal to add needed penalty to the path directly?

This is a separate idea in itself. What i am not sure about is if signal extra penalty value would be provided by the circuit network: when the value would be changed, some repath events would be required or the trains would behave a weird:

Signals already add penalty and controlled by circuit (when closed). Just penalty value cannot be changed. Imho no need to add new repath events.
But yes. It is another idea. Thanks for answer. If you think about it that is enough for me. I do not like when developers use "hacky" ways.

What you described is exactly telling that priority is a penalty.

Except priority allows not to calculate some routes. And not need "a value larger than any possible penalty of a path inside of rail network".
I am not sure could you find unreachable before actual routing. But at least you can route higher priority first and stop earlier.

[Nosferatu]

Consumer priority could be implemented by giving us a "skip next schedule if condition is met" feature.

The high priority stops would be listed first in the schedule. If they are full (train limit) or disabled they get skipped.
Low priority stops would be scheduled for leave when empty. Which is already true if the train has emptied itself on a high priority stop...

[disentius]

Would adding the possibility to assign a (circuit network) configurable path penalty to stations be a viable option? Similar to the penalty of a signal closed by the circuit network.

[Nosferatu]

@disentius:

trains pathfinder as currently implemented does not allow to add a target train stop penalty. All the penalty sources can be only due to rail segments or due to junctions between two rail segments. This would require doing some changes to the trains pathfinder itself.

But i would appreciate a "penalty signal" that you can configure using the circuit network.
At the moment I use normal signals for that. But they also block the train when set to train so you need to build something to unlock the track when a train wants to drive through...

[disentius]

Ah, I missed that, thanks.
Yeah i use the signal penalty to divide trans too.

[boskid]

I was thinking about this and i will not implement it. It has quite a lot of weird cases like increasing limit on a priority train stop would require to repath some trains that are going to lower priority train stops under the same station name. It is not that critical to have it implemented in base game itself: i was able to create a circuit network priority scheme where i have 2 train stops with limit and because trains count can be read to circuit network, when all train stops with high priority are full (C >= L) the low priority train stops simply set their limit to not zero. It basically requires 1 constant combinator + 1 decider per priority train stop and 1 constant combinator + 1 decider per low priority train stop (1cc+2dc in case of middle priority). It has some tiny limitations because trains going for a high priority train stop can repath to a low priority one but other than that it works reasonably.

[Koub]

[Koub] Moved to Won't implement subforum.

[danbopes]

I understand this is in the not implemented, but I wanted to put a take on this, in the hopes it can be reopened (Instead of making an entirely new thread).

I think the one thing for me that sets back the train system in vanilla is the need for priorities, and I do believe a lot of the things mentioned here are a bit overkill/complex. I'd like to offer a simple solution, that I think would solve the mega-base needs:

A priority signal for provider train stops (Or for the train itself, since it's schedule is tied to the high-priority station): If a train is waiting ("Destination Full" message), when a station opens up, trains will always be provided from higher priority stations first. Currently, adding train stops/pathing tweaks doesn't really help with this, it still does a round robin. For example, in the mod space exploration, I could have a station that provides coal from the core power drills first, and the train will sit there with a full load ready to go. When a station opens up, I would like it to provide from that station first. Right now, I don't have anyway to really do this effectively without involving 3rd-party mods that are overkill.

[Koub]

I don't know if the issue behind this suggestion will be taken care of, but we've had recent news that there would be some improvements on the train system with the expansion, let's wait and see, before we reactivate anything.