Routing trains to specific stops

[The_LORD_thy_GOD]

Mods that generate train schedules often want to send trains to particular stations, even in the absence of unique station names. However, train schedules send trains by station name and can't target particular stations.

In 1.x, mods like LTN would work around this by adding the coordinates of a nearby rail to the schedule, then the station. This would ensure that the train was sent to the correct target station, even if not uniquely named.

With the addition of priority in 2.0, this method no longer works reliably, as if there is another station of the same name with higher priority, the train will be rerouted away from the target coordinates to the higher priority station.

I therefore suggest that an API change be made (perhaps a `stop` field in `ScheduleRecord`) that would allow a train to be routed via API to a particular stop unambiguously.

[curiosity]

Duplicate of viewtopic.php?f=221&t=100216

And your thread title is bad. A station is the name. A stop is the entity in the world.

[The_LORD_thy_GOD]

Changed the title.

I don't think it's a duplicate, though. All of the information and developer responses in that thread are no longer valid due to the introduction of train priority. This is a new issue that was solvable in 1.1 but isn't in 2.0.

[Sharparam]

And your thread title is bad. A station is the name. A stop is the entity in the world.

The API uses station both to refer to the entity and the name (in different places), so it's not very consistent.

[curiosity]

The API uses station both to refer to the entity and the name (in different places), so it's not very consistent.

The API is not known for its consistency.

[The_LORD_thy_GOD]

With the addition of the new and very helpful LuaSchedule API, I thought it would be a good time to raise this issue again. Having to use intermediating rail stops causes fundamental issues with the builtin priority and train limits systems.

Being able to schedule a train directly to a specific stop would be an ideal fix. Even an ignore_priority flag on an entry, forcing old nearest-stop behavior, as a workaround would be a significant boon.

[robot256]

Are there any cases where you need script-route-to-specific-stop action *and* priority routing of vanilla schedules to the *same* station name? What if there were a prototype flag to hide the priority controls on a train-stop entity, so that it could be disabled completely for LTN stops? That doesn't help if vanilla stops share the same name as LTN stops but that's a more reasonable thing to make the user change.

The really ugly workaround is to set the priority of every stop with that name to 0 whenever you add it to a schedule. Or to keep track of which stops you care about and reset the priority whenever the GUI closes on one of them.

[The_LORD_thy_GOD]

For Project Cybersyn we have considered various workarounds, up to and including just forcing the priorities of all same-named stops to 50. Ultimately we settled on issueing a warning when a controlled train lands at a stop with priority not equal to 50.

We have simply been telling people not to use priorities with the mod, but that is an unfortunate situation as they are now a built in feature and we would rather cooperate by reading the priorities and using them to inform the logistics. Unfortunately that is not possible currently.

Having people rename stations so the namespace don't overlap is certainly a workaround but I think falls quite short of a good solution.

[Harag]

Temporary rail stops directly in front of the actual target stops to achieve dynamic point-to-point deliveries have always been a workaround. With the additions the rail system has received over the years that workaround has accumulated a lot of drawbacks (for further discussion let's use 'delivery manager' instead of a specific mod that makes use of them).

UI issues

A minor nuissance is that trains don't appear in the actual target stop's UI as incoming trains until they have already arrived.

Limits

Trains heading for a temporary rail stop don't count towards the limit of the actual target stop.
This can easily lead to a deadlock if a train that was not sent by the delivery manager also has the stop in its schedule:

1. The delivery manager inspects the limit, sees there's one slot left and sends a train to a new temporary rail stop (which doesn't reserve the free slot at the target)
2. Now another train starts heading to the target stop via its normal schedule and reserves the slot
3. The delivery manager's train arrives at the temporary rail stop first and must wait for a free slot at the target stop
4. The other train arrives and waits behind the delivery manager's train and can't free the slot

Also, with schedule interrupts there now always is a second control system that can create dynamic schedules. That makes this scenario much more likely.

Priority

As Lord already said, setting different priorities outright breaks temporary rail stops as a workaround for point-to-point schedules.
If another stop with the same name as the intended stop has a higher priority, the train planner will simply re-path there after reaching the temporary rail stop.

Vision

Here's my attempt to define some actionable requirements how the propsed field `stop: LuaEntity?` could affect scheduling:

• the train planner skips finding the nearest stop by name and always picks the stop designated by the field
• priority is ignored, there is only one possible destination (but the delivery manager could evaluate and prioritize deliveries with it)
• limits apply as usual
• temporary applies as usual
• removing the stop makes the schedule entry defunct (and should probably no-path the train)
• renaming the stop does not change the path and can always be reflected in the UI, even with other stations having the old name
• the UI could add the prefix "Direct: " and use additional backdrop colors, say, blue for direct and light-blue for temporary-direct