static consists are moving on gradient

Bug #1402854 reported by Phil Moser
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Open Rails
Fix Released
High
Peter Gulyas

Bug Description

In timetable mode, when either consists become static or are formed to become another train later on, if the train is parked on a gradient, the train will move. In the situation I noticed, the train rolled backwards out of the path that the new train is formed by and Open Rails crashed. This did not happen before X2678 and X2685 did not correct this particular problem.

Peter Gulyas (pzgulyas)
Changed in or:
assignee: nobody → Peter Gulyas (pzgulyas)
Revision history for this message
Peter Gulyas (pzgulyas) wrote :

In r2724 I partially reverted the modifications of r2678, in a hope now they would not affect AI trains. May I ask you to test it?

Peter Gulyas (pzgulyas)
Changed in or:
status: New → In Progress
Revision history for this message
Phil Moser (phil-moser1) wrote : RE: [Bug 1402854] Re: static consists are moving on gradient

Peter,

That fixed it. The timetable works exactly as I thought it should through the 24 hour period. I had also noticed that AI trains were not going "static" when they should have, but that is also working perfectly now as well. Thank you for the quick response.

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Tuesday, December 16, 2014 2:12 PM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

In r2724 I partially reverted the modifications of r2678, in a hope now they would not affect AI trains. May I ask you to test it?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  New

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Peter Gulyas (pzgulyas)
Changed in or:
status: In Progress → Fix Committed
Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

I spoke to soon. I was placing more consists, and the problem reappeared. The consists show as static in the dispatcher screen, but they still will creep downhill. The consists I was having a problem with originally when I submitted the bug report are staying put however.

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Tuesday, December 16, 2014 2:12 PM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

In r2724 I partially reverted the modifications of r2678, in a hope now they would not affect AI trains. May I ask you to test it?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  New

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

And what is the difference between the consists with and without having the problem?

Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

FYI... this is for the Surfliner2 route. I'm trying to "stage" consists in the Amtrak yard south of LAUPT (Los Angeles Union Passenger Terminal) on tracks called "North Yard 1" thru "North Yard 4". With your recent fix, the consists on those tracks which are "push-pull train sets" (Pacific Surfliner trains) don't move. When I added the three pairs of Amtrak long distance trains to the timetable, that's when I noticed consists moving again. I'm trying to stage those trains on tracks called "Yard Transfer 1", "Yard Transfer 2" and "South Yard Lube". The consists on those tracks are Amtrak Superliner consists with the engines on the south end, so they shove into LAUPT. Given enough time, these consists will roll downhill and eventually end up on the track behind the roundhouse! The gradients on the later tracks are not much steeper than the tracks were the trains don't move, so I don't know why the superliner consists are moving. When I start adding commuter trains to the timetable this will become a bigger problem since some of the stations were trains reverse directions are on much steeper grades (Moorpark and Laguna Niguel especially).

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Thursday, December 18, 2014 3:32 PM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

And what is the difference between the consists with and without having the problem?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  Fix Committed

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

I believe I can add more information for this problem. This also affects reverse points that are on a grade and depends on simulation speed. I back the non "push-pull" trains out of LAUPT to the crossovers just north of Mission Tower and then reverse direction to go back to the coach yard. I do this so the consist is pointing the correct direction when I back those consists back into LAUPT later in the day. The grade were the train reverses direction north of Mission Tower is .450 - .600 as shown in the Route Editor. The reverse moves work fine as long as the simulation is running up to 6X normal speed. At 8X and above, the train will stop at the reverse point and will never reverse (it just sits there). If I move the reverse point to a level area just south of the Los Angeles River, the reverse point works fine at any simulation speed. Of course, this affects trying to start any train that starts later in the day than the consists that reverse direction.

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Thursday, December 18, 2014 3:32 PM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

And what is the difference between the consists with and without having the problem?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  Fix Committed

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
r.roeterdink (r-roeterdink) wrote :

This could well be a completely different problem.
I think AI trains don't react well to simulator speed increases. The update doesn't always handle the larger update interval time correctly. I have noticed a similar problem when using "time fast forward" - that makes a real mess of AI timing.

Regards,
Rob Roeterdink

Revision history for this message
r.roeterdink (r-roeterdink) wrote :

Just for info : Surfliner2 was one of the first routes for which a timetable was created, as test-bed during development.
This is a view of the LA Metro Yard around midday - about 20 sets are stored here between morning and evening rush-hours.
All sets in view are 'life' AI trains, all are just 'stabled' as part of their timetabled duties, using the $stable command or, in some cases, using in and outbound ECS runs, using direct $forms commands.
Sometimes the ECS runs work better than the $stable command as it allows commands to be set for these runs, which ofcourse is not possible for $stable runs.

Regards,
Rob Roeterdink

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

May I ask you to test the attached RunActivity.exe, if that solves the running away new trains? (Please be aware it is not an LAA version, thus you have to switch off LAA in options.)

Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

Sorry, the "runactivity.exe" file you asked me to test didn't make any difference in the runaway consists.

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Saturday, December 20, 2014 4:48 AM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

May I ask you to test the attached RunActivity.exe, if that solves the running away new trains? (Please be aware it is not an LAA version, thus you have to switch off LAA in options.)

** Attachment added: "RunActivity.zip"
   https://bugs.launchpad.net/or/+bug/1402854/+attachment/4284619/+files/RunActivity.zip

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  Fix Committed

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

As svn server is now working, I uploaded this minor change as r2729. Now all AI trains are added to world with applied train brakes, that I can think of. For investigating the case it doesn't, or where the brakes are released, I need to see a test case for this myself. It would be a big help if you could show one, most preferably on a default MSTS route, using a default consist.

But first of all it would be good to know if the particular track location or the particular consist triggers the issue. It would be worth trying if you can reproduce the issue with a default consist, or it is specific to the one you use there.

Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

X2929 did not solve the problem. After more experimenting, I think I've found a pattern. The only difference between the consists that stay put and the ones that roll away are the location of the engines. If the engines are facing uphill, the train will not move. If the engines are facing downhill, they will roll away. Since all the static consists have the engines facing downhill, I couldn't figure out why the "push-pull" consists weren't rolling away until I realized the cab car is an engine as well (although a very weak one). Anyway, I solved my problem by staging the Superliner consists with the engines facing north (uphill at this particular spot). The only difference in my operation is turning the long-haul trains before departure vs. after arrival in Los Angeles (all other trains are push-pull). If you wanted to, you could probably revert to the changes you did in x2724?

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Sunday, December 21, 2014 12:59 PM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

As svn server is now working, I uploaded this minor change as r2729. Now all AI trains are added to world with applied train brakes, that I can think of. For investigating the case it doesn't, or where the brakes are released, I need to see a test case for this myself. It would be a big help if you could show one, most preferably on a default MSTS route, using a default consist.

But first of all it would be good to know if the particular track location or the particular consist triggers the issue. It would be worth trying if you can reproduce the issue with a default consist, or it is specific to the one you use there.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  Fix Committed

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

Great, this is something to start with. I cannot revert the changes, because the change involves a large restructuring of the braking code. I would rather fix the issue. Reverting changes is never a step forward, that means staying with a particular code probably forever, which is not what I think is a good thing for the future.

Peter Gulyas (pzgulyas)
Changed in or:
status: Fix Committed → In Progress
Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

After more testing, I can clarify a couple things. First, consists that go "static" will stay put regardless if they are facing up or down hill provided the engines are on the front of the consist. If the engines are on the rear of the consist, the consist will roll down the hill. If the consist gets "formed" into another train, then what I mentioned yesterday is true (works only if engines are on the front of the consist and are facing uphill). I believe the "Stable" command has the same problems as the "forms" command mentioned above. One thing I see when looking at the dispatcher screen is as soon as the consist goes static, it immediately becomes the train it is formed into instead of waiting until the start time of the formed train. Because of what I noticed about static trains above, maybe waiting for the start time of the formed train to form the new train may help with part of this problem.

Thanks,
Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Tuesday, December 23, 2014 2:36 AM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

Great, this is something to start with. I cannot revert the changes, because the change involves a large restructuring of the braking code. I would rather fix the issue. Reverting changes is never a step forward, that means staying with a particular code probably forever, which is not what I think is a good thing for the future.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  Fix Committed

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

Phil,

May I ask you to make a new test with r2736?

Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

r2736 made it worse. Now, everything including "static" trains roll away.

Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Wednesday, December 24, 2014 4:01 AM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

Phil,

May I ask you to make a new test with r2736?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  In Progress

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

I don't give up. :) Could you please try r2738 now?

Revision history for this message
Phil Moser (phil-moser1) wrote :

Peter,

I've tried every test I can think of for this bug and everything works perfectly now. Thank you for your patience with me on this.

I wonder if you could do me another favor. I've subscribed to bug #1380640 (Error: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.), but I don't know how to leave a message for the conversation on this. It's getting to the point where I can't add any passing paths to further paths that I create. If you could pass along that I'm having this same problem, I would appreciate it. I know Rob Roeterdink was working on this and he's also the one who created the original timetable for the Surfliner2 route.

Thanks again,
Phil

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Peter Gulyas
Sent: Thursday, December 25, 2014 5:08 AM
To: <email address hidden>
Subject: [Bug 1402854] Re: static consists are moving on gradient

I don't give up. :) Could you please try r2738 now?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1402854

Title:
  static consists are moving on gradient

Status in Open Rails Tracker:
  In Progress

Bug description:
  In timetable mode, when either consists become static or are formed to
  become another train later on, if the train is parked on a gradient,
  the train will move. In the situation I noticed, the train rolled
  backwards out of the path that the new train is formed by and Open
  Rails crashed. This did not happen before X2678 and X2685 did not
  correct this particular problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/or/+bug/1402854/+subscriptions

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

Just login to launchpad, and go directly to the bug's page: https://bugs.launchpad.net/or/+bug/1380640 , and post a comment using the web browser.

Changed in or:
status: In Progress → Fix Committed
James Ross (twpol)
Changed in or:
importance: Undecided → High
milestone: none → 1.0
James Ross (twpol)
Changed in or:
status: Fix Committed → Fix Released
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.