[2.0.12] Train does not move between stops with same name (MR)

[carcinized]

What did you do?

Build two train stops with the same name, e.g. Test
Build a train
Give the train a schedule that contains "Test" twice, with some condition, e.g. 5s inactivity
Set train to automatic.

Screenshot_20241029_230024.png (9.28 KiB) Viewed 1438 times

What happened?

The 5s inactivity condition begins flashing extremely rapidly (on both stops in the schedule) and the train does not move.

Screenshot_20241029_230132.png (3.25 MiB) Viewed 1438 times

What did you expect to happen?

The train moves between the two train stops, respecting the conditions. This was the behavior in 1.1, see e.g. this YT video where somebody uses it to make a train advance https://youtu.be/HzpUQZIr15g?feature=shared&t=2010 (timestamped link).

This behavior is very desirable because it allows you to build e.g. a defense resupply train which will simply visit all enabled defense resupply stations and use an interrupt to refill itself back at base. There are many cases where one might want a train to travel between stations with the same name.

Does it happen always?

Yes, it's easily reproducible. Setting train limits to 0 or disabling either train stop does not affect the behavior.

[BorisOZ]

This is intended, and not a bug. You are telling the train to go to a station, and it is currently at that station. Why would it move?

To achieve the functionality you desire, check out this post viewtopic.php?f=18&t=117059

Basically what you want is to have circuit logic that disables the train stop when it no longer requires resources. Then the train will move off automatically, either when the interrupt is triggered because it is empty or the train stop it is at gets disabled because it is full.

Alternatively, use circuit logic to disable the stop when there is a train on the way to it. The train will still stop as normal and not leave until the conditions are fulfilled, but will correctly move off to the next location. This may result in the train running in a loop if it is easier to get back to the previous stop than to go to a different one.

[carcinized]

Please do not respond without first reading the post and verifying any solutions you offer. This is very rude.

As I posted, when a train has two of these stops the conditions will rapidly flicker, I doubt that this is intended and this indicates that this is a bug. Furthermore, I could not find documentation anywhere that this behavior is an intended change, as this behavior worked fine in 1.1 and was widely used there. Also, I do not see any reason for the current behavior to be desirable as it just results in trains getting stuck.

Second, your proposed solution does not work, as I have just verified ingame. If the station the train is at is disabled/has train limit 0 (which are the same as of 2.0), it will still not move and the bug still occurs.

[Snirp]

Second, your proposed solution does not work, as I have just verified ingame. If the station the train is at is disabled/has train limit 0 (which are the same as of 2.0), it will still not move and the bug still occurs.

Yeah I am having the same issue, I was already disabling the station as I expected that to be the problem but it still won't move to the new station. Already posted a bug report about this specific issue but it isn't approved by a moderator yet.

[robot256]

Disabling train stops does not work anymore. The "disabled" state is analogous to seeing the limit to zero. Telling a train to go to the station or is already at, but now has limit 0, may be an undefined operation--the described behavior implies that the old reservation is not released before the train "re-arrives", so it never checks the new limit value.

It's worth getting the devs to check if this is the intended behavior, but also in this application another method should probably be used. The easiest is to add a "waypoint" stop in front of each station and add it to the schedule with no conditions. This will force the teain to leave the first stop and release its reservation, pass through the waypoint, and them search for a new stop with open slots.

[carcinized]

I am fully aware that disabling train stops and setting the limit to 0 now do the same thing. This is not relevant to this bug report as the bug occurs without using train limits (as I have stated in the original post), and the change to how disabled train stops work should not have had any effect on the behaviour as it existed in 1.1.

I do not agree that another method should be used in this application. Adding an extra station in front of every station is an unintuitive workaround when the 1.1 behavior was perfectly intuitive and worked well for many people. Interrupts actually make this behaviour even more desirable in 2.0, because it would allow you to set up a defense resupply train with an extremely simple schedule.

And, for the third time, the rapidly flashing conditions and the train not moving without any "no path" or "destination station full" indications make it pretty clear that this behavior is not intended.

[Kalanndok]

the described behavior implies that the old reservation is not released before the train "re-arrives", so it never checks the new limit value.

Actually that's exactly what happens if I recall one of the FFFs correctly.
A departing train only clears its reservation once it has left the block in which the station resides.

Which then in turn leads to the described side effect that the train would not depart since it has a valid reservation to the station it is still sitting at.

[robot256]

Several other reports are potentially caused by the same behavior:

viewtopic.php?f=7&t=118530

viewtopic.php?f=7&t=118733

[Niedzwiedzislaw]

If the station the train is at is disabled/has train limit 0 (which are the same as of 2.0), it will still not move and the bug still occurs.

I thought so too, but it seems to not be true. Limit for disabled station is 0/None which is very different from a station with limit 0/0. Moreover, solution from BorisOZ works and if you set limit to 0, the train eventually goes to next station. But using circuits and requiring energy seems not intentional. Enable/disable was supposed to be simple.

But back to the topic. I experience the same behaviour. Blinking condition certainly seems like unintended behavior. And intuitively, when I set multiple stations with the same name I'd expect the train to move from one to another rather than stay at one. I would even argue that having just a single station in schedule shouldn't make the train stop.

I wonder what's the underlying issue. It looks like the train tries to leave station but immediately decides that it arrived at destination. And completely ignores that the station is disabled. However it respects station limits and when it is 0, then the train correctly leaves.

10-31-2024, 20-55-55.png (724.89 KiB) Viewed 1236 times

[BorisOZ]

Please do not respond without first reading the post and verifying any solutions you offer. This is very rude.

Apologies, I was slightly wrong. I just realised I was using interrupts, not just one station in the schedule. Screenshots below, it still requires stops to be set to 0 train limit when you don't want the train there anymore. Disabled doesn't seem to work correctly, and I believe this is a bug. FFF-395 seems to suggest that a disabled train stop behaves the same as a train stop with limit 0, but it currently does not.

I also believe it's a bug that a train does not move on from its current station if that station is at its train limit/disabled and it is meant to go to a station with the same name. Especially seeing as it works fine with interrupts, I wouldn't expect the behaviour of the two to differ.

As I posted, when a train has two of these stops the conditions will rapidly flicker, I doubt that this is intended and this indicates that this is a bug. Furthermore, I could not find documentation anywhere that this behavior is an intended change, as this behavior worked fine in 1.1 and was widely used there. Also, I do not see any reason for the current behavior to be desirable as it just results in trains getting stuck.

I believe this behaviour is desirable, but I guess that is a matter of opinion. If I am telling the train to go a station, and the station it is currently at matches that, I wouldn't expect it to move. Or, I have a train and the only station it has in its schedule is a pickup station. I then have an interrupt which triggers when cargo is full and chooses the correct dropoff station. With the old mechanics this wouldn't work, as the train would continually cycle between all of the pickup stations and not stop. You could make it work by adding the cargo full requirement to the stop as well, but then both your interrupt and schedule both have the same condition which is redundant.

Remember interrupts only trigger when a train has met the conditions for leaving the current station, so what if you wanted an extra interrupt that can trigger while you're at that station but before the cargo is full? For example all my trains run the same pickup and dropoff schedule, but I also have a special station as part of it that loads in goods to deliver to my rockets to go to my space platform. The train loading is done via circuits so I know I have the correct amount of stuff on board, and then I have an interrupt that triggers to send the train to the correct station. I could again put the circuit signal both as a condition for leaving the station and as the condition in the interrupt, but again that adds redundancy. If I want to change one of them, I have to change both, which defeats the purpose of all these QOL additions that are designed to reduce the number of individual changes required.

You would have identical behaviour by only having the stop in the schedule once, except it wouldn't flicker. The reason it is flickering is because it has both reached the station you told it to go to and passed the condition of being inactive, so it just keeps switching between them on each tick. But the train doesn't actually move anymore, I believe because of train reservations.

A departing train only clears its reservation once it has left the block in which the station resides.

Which then in turn leads to the described side effect that the train would not depart since it has a valid reservation to the station it is still sitting at.

As far as I can tell, this is exactly why it is happening, but is also the cause of the train not leaving when the stop has been disabled or set to 0. But again, this works fine when you use interrupts, so I don't know why the behaviour is different.

Train interrupt

This train has nothing other than this interrupt, and it behaves as expected when the train limit of its station is set to 0. If the station is at limit=0, the train will move off. If the limit>=1, the train will stay. Disabling the train stop doesn't work.

11-01-2024, 10-28-23.png (86.58 KiB) Viewed 1186 times

Also, I just noticed that manually sending the train to a station it is currently at will also move it forward if the train limit is 0. I believe what happens with this and with interrupts is that it clears the current reservation before going to a new station, though the station itself does still see the train as being there for train limits and such until the train clears the block. Not exactly sure why this behaviour is different to that of normal schedules.

There's a few inconsistencies with trains at the moment, maybe all of it is intended but for some things it is hard to tell.

[CatCattyCat]

Also facing this problem, I think this is the root cause of viewtopic.php?f=18&t=118092 , but they might be two different issues?

Disabling the stop the train is currently at does not solve the problem - the train still won't path to a different station of the same name even though it's the only valid station. Attached an example of this.

I agree that this behavior is not intuitive to me - it doesn't occur if the stops are named differently. Why would that change train behavior? I expect the train to try to the path to the station with the provided name, and in the railway I've set up there's only one valid, enabled stop to go to. It happens to have the same name as the existing stop, and the existing stop is even disabled.

Moreover, it's important to me to have the station names the same. In my real factory, I want to name all the stations where I need a certain material with the same name and have the train only go to enabled stops.

[tappi]

I also hit this. I made a supply train stop at the heart of my base and 10+ train stops for wall supplies. I had to make a bunch of "Idiot train" trainstops right after all the wall supply stops to force the train out of the disabled stop and to make the trains work again to repath to other enabled stops.

[wvlad]

Same issue for me, disabling train stop doesn't work

[Loewchen]

Ref.: 119828, 118733, 118530
See as well: 79303

[cQfvCf57K]

The moment I tried to build similar thing, I faced the same issue.

Setting station limit to 0 or disabling it, that was suggested above, doesn't trigger train to leave.

The only workaround is to build "exit station" in front of "station". But it has to be some distance away from the "station" (more than 1 block of rail) otherwise the train will keep rerouting to the same station again, even with limit set to 0.