It is possible to delete a route while it is still set by driving the train past the influence point of the signal, stopping it, and then deleting the route via the signal's formspec.
The route can still be cleared if the train is driven to the final TCB of the route, or by using the interlocking tool to remove all locks and resetting all section states. However, this requires a lot of work if the route contains many passive components.
My proposed solution: When the delete button is pressed for a route, advtrains will first check if that route is applied, and if so, forbid the deletion, send the player a chat message saying "Can't delete route: That route is still applied", and close the formspec so they can see the chat message.
[From discussion on Minetest Forums](https://forum.minetest.net/viewtopic.php?f=11&t=14726&p=415708)
It is possible to delete a route while it is still set by driving the train past the influence point of the signal, stopping it, and then deleting the route via the signal's formspec.
The route can still be cleared if the train is driven to the final TCB of the route, or by using the interlocking tool to remove all locks and resetting all section states. However, this requires a lot of work if the route contains many passive components.
My proposed solution: When the delete button is pressed for a route, advtrains will first check if that route is applied, and if so, forbid the deletion, send the player a chat message saying "Can't delete route: That route is still applied", and close the formspec so they can see the chat message.
An alternative solution occurred to me: The signal formspec after the train passes the signal could be set to the same formspec as before it passes it, with the "A route is set on this signal" text and the "Enable automatic working" button still present, but without the Cancel Route button. Of course, I don't know enough about advtrains' internals to know if a signal can set more than one route at once.. but such an idea sounds a bit silly to me. Maybe.
Of course, multiple route setting could have its operational benefits, like having a junction in front of two diverging single-track lines, and allowing trains to pass onto each line once the back of the previous train has cleared the junction, which I think is how it is now. Allowing only single route setting would require the first train to reach a passing loop, end-of-interlocking point or so on before the second train can pass the signal. Perhaps it suffices to hide the route editing part of the formspec from player intervention without removing the ability of ARS to set multiple routes. The signal can keep count of how many routes it has set and when it returns to 0, the full formspec is revealed again. Or it can keep a table of set routes and display those in the formspec, which might be more helpful for error recovery.
Ok that's my proposal: A signal should track set routes and show them in its formspec, disallowing new route creation while any route is set. It should then show the full formspec only when there are no routes set at all.
An alternative solution occurred to me: The signal formspec after the train passes the signal could be set to the same formspec as before it passes it, with the "A route is set on this signal" text and the "Enable automatic working" button still present, but *without* the Cancel Route button. Of course, I don't know enough about advtrains' internals to know if a signal can set more than one route at once.. but such an idea sounds a bit silly to me. Maybe.
Of course, multiple route setting could have its operational benefits, like having a junction in front of two diverging single-track lines, and allowing trains to pass onto each line once the back of the previous train has cleared the junction, which I think is how it is now. Allowing only single route setting would require the first train to reach a passing loop, end-of-interlocking point or so on before the second train can pass the signal. Perhaps it suffices to hide the route editing part of the formspec from player intervention without removing the ability of ARS to set multiple routes. The signal can keep count of how many routes it has set and when it returns to 0, the full formspec is revealed again. Or it can keep a table of set routes and display those in the formspec, which might be more helpful for error recovery.
Ok that's my proposal: *A signal should track set routes and show them in its formspec, disallowing new route creation while any route is set. It should then show the full formspec only when there are no routes set at all.*
A (hopefully) minor issue with the approach of showing "A route is set on this signal" comes up when a train moves beyond the signal and the next train approaches the signal - then you have the issue that you can not cancel the route set for the upcoming train as it is not shown on the formspec.
Changes to the signaling formspec would likely involve quite a bit of work for me in the future, as I have also made some changes to the formspecs in the new-ks branch.
Currently the new-ks branch reorganized certain elements into tabs. Perhaps this could be done so that you can work with routes on one tab (although, likely you mentioned earlier, you should not be able to delete a route that is set) and look at the routesetting information on another tab. The space should be sufficient for showing information on the current route set and the upcoming one.
A (hopefully) minor issue with the approach of showing "A route is set on this signal" comes up when a train moves beyond the signal and the next train approaches the signal - then you have the issue that you can not cancel the route set for the upcoming train as it is not shown on the formspec.
Changes to the signaling formspec would likely involve quite a bit of work for me in the future, as I have also made some changes to the formspecs in the `new-ks` branch.
Currently the `new-ks` branch reorganized certain elements into tabs. Perhaps this could be done so that you can work with routes on one tab (although, likely you mentioned earlier, you should not be able to delete a route that is set) and look at the routesetting information on another tab. The space should be sufficient for showing information on the current route set and the upcoming one.
Once the train passes over the first TCB of the route (enters the first section of the route), the route is disassociated from the signal. Each section has its own record of
which was the previous section
which is the following section
which route locks does this section hold
At this point the sections do not consult the initial signal anymore. This way, the signal can set a new route while the rear part of the previous route is still set.
There is a fallback mechanism if the train leaves a route section on the "wrong" tcb. When this happens, the rest of the route - starting from the correct "next" tcb - is cancelled (cancel_route_from() in the tcb exit callback).
All in all, once the train has passed the first TCB, deleting the route from the signal should not cause problems. As soon as you move the train out of the route sections (e.g. by reversing it again) the route should be automatically released.
There might still be a bug hiding, so can you try this?
Set a route
Move train into first section and stop it
delete route from signal
Move train backwards out of first section
The route should now be released again
Once the train passes over the first TCB of the route (enters the first section of the route), the route is disassociated from the signal. Each section has its own record of
- which was the previous section
- which is the following section
- which route locks does this section hold
At this point the sections do not consult the initial signal anymore. This way, the signal can set a new route while the rear part of the previous route is still set.
There is a fallback mechanism if the train leaves a route section on the "wrong" tcb. When this happens, the rest of the route - starting from the correct "next" tcb - is cancelled (cancel_route_from() in the tcb exit callback).
All in all, once the train has passed the first TCB, deleting the route from the signal should not cause problems. As soon as you move the train out of the route sections (e.g. by reversing it again) the route should be automatically released.
There might still be a bug hiding, so can you try this?
- Set a route
- Move train into first section and stop it
- delete route from signal
- Move train backwards out of first section
- The route should now be released again
I ran that test and it still cleared the routesetting status just fine, so the system seems to work well. The original reporter SylvesterKruin from the forums said that to fix the issue the route was re-created, a train was run over the end of the last TCB, and that resolved the issue. It may be quite complicated to engineer a systematic solution, so perhaps this kind of issue (along with many others) can go in some kind of troubleshooting page on the wiki and we can mark it as WONTFIX. Or just let it sit here in the hope someone will get around to it some day.
I ran that test and it still cleared the routesetting status just fine, so the system seems to work well. The original reporter SylvesterKruin from the forums said that to fix the issue the route was re-created, a train was run over the end of the last TCB, and that resolved the issue. It may be quite complicated to engineer a systematic solution, so perhaps this kind of issue (along with many others) can go in some kind of troubleshooting page on the wiki and we can mark it as WONTFIX. Or just let it sit here in the hope someone will get around to it some day.
From discussion on Minetest Forums
It is possible to delete a route while it is still set by driving the train past the influence point of the signal, stopping it, and then deleting the route via the signal's formspec.
The route can still be cleared if the train is driven to the final TCB of the route, or by using the interlocking tool to remove all locks and resetting all section states. However, this requires a lot of work if the route contains many passive components.
My proposed solution: When the delete button is pressed for a route, advtrains will first check if that route is applied, and if so, forbid the deletion, send the player a chat message saying "Can't delete route: That route is still applied", and close the formspec so they can see the chat message.
An alternative solution occurred to me: The signal formspec after the train passes the signal could be set to the same formspec as before it passes it, with the "A route is set on this signal" text and the "Enable automatic working" button still present, but without the Cancel Route button. Of course, I don't know enough about advtrains' internals to know if a signal can set more than one route at once.. but such an idea sounds a bit silly to me. Maybe.
Of course, multiple route setting could have its operational benefits, like having a junction in front of two diverging single-track lines, and allowing trains to pass onto each line once the back of the previous train has cleared the junction, which I think is how it is now. Allowing only single route setting would require the first train to reach a passing loop, end-of-interlocking point or so on before the second train can pass the signal. Perhaps it suffices to hide the route editing part of the formspec from player intervention without removing the ability of ARS to set multiple routes. The signal can keep count of how many routes it has set and when it returns to 0, the full formspec is revealed again. Or it can keep a table of set routes and display those in the formspec, which might be more helpful for error recovery.
Ok that's my proposal: A signal should track set routes and show them in its formspec, disallowing new route creation while any route is set. It should then show the full formspec only when there are no routes set at all.
A (hopefully) minor issue with the approach of showing "A route is set on this signal" comes up when a train moves beyond the signal and the next train approaches the signal - then you have the issue that you can not cancel the route set for the upcoming train as it is not shown on the formspec.
Changes to the signaling formspec would likely involve quite a bit of work for me in the future, as I have also made some changes to the formspecs in the
new-ksbranch.Currently the
new-ksbranch reorganized certain elements into tabs. Perhaps this could be done so that you can work with routes on one tab (although, likely you mentioned earlier, you should not be able to delete a route that is set) and look at the routesetting information on another tab. The space should be sufficient for showing information on the current route set and the upcoming one.Once the train passes over the first TCB of the route (enters the first section of the route), the route is disassociated from the signal. Each section has its own record of
At this point the sections do not consult the initial signal anymore. This way, the signal can set a new route while the rear part of the previous route is still set.
There is a fallback mechanism if the train leaves a route section on the "wrong" tcb. When this happens, the rest of the route - starting from the correct "next" tcb - is cancelled (cancel_route_from() in the tcb exit callback).
All in all, once the train has passed the first TCB, deleting the route from the signal should not cause problems. As soon as you move the train out of the route sections (e.g. by reversing it again) the route should be automatically released.
There might still be a bug hiding, so can you try this?
I ran that test and it still cleared the routesetting status just fine, so the system seems to work well. The original reporter SylvesterKruin from the forums said that to fix the issue the route was re-created, a train was run over the end of the last TCB, and that resolved the issue. It may be quite complicated to engineer a systematic solution, so perhaps this kind of issue (along with many others) can go in some kind of troubleshooting page on the wiki and we can mark it as WONTFIX. Or just let it sit here in the hope someone will get around to it some day.
Agreed. Let's keep this in mind for documentation.