Please extend the TrainScheduleRecord to allow changes in direction

[mrvn]

TL;DR

Add an option to the TrainScheduleRecord that allows trains to change direction when looking for the next destination when the record has no wait_conditions.

What ?

A TrainScheduleRecord with no wait_conditions switches to the next record when the breaking point reaches the destination. The train then tries to extend the path it is on to the next destination. If a destination is found that extends the current path (by at least one extra rail) then the train continues it travel without slowing down. But this ignores all stops that do not extend the current path or are connected to the rail itself.

Extend the TrainScheduleRecord with an option that makes all directions and distances valid for such a case. This would allow a train to pick a station connected to the rail directly but also allow the train to stop and reverse direction to reach a stop that is closer than extending on the current path. Trains should also reverse their direction without being stopped for one tick so inserters don't load items accidentally.

Why ?

Say I have a train stop like this:

overview.png (1.37 MiB) Viewed 2898 times

Using the train stop directly trains can only approach the train stop from the bottom. Trains coming from the top have to drive past it and do a U-turn someplace and then approach the station from the bottom. This is because TrainScheduleRecords with a train stop have a direction.

When multiple stops with the same name exist there is no way to send a train to a specific stop. Instead the train has to be send to rail as a waypoint and then to the stop. LTN does this by sending the train to the rail the stop is connected to like this:

path0.png (1003 KiB) Viewed 2898 times

The TrainScheduleRecord LTN uses has a wait_condition of "0s passed". This makes the train break and stop at the rail for 1 tick and then continue to the real stop, which will always be the closest. Well, not always. Since the TrainScheduleRecord LTN used had no direction trains could approach it from the top and then pick a totally different stop that is closer than doing a U-turn and approaching the stop from the bottom. The fix for that was recently added to set a direction on the TrainScheduleRecord.

But that still has problems. The train will stop for 1 tick at the rail before continuing to the train stop. In that 1 tick inserters can load items screwing up the manifest of the train when it actually arrives at the stop. To fix that a TrainScheduleRecord without wait_conditions would be better. But then the train stop connected to the rail is ignored leading to a path like this:

path0b.png (1.35 MiB) Viewed 2898 times

For LTN and similar mods it would be nice to turn of the distance restriction for extending the path.

bi-directional trains

Using the train stop directly trains can only approach the train stop from the bottom. Trains coming from the top have to drive past it and do a U-turn someplace and then approach the station from the bottom. To allow trains to approach the stop from the top a waypoint must be set that drives the train past the stop far enough so that it can reverse directions and ends up at the stop like this:

path1.png (1.35 MiB) Viewed 2898 times

This would be a far better option than doing a U-turn somewhere far off. But for this to work, so that the train will reverse directions, the TrainScheduleRecord need a stop with a wait_conditions. This also runs into the problem that for 1 tick the train is stopped and inserters can load items into the train.

Next consider what this means for a train coming from the bottom. It would also stop at the waypoint:

path2.png (1.36 MiB) Viewed 2898 times

For trains coming from the bottom a TrainScheduleRecord without wait_conditions would be far superior as the train would drive right through and only break for the final stop. This would avoid having the train stop on the east-west lane causing congestion.

Summary

I'm asking for a TrainScheduleRecord that allows sending uni-directional and bi-directional trains to specific stations using waypoints that don't have the train stop at a bad place or interact with inserters for 1 tick.

PS: I know there are changes to the trains in the works for the extension that probably solve the first case. But I'm unsure if the second case with bi-directional trains has been considered as well.

[robot256]

> This also runs into the problem that for 1 tick the train is stopped and inserters can load items into the train.

This is (almost) easy to fix by making the inserters wait for a train to be present at the correct stop.

It sounds like you are asking for a conditional wait condition, where the train would calculate if it would get to the following destination faster by coming to a complete stop and then reversing, or by moving through at speed.

Much simpler would be a mod that can remove the wait condition if the train is approaching from a certain direction. For example, your maybe-reversing waypoint would be two train stops with the same name. The one facing the same direction as the next destination is fed a "waypoint only" signal. The mod detects when a train is braking to approach that particular station and removes the wait condition in the schedule before the train slows down.

[mrvn]

> This also runs into the problem that for 1 tick the train is stopped and inserters can load items into the train.

This is (almost) easy to fix by making the inserters wait for a train to be present at the correct stop.

No. Inserters that are left holding items in the hand from a previous train will insert them into the cargo wagon ignoring in that 1 tick regardless of any enable/disable condition as that is only checked at the beginning of a swing.

It sounds like you are asking for a conditional wait condition, where the train would calculate if it would get to the following destination faster by coming to a complete stop and then reversing, or by moving through at speed.

You can describe it that way.

Much simpler would be a mod that can remove the wait condition if the train is approaching from a certain direction. For example, your maybe-reversing waypoint would be two train stops with the same name. The one facing the same direction as the next destination is fed a "waypoint only" signal. The mod detects when a train is braking to approach that particular station and removes the wait condition in the schedule before the train slows down.

If you can call that simple.

[boskid]

Won't implement.

It makes completly no sense to have a waypoint record and allow pathfinder to start looking for a path in reverse before a train arrives here.

First of all, if a path would abruptly start moving in the opposite direction after being extended by such logic, trains movement code would crash because a rail would be given to enter but that rail would be already behind a train. There is an assumption that at any point in time if there are 3 rails in the rail path object, rail direction from second to first is different as the rail direction from second to third. That means it makes no sense for the waypoint logic to append a reverse-going path into a current path when the braking point would reach a waypoint.

Lets assume i would handle this case super carefuly: i would allow the trains pathfinder to look for rails in the opposite direction but if it would happen that a reversing path would be given, i would force a train into ARRIVE_STATION state so it first approaches the waypoint, stops at it and then starts driving in reverse. But there are no guarantees that the reversing path is even possible for the train as the train when repathing is doing a search from its 2 ends (when stopped) which almost always are on 2 different rails (train cannot be modeled as a single point in space, unfortunately).

100661-a.png (117.83 KiB) Viewed 2860 times

This also does not cover cases where a train can approach a train stop in one of 2 configurations (having its tail on one of 2 rail legs) where from first configuration a certain train stop would be available and from the other it would not be.

100661-b.png (241.16 KiB) Viewed 2860 times

One could say since its a path extension logic for the waypoint i already have a path on which the train will be arriving, i have a train's length so i should be able to accurately go back couple of rails back on the rail path object to pinpoint the exact rail on which the train would be if it would stop on the waypoint so the reverse search would be accurate for deciding if a train should stop and reverse or if it should go past the waypoint. This approach has a corner case when a train itself is longer than the length of the rail path because in that case the rail a reverse search would start on is not in the path but it is under the train itself (not part of the path object as the path only ever goes from the train's end up to the destination). This corner case is also possible to solve but entire value added of this logic is basically to let a train be able to stop at a waypoint if there is path in reverse better than a path when going forward past the waypoint without stopping.

I am just not going to implement this. It feels like making a core hack to allow a mod hack do its hacks abusing core mechanics by provided core hacks. If you want a two directional stops, this logic currently does not exists so if you have a nice solution that would solve this i may consider it, but trying to abuse a rail target waypoints with reverse/no-reverse logic is a no-go. There are so many other, more likely solutions to consider, like what if a schedule record added by a mod would have not a rail target, but a train stop target (so there would be 3 options: station name, train stop entity, rail entity). That would pinpoint a train to going into one specific train stop without a need for a waypoint. It would properly make the trains count on the train stop include the arriving train, it would show the train in the trains overview gui. Issues it would create would be that such train would not show on the per-station-name list but it would show on the list of trains with given train stop in the train stop gui. What if a mod would be able to provide a whole vector of train stop entities and a localised string to show on the schedule record in the locomotive gui so a player is not faced with a record saying "one of train stops [1,51], [327,653], [111,223], [333, 445]" but a nice "closest depot for 1-4 train". Those options are not something i would implement immediately because they would have to be considered if its even worth adding them, what are their pros and cons etc..

[mrvn]

I didn't ask for the path to be extended in the case the logic decides to reverse directions. So you don't end up with a path that suddenly changes direction. Rather the opposite. Even if the path can be extended to some stop it should simply not do so when there is a (potential) stop that is cheaper when reversing direction at the end of the path (if the flag is set in the TrainShceuldeRecord).

Lets assume you handle the case very sloppy, handling the train as a point. The braking point reaches A and you see that the bad "B" stop is closer and don't extend the path. So the train switches to ARRIVE_STATION state, breaks, ends up at A and then asks for a path to "B". And oh, there is only one B reachable going straight ahead. Lets wait at the signal for it to open up.

Same for your second example. The train ends up at A and then depending on where it ended up it either finds a path to B or not. Given that there is no way through the A station that is the current behavior anyway.

So, nothing bad happens. Nothing breaks. At most the train breaks when it could have driven through loosing a bit of time. Setting the option in the TrainScheduleRecord for this comes with the risk of the train breaking only to find out the potentially closer stop isn't a valid one. If you don't want that risk then don't set the option.


You have already shot down the suggestion for trains to be send to specific train stop entities because then trains would have to remember that they are locked into a single stop entity and saying the rail target already solves that problem.

Except it doesn't, not without side effects like activating inserters. So what are mods to do that want to send trains to specific stops? Force the user to name all stops uniquely?


So please reconsider implementing this or at least parts of it. The request has 3 parts:

1) allowing trains to target train stops connected to the targeted rail
2) have trains skip the 1 tick stopped state
3) allow breaking and reversing direction

The 3rd part can be done using a rail target and 2 extra train stops by mods. Not nice but possible. I see no way to work around 1 and 2 in mods.

[boskid]

Lets assume you handle the case very sloppy, handling the train as a point. The braking point reaches A and you see that the bad "B" stop is closer and don't extend the path. So the train switches to ARRIVE_STATION state, breaks, ends up at A and then asks for a path to "B". And oh, there is only one B reachable going straight ahead. Lets wait at the signal for it to open up.

Signal here is more like a sign to tell that there is some penalty to the train stop on the right. It could be a penalty anywhere on the right. The issue would be that from a player point of view this case would look like a train which has a waypoint which it should not stop at, it stops at it and continues straight forward only because there was some train stop a little bit closer from the train stop point of view but not from the train point of view.

You have already shot down the suggestion for trains to be send to specific train stop entities because then trains would have to remember that they are locked into a single stop entity and saying the rail target already solves that problem.

I shot down the suggestion when a schedule record would point to a station name (which is a short description of a vector of train stops which all share the same station name) as i do not want trains to be pinned to one specific target from the list of all possible targets. What i suggested by talking about a schedule record with a train stop (or vector of train stops) is also not making a train pinned to one specific target from the list of all possible targets. It would still be able to choose on its own to which targets it would be going, but a mod could adjust the schedule itself to reduce set of train stops. If a mod would only put one train stop here, it would not be pinned to any train stop, it would just have only one possible target to which it could go. Distinction is subtle but it goes around how trains are choosing their candidate goals. Changing list of possible targets (part of schedule) is doable. Making train to disregard list of possible targets when one of them was already choosed is not allowed since a list of possible targets may change run-time and train should react to this.

Having all train stops with unique names is preferred solution.

ad 1/ This is doable, i would have to back-port some of the changes to 1.1.x branch.
ad 2/ No.
ad 3/ No.

[mrvn]

Being able to specify a list of train stop entities to target in a TrainScheduleRecord would be great. Even better than being able to only specify just one.

[Optera]

Temp stops are a workaround for targeting train stops by unit_number rather than ambiguous name.
Instead of trying to fix the workaround, I'd rather have the ability to tell the scheduler to go to a specific stop regardless of name.

[curiosity]

Inserters that are left holding items in the hand from a previous train will insert them into the cargo wagon ignoring in that 1 tick regardless of any enable/disable condition as that is only checked at the beginning of a swing.

This seems like a much more realistic thing to ask for.