Train runs OffPath and OutOfControl at siding after oncoming train clears track ahead and path is aligned.

Bug #1193485 reported by Markus Gelbmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Open Rails
Fix Released
High
r.roeterdink

Bug Description

For further Information, please refer to the following thread at ElvasTower:

http://www.elvastower.com/forums/index.php?/topic/21784-yet-another-emergenxy-problem/

Tags: signals
Peter Gulyas (pzgulyas)
tags: added: signals
Revision history for this message
James Ross (twpol) wrote :

Please describe your precise problem in the bug report, instead of linking to a forum thread. This will make tracking the issue easier and avoid any confusion from other posts in the thread.

Changed in or:
status: New → Incomplete
Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Copied from ET: (link in 1st post)

Going into emergency isn´t fun anyway, but especially if one doesn´t know why - exactly the case with my train now on Bob Wirth´s "peavine" ATSF Phoenix Sub.
 I was stopped at Skull Valley holding the main to let a local pass utilizing the siding. It eventually got there and released the switch as it should, but then I was right down Dunno-What´s-Going-On-Street: The signal protecting the next single-track portion of the line shortly turned over to green, and about half a second later - train was at a standstill and I had just a few seconds before made the alerter shut up - emergency kicked in, the signal turned to red and in track monitor it saif: "Out of control: off path".

 Uh? :shock6: Are you kiddin' me? :fever2: I was supposed to head along the line another 100 miles or so. Even checked the path in AE, as might have been broken due to some error in AE saving the files - nope, no such MSTS thingy, must be some problem in OR...

 I guess, this issue might be somehow related to the deadlocks used to "grant" passing rights to trains over single-track bi-directional right of way. The AI I was waiting for to pass is suppposed to be followed losely by another high priority hot shot, some 20 minute in between in starting times. I don´t know where that train was when OR decided to send me to park position. Maybe the trackage grants have somehow conflicted with each other...?

 Anyway, any help appreciated as debugging a self-written activity is not that much fun if the program thinks it´s funny to setting up additionaly oddities ;)

 Yours, Markus

 PS: OR X.1600 used

Changed in or:
status: Incomplete → In Progress
assignee: nobody → r.roeterdink (r-roeterdink)
milestone: none → 1.0
Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Forgott to mention in the above, that this occurs onwards from X1600 (if in earlier revisions too, I can´t say...)

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

Markus,

could you please run the attached test version?
It creates various additional outputs which I hope will shed some light on this problem.

Usage :
A set of additional files will be generated in directory C:\temp. Please ensure that this directory exists.

Rename the existing RunActivity.exe (in ...\Trunk\Program), copy the RunActivity.exe from the attached zip file into this directory.

A)
Run the activity from the start. This will generate a number of info files which hold details on the train's paths.
You can stop this run as soon as the main OR window appears - all data is generated during initialization.
Collect all generated files (in C:\temp) in a zip-file and remove them.
If you need to run this test twice, please remove all files from C:\temp before resuming.

B)
Run the activity from the save just before the problem occurs.
The normal check on OR versions for resume has been disabled, so you should be able to resume from this save regardless of the difference in versions - except when there have been changes in the saved data structures, in which case this will, alas, crash.
If resume is possible, than run the activity until OutOfControl occurs.
Collect all generated files (in C:\temp) in a zip-file and remove them.
If you need to run this test twice, please remove all files from C:\temp before resuming.

When completed, please upload both ZIP-files.

Thanks,

   Rob Roeterdink

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Will do so probably on friday, but until then, Music is the only Thing for me to think about (here a gig, there...)

Nevertheless, thanks for all those efforts! :)

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

No problem - making music is very good and important - have fun!

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Thanks you :)
Will then also post how many sticks i smashed :D

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Here´s the zip containing the files created on a new start of the activity.

Resuming a saved activity however doesn´t work - OR V0.9 Shows all saves as invalid in the resume menu... probably also there some sort of checking the Version number Needs to be deactivated?

Cheers, Markus

PS: No sticks smashed so far, all drums still alive ;)

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

Thanks for the data.
You can start the saved session without the menu :
Open a CMD window.
Go to the OpenRail Program directory.
Start RunActivity using the following command : RunActivity.exe -resume
This will resume from the latest available save.

Keep those sticks going,

    Rob Roeterdink

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Doing what you described above, I get this (see pic in attachment)

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Continuing the above post (for some reason the System didn´t allow me to add more text...?)

"bei" in the DOSbox means "at".

And is it necessary to delete ALL other saves except for the one you want to resume? (in my case this one still is the latest, ie. newest save...)

Cheers, Markus

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

here´s also, what OR Outputs to the "DOS box" during initialization (I know, it´s not a Dos box, but I don´t know what else to call it...)

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

Could you please try the attached version?
I have remove restore of the 'gear' information - your saved data probably did not have that data yet.
You don't need to remove other saves as long as the required save is the last one. If not sure, best is to create a temp directory in the save area and move all saves in there, taking out the one you need. When done, move them all back again.

Und zum letzten : Danke, aber sie brauchen Deutsch fur mich nicht zu übersetzen - ich wohne nur etwa 15 km der Deutsche Grenze ...

Viel spass,

   Rob Roeterdink

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Will do so today.

And he Translation was actually just for General, if anybody not able to understand german might read it (i know, you´re from the netherlands, and that our two languages are in some parts wuite similar to each other - if I read some dutch text, I also understand what it´s about in General ;) )

Cheers, Markus

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Again, I get that.

Maybe something to do with the Directory ORv09 is in? ("C:\MSTS\OR\OR_v09")

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

This bug of yours is pretty reluctant to be caught.
I don't think it is the general path, more likely there could be yet more differences between the versions of the save and this version which tries to restore.
Did you use the 'official' V09 version to save? If not, what version did you use?

Anyway, have included a print-out statement showing the path it is trying to read, so let's see what it comes up with.

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

Now, that would be a lot more usefull if I had actually included that version ....

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

I used actual v09, and can without any Problems load the save in the official runactivity.exe

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

And again it´s the same! OR doesn´t like me, does it? XD

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

Are there any extra print-statements in the log-file this time?
It's not OR itself - it's that special bug you've got in there ....

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

This version is derived from the 'official' V09.
Let's see what this brings ....

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

If I go to where OR stores ist saves (Open Savepacks Folder and go one Level above), locate the concerned save and open it using MS Editor, the first Thing right at the start of the first line seems to be the Version code:

"0.9.0.1648"

So, that seems to be where it really was saved... :/

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

The latest version which I attached (saturday) was created out of 1648, so that should do it.

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Yeah, but what it did, was print to the Screen the file from #21...

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

OK - started all over again, cleared out all versions, downloaded version 1648, inserted patches - if this does not work, you'll have to send out a search-party for then I am completely lost.

Now, to complete all trouble, launchpad 'timed out' on submitting this comment ...
Retry ....

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

You know what? I´ll run the activity again, not too much changed so far, so we´ll see...
Maybe the save also simply is corrupt...

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Here´s the files OR created while I ran the activity full length.

PS: Same result as above: off path, out of control...

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

And, additional findings: Now, that I ran the activity totally with your test Version, I actually in any case should be able to load the save. Yet, it does neither work with the command line Option, nor the Standard one from the menu. I always get the same error message...

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

GOT IT!!
Pff, this was a hard one to find.
Problem is that SIGNALS.cs, which determines if an alternative path is available, uses the active train path, whereas TRAIN.cs, which extracts the required alternative path, uses the default train path. The index where the alternative path starts is calculated by SIGNALS.cs, but as TRAIN.cs using a different path it is the wrong index, and part of the active path was therefor not included in the new path - and that just happened to be the part of the path the train was sitting at.
So - all this searching resulted in just one line of changed code .....

I will have to do some testing on this change first, that will take a few days (same problem as you have : have to find a proper passing sequence).
When it works correct I'll post a testversion here.

No idea why this version won't load it's own save, but as it is a testversion I'm not going to look into that problem.

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

By the way - I also now know why you ran into this problem whereas most people don't.
Normally, the active path and the default path are the same - so the problem would not occur.
But you have done some shunting earlier and therefor switched to manual mode - and back again. When you switch back again to Auto mode, the active path is rebuild starting at the present position - and then default and active are no longer the same.

Revision history for this message
Markus Gelbmann (gelbmann-markus) wrote :

Simply a G R E A T THANK YOU, and CONGRATS!

That one was a nasty one, indeed! But finally... ;) :)

Cheers, Markus :)

Revision history for this message
Dennis A T (dennisat) wrote :

Sorry to butt in on this bug but I'm researching a very similar problem.

An activity has a double reverse point placed in the Player train path to ensure an AI can leave a siding and cross the path of the Player train. This is a very common ploy with MSTS to make the Player train temporarily lose priority.
In OR the Player train is duly stopped at the signal before the conflicting move. The double reverse point is not visible on the track monitor though. The AI leaves the siding and heads off, so far so good. Signal clears in front of the Player train but the switches beyond are still set to the AI path and the Player train is emergency stopped. I've found no way to dodge this with any manoeuvring (backwards, forwards, etc) of the Player train. If you go into Manual, you can get by the location but OR never lets you back into auto. It always comes back with "train is not on original path".

Do you think this could be related to the problem above or shall I report a new bug?

Dennis

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

Dennis,

looks to me to be a different problem altogether.
Please write a new bug or start a post in the Elvas Tower forum.

Thanks.

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

Fixed in V1676.

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