AI train WP restart events don't work after save

Bug #1848878 reported by Carlo Santucci
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Open Rails
In Progress
Low
Carlo Santucci

Bug Description

Let's have a train which has an event which is linked to an absolute WP of an AI train, which causes the AI train to restart before WP expiration. If a save is performed before the event is triggered, the link won't work and the AI train won't restart before WP expiration.

Tags: ai
Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Committed on 23/10/2019.

Changed in or:
status: In Progress → Fix Committed
James Ross (twpol)
Changed in or:
milestone: none → 1.4
Revision history for this message
Carlo Santucci (carlosanit1) wrote :

The bug fix does not work correctly for standard WPs where a save is performed during the WP.

Changed in or:
status: Fix Committed → In Progress
James Ross (twpol)
Changed in or:
milestone: 1.4 → none
Revision history for this message
David Safdy (wmuzeke) wrote :

This bug is still present in 1.5.1. It only seems to effect standard wait points (wait time) and not absolute (wait until). If you hit F2 before the AI traffic starts or before it gets to the wait point, then the wait point reset works correctly. If you hit F2 after the AI traffic reaches the wait point, the wait point reset does not work. You can verify this by changing the AI wait point in the sample TesteventWP_longerpath activity to a wait time. Stop the Acela in the tunnel, wait for the AI train to stop at the WP, press F2, then pull forward to the restart point. (Click resume when the activity end box comes up) The AI train will not restart. Do the same thing again without pressing F2 and it restarts.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Unstable release U2023.03.09-1121 contains a fix for the bug.

Revision history for this message
Don Leblanc (don6218) wrote :

This bug is still present in 1.5.1. It only seems to effect standard wait points (wait time) and not absolute (wait until). If you hit F2 before the AI traffic starts or before it gets to the wait point, then the wait point reset works correctly. If you hit F2 after the AI traffic reaches the wait point, the wait point reset does not work. You can verify this by changing the AI wait point in the sample TesteventWP_longerpath activity to a wait time. Stop the Acela in the tunnel, wait for the AI train to stop at the WP, press F2, then pull forward to the restart point. (Click resume when the activity end box comes up) The AI train will not restart. Do the same thing again without pressing F2 and it restarts.

I was ata loss as to why this activity was not working, and this was the cause.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Yes Don,
that's exactly what David Safdy has written in his above post.
As i have written, the actual Unstable release contains a fix for the bug, and most likely from this Saturday on the fix will be present also in the Testing release.

Revision history for this message
David Safdy (wmuzeke) wrote (last edit ):

Thank you for addressing this issue. I tested it out on my sample activities with the update and it seems to be resolved. There is still another bug that may be related to this one. When you use an AI train to reset another AI train's wait point using "ORTSTriggeringTrain" it does not work after saving. Is this part of the same bug?

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Hi David, good that it works now. Re the other issue, if you mean the fact that the Resume generates a crash, I have verified it and in fact it is so. It is another issue. If you have only one AI train with the service name used in ORTSTriggeringTrain, you can remove the second parameter (the numeric one) in the ORTSTriggeringTrain line, and this should avoid the crash. In the meantime I'll study how to solve the issue.

Revision history for this message
David Safdy (wmuzeke) wrote :

I should have been more specific, but yeah I meant that resuming with that command in the extension file crashes the program. I have to go into Windows task manager to "end task" on the OR Activity Runner each time it does this, too. But removing that 2nd parameter did the trick. I'm trying to orchestrate a 3-way meet using this feature. Anyway, I appreciate you working on this and look forward to an update.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.