[kovarex] [0.17.7] Disabling waypoint between train & train-breaking-distance doesn't cause trains to repath.

[farcast]

Waypoint Bug Test.gif (3.89 MiB) Viewed 5664 times

Top: Waypoint disables when the first rail signal turns red, train paths straight to the destination.

Middle: Same as top, but the train slows down on the third signal. Train paths to the destination until it starts slowing down, then repaths to next waypoint.

Bottom: Waypoint disables when the first signal stops being green. Train repaths to next waypoint.

Train Schedule.png (90.59 KiB) Viewed 5664 times

All trains have the same schedule and run on solid fuel. Test was done in a sandbox scenario with max (+100%) braking force researched.

I've attached a blueprint with the test shown. Build the blueprint, set all trains to automatic, and turn on the constant combinator (offscreen to the left) to reproduce the bug.

I'd expect all three trains to repath towards the second waypoint and turn left, or at least the top and middle tests should have the same result.

0eNrtnc1u20gWRl+lwbUUsP6rDMws5hW6gVkMAkO2GIeALBmUlJ4g8LsPqR+bLUvO+ZxujNHIpjuyraMq3rrFYvFc6lt1s9g2D1273FRX36r2drVcV1f/+Vat27vlbDH8bPP1oamuqnbT3FeTajm7H14tVrer+9Wm/dJUj5OqXc6b/1ZX5nHy3Td2s3YxeosFb9n071lO15vVw+iN7q1v9I8fJ1Wz3LSbttl3dffi6/Vye3/TdH0vnt5/u+2+NPPprsmT6mG17t+zWg4f13NS/3dfq6upST173nbN7f6XcWjYCdI+IddDm+4+by5B4wGa/wi1Z6AOQzOHegrNNYcGDLUcGjHUc2jCUCFQGUOFQBUKLUKgTI2pQqSMwVQhVAYnVRFiZXBWFSFYBqeVqZVwBTZVxXBgOsCM56bPy3NKPEFOqv4UsulWi+ub5vPsS7vqhnfctt3ttt1c97+bP2E+td16c/1iDv/SdpvtbPE8je//YnrXNc1ymMiHc9RmNpyw6uHF/cOsm22Gz6n+ufv14bOa5exm0VzP2/Xw/+pq022bSbVulvPrzep617nq6tNsse5/unt1PXT1oZnzJv1WPfYf2Ddm36Xq37OvD6vhVHruwCZ0YJ8HwMsj+/xBv+7PaS8/5HmuuZ11d6vp77O7/g0vPmVayuFT+jFQrbq25xzY9QcbzpHxhDN97oL9/nizeMqZPmUcwRqOjQLW0uNrxeNrHW+wFxrsOdYK2MCxymCI5xaYL5k5vHZ0J7tl4Hr44/Vq0c6nn7ZNn82hfjz3kfiUP83K+Mscq4w/noVZGCWOJ2EWRonjSZiFUeLwmX+ahJA5noFJCJnjGZiUkPEMTErIIscqIeNZFpWQ8SyLSsh4lkUhZJ5nWRRC5nmWRSFknmdZEELmeZYFIWSeZ1lQQsazLCgh41kWlJDxLPNKyHiWeSVkPMu8ELLAs8wLIQs8y7wQssCzzAkhCzzLnBCywLPMKSHjWeaUkPEsc0rIeJZZJWQ8y6wSMp5lVghZ5FlmhZBFnmVWCFnkWWaEkEWeZUYIWeRZZpSQ8SwzSsiisDEgYIXrMoEqLBgFqnAm49QkpJhAxRkmBCvh/FJairNLOag4t4T4J36DQ4BGvmcsUHFaKXNAwmmlTFgJp5Uyu2acVsqpIOO0Us5bmeeVEK2ME0tZEWScWcryJePUUtZaGeeWsjDMOLeUVWzGuaUsuTPOLeX6oODcUi5mCs4t5cqr4NxSLhMLP2kJ0So4t5QL8IJzS9ktKDi3lK2NgnNL2YcpOLeUTaOCc0vZ4drdVYPYrGBxdim7h6bG6aXsdZoa55eyM2tqviyUQoYzLEohwymWpJDhHEtSyHCSJSlkRZaqCJYrMMq9JcMdGOVOmOESjHLfznALRrnLaLgGk6WQBVmwQtgoK1YIm2THCmGzLFkhbJEtK4Ll1ocifRhufUiOihlpH6+5O883x2tkRf2QddQDl3v+znQww3/2itTIaW3nQ+vz48c/ekq/bmbdeUlppKEMB256aNSZ680PRwej/hBODNjvOGCL1bp56u1BwDr+smtmz0diMLYu9LRr5i/76Yd+nu2VR/FzWvj+DKlt6MerSts//i9KGz7k7nRovarAjbShV0eXC6+MrrPgyMAh/knDdn/kz47akxH9FyuP/fg4P+RV3bB+i2440pzum3m7vZ82i57QtbfTh9XirLr1NHGEXQCEaWw8NQ8/saG+mPBFk/gdGGNckjouOD3xjY263kRUqy43EdWpq01E9epiE1GDutZE1KguNRE1qStNRM3qQhNRi7rOJFSuRhUhWtyMKkK0uBj1NLkirJNkfkOQXnL57U+VH65jRloYOrnat5xbR5IYcvmxyS9oYscekIskQRM7pBuiFlXkJ9SRJIY8fnxsBU3sMD+i5lrV4kdUp0r8iOolh//HDX4j6GOZDzzBHsvCwEuqwI+oWfX3EbWo+j6hCuZY4tESxLHEoyV4Y4lHS9DGEo+WYI0lIVpBFfcRNarePqImVdtH1Kxa+4haVGmfUAVlLPBocWXsqOwjqlWNfUR1qrCPqF719RE1qLo+okbV1kfUpMr6iJpVVx9Ri6rqEyr3xo6mPqIaVdRHVKt6+ojqVE0fUb1q6SNqUCV9RI2qo4+oSVX0ETWrhj6iFlXQJ1TujR39fEQ1qp6PqFa18xHVqXI+onrVzUfUIKr5CBpFMx9BkyjmI2gWvXwELZqWj56sUGtWPmIaTcpHTKs5+YjpNCUfMb1o5CNoEIV8BI2ij4+gSdTxETSLNj6CFlHGRw8UqUUXH0GNqOIjqBVNfAR1ooiPoF708BE0iBo+gkbRwkfQJEr4CJpFBx9Bi6jgo2fp1KKBj6BGFPAR1Ir+PYI6Ub9HUC/a9wgaRPkeQaPo3iNoEtV7BM2ieI+gRdTuCZQrKnyr0nJDhe+qWi6o8A1gy/0UvldtuZ6ShEAFUbVH0CiK9giaROsJQbMoPSFoEZ0n9Pi0WlSeENSIxhOCWlF4QlAn+k4I6kXdCUGDaDshaBRlJwRNouuEoFlUnRC0qKYTenRgLcn0/p2p9KcOasFyvR3JIUyud+9ErbfBXjBtbbCKWu9/ivXwgJsXA01S7e1I7mFmtvOHQecvetkXRsZpQ8PFseJF/d8R+d+O/B/WVe/e1lX3oqvxYlej2KZg39am8KJN6WKbklgk4f4+JRLCEb0c0yxZn/4N0qcdOVdqQUXW6imG6ok/Dh2XzaWuj6QtUk9hDEhbrmwdrixelKicpVrx0oJRnXhtwahevLhg1CBeXTBqFC8vGDWJ1xeMmsULDEYt4hUGonJlqwjR4spWEaLFla0iRIsrW8eZlWG9Vk8RCDMoBRXmZ0EFXa2mKJ1azVsKKuzIYUMFFbtvYEDP7hc8tqcuRDLeilpSgbCCynacHhDWaEUV/PgKPttxlkQNdmpZBcN6ta6CYYNUWHH+6GrfjSD4blkZf0ktrWDYrNZWMGxRiysQVnDesjBKBOktCSETrLckhEzQ3pIQMsF7S0rIglpiwbBRrbFg2KQWWTBsVqssGLaoZRYE6+parbNgWKMWWjCsVSstGNappRYM69VaC4YNarEFw0a12oJhk1puwbBZrbdg2KIWXCCsqdWKC4Y1askFw1q15oJhnVp0wbBerbpg2KCWXTBsVOsuGDaphRcMm9XKC4YtaukFwgpflWeFkAlflWeEkFmrVl8wrFPLLxjWq/UXDBvUAgyGjWIFBqMmsQSDUbNYg8GoRSzCQFTuzwnB4v6c0lKr1WEwqNMKMRjUa5UYDBrEUgxGjWItBqMmsRiDUbNYjcGoRSzHQFQu0SnnLW7RKSdZrtEpKwLu0SnLFy7SKWstbtIpC0Ou0imrWO7SKUtuLtMp1wfcplMuZvjX3SlXXvwxRsplIn+MkXJNyx9jpFyA86+6U3YL+KOKlK0N/qgiZR+GP6pI2TTijypSdrj4o4qU7Tj+qCJl75B7L8pGJ/dehF1Zx70XYQvZce8lKtEKYqEGo0axUoNRk1iqwahZNaoQtahGFaFy70W4++W49yLcqnPcexHuKzruvQg3QR1/VFFWohVUowpRo2pUIWpSjSpEzapRhahFNaoIVfiKO8FGcSO/gxRumPyOKjeGOo1T2zXhyg03ElBY5YZJ76R0w2V3Qep1I/0FlG7AcP6tbTZ8zK1Sq+GyWhdxZnSd5QZR+P/BUfvevxTBZVEzzG/QDN3Ibjq2cNq37qZd7lp3TkY6Hv5yevgvJNmndrFpuvVu3L3luG2Hg9bP5u1y3gz9ffzY/3t9vTqmiTKzHqsGesT69nMz3y6afcOeJbXhtY2T4dHANofRH+47cDL/TqrfZ+Mhsqft49tcHzq5O5CHfx8GVbVr9F886fRdnXy7lNcng+O9d+TjLuyb5r7/yc1i2zx0Q0cm1WJ2MziBT3375V/bu19+a9bD7770w27XrORq40ttU46Pj/8DyAzc3A==

Copy blueprint

[knightelite]

This appears to be the same issue as I reported in this thread. Didn't see your thread when I reported it.

[quyxkh]

So, near as I can tell, a train whose braking point reaches its enabled path end waypoint stop immediately extends its path to its next stop and remembers which block it has to enter to actually pass the waypoint, but doesn't update its schedule until it actually enters that block.

The interval between reserving the block past the waypoint and actually entering it is weird, a waypoint-only state where the path end stop isn't next on the schedule. When the waypoint disables itself, for the top two trains in your blueprint it's next on the schedule but it isn't the path end stop, and they don't repath, why should they? they're not pathing to that stop any more anyway, they've already reserved a path past the desired waypoint, the schedule has already had its desired effect on the train's behavior, after which it disabled itself.

This is exactly what's desired for regular stops: I think everybody can agree trains that have arrived at their stop should stay there if the stop disables itself, the schedule has already had its intended effect, the train stopped there, disablement doesn't affect past decisions and behavior, only future decisions it might make about that stop.

And I think everybody can agree that waypoint stops that disable themselves after the train has passed the waypoint shouldn't affect the train's route, the schedule has had its desired effect, the train's route went past it.

But when the train plans and reserves a path past an enabled waypoint to its next stop, and if nothing _else_ forces a repath it is guaranteed to actually pass that stop, the question here is whether that's the end of "the desired effect". It was never going to actually stop there, it has already routed past there, what's left to achieve?

With the train that's stopped itself at a regular stop that then disables itself, it's already looking at something besides path_end_stop, it's done worrying about this one and it's on to the exit conditions. With the train that's routed itself past a waypoint that then disables itself, it's done worrying about this path_end_stop, it's worrying about the next one. In both cases the train's current task is something other than doing the right thing at the particular path_end_stop in question, and the answer's the same: if the train's not worried about that particular path_end_stop, it's not worried about whether it's enabled or not.

Suppose you had a fast very long train with multiple waypoints on its schedule, with the behavior the way it is now the train only has to worry about one path end stop at a time, but the otther way there's literally no limit to the number of stops a train might have to be watching in case they disable themselves. I think this is the clincher, currently trains only have to watch one stop for disablement every tick, what you're asking for would require them to scan an arbitrarily-long list each tick.

[knightelite]

But when the train plans and reserves a path past an enabled waypoint to its next stop, and if nothing _else_ forces a repath it is guaranteed to actually pass that stop, the question here is whether that's the end of "the desired effect". It was never going to actually stop there, it has already routed past there, what's left to achieve?

It's an unintuititive behavior, especially given that the train schedule doesn't update at the point where it changes destinations, only at the point where the train passes the actual waypoint station. I would expect that changes to any waypoint stations would continue being honored until the train actually passes them. The train is clearly still checking if it's passed that station or not as it updates its schedule once it does pass the station.

With the train that's stopped itself at a regular stop that then disables itself, it's already looking at something besides path_end_stop, it's done worrying about this one and it's on to the exit conditions. With the train that's routed itself past a waypoint that then disables itself, it's done worrying about this path_end_stop, it's worrying about the next one. In both cases the train's current task is something other than doing the right thing at the particular path_end_stop in question, and the answer's the same: if the train's not worried about that particular path_end_stop, it's not worried about whether it's enabled or not.

The interesting thing here though is that farcast's second condition this is clearly not what's happening. The train routes past the waypoint, then reroutes when it sees the red signal, and then paths through the next waypoint. Meaning it hasn't actually finished with the previous waypoint, as the waypoint is still in the schedule until the train actually passes the station. If it were already cleared then the repath in the second row of farcast's gif caused by the red signal would not redirect the train through the top waypoint station.

Suppose you had a fast very long train with multiple waypoints on its schedule, with the behavior the way it is now the train only has to worry about one path end stop at a time, but the otther way there's literally no limit to the number of stops a train might have to be watching in case they disable themselves. I think this is the clincher, currently trains only have to watch one stop for disablement every tick, what you're asking for would require them to scan an arbitrarily-long list each tick.

Train length wouldn't directly affect this (since only waypoint stations in front of the front of the train would matter), as any train with the same ratio of wagons:locomotives has the same braking distance. Though I suppose that train weight and braking force would matter, which can be related to length if there is large wagon:locomotive ratio, or artillery wagons present (which have same braking force as normal wagons, but weigh 4 times as much).

You're right though that it might cause the train to need to be aware of all the waypoint stations within its braking distance + the station it currently has as its destination. If it's going the other way around though, with stations sending events to trains that have them as their targets when they get disabled it might not be too onerous as compared to the current method (train just becomes able to receive signals from multiple stations, but the signal is still only sent once per station that is disabled).

[knightelite]

This behavior may have changed; I was able to find a difference in behavior since the last time I did the test. See here:

viewtopic.php?f=7&t=68145

EDIT: Interestingly, it hasn't. I just ran farcast's blueprint, and it behaves exactly like in his gif in0.17.16, but the trains do not behave the same in my game. I'll have to mess around some more now, maybe the difference is that he has three differently named stops and I only have two, or else I'm doing something else strange.

EDIT2: The three stops is not the difference, I'll try some more stuff.

[knightelite]

So I continued investigating this some more, and I'm not sure if farcast positioned his signals where he did on purpose, or it just lucked out that way, but I think I've figured out the current behavior. Demonstrated in this video with pause mode showing the exact ticks where the difference in behavior happens. I've attached the save as well if anyone wants to mess with it.

I think I've got the behavior figured out now (version 0.17.16):

• Trains consider a waypoint station to be "passed" (and remove it from their schedule) only once the front of the train is ~2 tiles beyond the station.
• If the waypoint station becomes disabled prior to the train's braking distance reaching it, the train will repath immediately.
• If the waypoint station is disabled after the train's braking distance reaches it, the behavior will depend on some additional conditions:
  • If nothing forces the train to repath prior to the train updating its schedule, the disabled waypoint is passed, and removed from the schedule.
  • If something does force the train to repath (basically if it brakes for any reason) prior to the schedule being updated, the train will not consider the disabled waypoint to have fulfilled its waypoint schedule item, and will repath to another waypoint station.

[knightelite]

Kovarex, do you have any thoughts as to which way you're leaning for fixing this one? Is it going to be "waypoints are struck from schedule as soon as braking distance passes them" or is it going to be that turning off a waypoint prior to the train physically passing it will immediately cause a repath to another of the same name? I definitely prefer the second, but could understand using the first.

[farcast]

I'd also prefer knightelite's second option, as the first would make waypoints less useful in heavily combinator controlled train systems.

Speaking from experience, I may be a bit biased...

[knightelite]

I'd also prefer knightelite's second option, as the first would make waypoints less useful in heavily combinator controlled train systems.

Speaking from experience, I may be a bit biased...

Definitely why I started looking into this as well, I was thinking "Hey, I can shrink these blueprints down to 1/4 of their previous length using these new waypoint stations!"

[kovarex]

This is not a simple thing to decide/change.

Changing path closer than the braking distance is tricky as the train might choose a different path with a red signal, which would cause it to stop much faster than it physically normally could. We already discussed this specific problem at some point (as it can happen currently as well in some cases) and it should be solvable by providing "minimum free distance" when pathfinding a train that is in motion. This would restrict the pathfinder from selecting a path where it has to stop sooner than it would be normally possible.

But I would prefer to not do this kind of change at this point, as it would require non trivial changes and some consequences that wouldn't be expected, like train being forced to some part of the rail network where it would never normally go, as it would be the only free path etc.

The question I would like to ask instead is: Why do you need this behaviour so much? Isn't there some more straightforward way to achieving your goal?

[knightelite]

In my case, I achieved the goal already without waypoint stations back in 0.16. It just required leaving the train's full braking distance between stations so they wouldn't slow down at each one (with 1-2 ratio trains, that is about 120 tiles). I had been hoping that with 0.17 I would be able to make shorter segments with waypoint stations instead so the individual blueprints could be smaller and less cumbersome to place. But if I still need to leave the train's full braking distance before disabling a waypoint station in 0.17, then for my use case there's no advantage to using them instead of regular stations.

What I'm doing is making all the trains have the same schedule, and passing metadata in the circuit network along the rails as the trains travel down them. Each branch point in the rails then makes a decision on where the train should go based on its metadata, and routes it appropriately.

You can check out this reddit post and the associated videos if you're curious about how it works.

I'm not sure what farcast wants this change for .

[farcast]

I'm making my own combinator LTN inspired by this reddit post. I used RattlemBones' method in a two-lane RHD three way junction, and, while it works just fine in 0.16, trains have to slow down while passing through the junction if they're moving too fast. If I could use the new waypoints, train throughput should only be marginally lower than a circuit-free three way junction.

The junction is pretty much complete, I'm still working on the stations to go with it though. I can share pictures/blueprints if you'd like, but I'd like to save the full write-up for when the whole system is finished.

While it's not necessary for this bug to be fixed, I would greatly appreciate if it was.

[knightelite]

Slightly derailing this thread, but that post is extremely cool, and I wish I had seen it sooner! Sounds like you and RattlemBones are doing something very similar to what I came up with, with attaching metadata to the trains and then doing stuff based on that; just with a different type of metadata.

So you basically want this for exactly the same reason I do .

[farcast]

Yeah, pretty much.

To clarify a bit, in my case, the station can't be disabled until it's absolutely certain the train is moving in the right direction. That only happens when the physical train enters the next block after the rail split. There's no other method that I'm aware of. Disabling it sooner risks the train pathing through the wrong exit, and to allow trains to pass through the split at full speed would require a huge distance between the split and each station.

So my only options are:

1. Accept sub-optimal train throughput by allowing trains to slow down.
2. Accept ridiculously huge junction exits allowing maximum throughput.

Using waypoints instead would allow maximum throughput without the huge exits. That's why this mildly inconvenient bug should be fixed as soon as possible!

[knightelite]

Accept ridiculously huge junction exits allowing maximum throughput.

That's what I did with my original version; made everything 125 tiles or thereabouts long. It does get a bit large.

Using waypoints instead would allow maximum throughput without the huge exits. That's why this mildly inconvenient bug should be fixed as soon as possible!

That's definitely my reasoning as well .

[knightelite]

So I had a thought (that might be dumb) on how to implement the behavior that farcast and I want. Would it be possible to create some kind of "virtual station" <train braking distance -1 tile> along the train's path from the waypoint station, and only consider the waypoint station to have been "passed" by the train once the braking distance passes this virtual station? Then when the real waypoint station becomes disabled, the virtual waypoint stations would disappear, forcing the train to repath to find another correctly named waypoint station to pass through.

That could be dumb idea for any number of reasons, but I figured I would post it anyway in case it's useful.