[disc]

So how is that deadlock processing working? I saw a activity, where the creator made a mistake with the paths: at a passing loop he placed both train paths on same track, so it caused deadlock. But the game didn't solved it, by diverting the inbound train to the free track. Why? Or this feature needs new act editor?

[dennisat]

I've seen a similar deadlock in Open Rails with an activity that works in MSTS. The player train arrives at a station and is then required to reverse out to continue on its path. A reverse point is at the station. However, OR allowed an AI to follow the player train on the same track as far as the signal immediately behind the player train. Unfortunately, this blocks the crossover that the player train needs to reverse out of the station on its prescribed path. Result is deadlock, the signal to allow the player train to proceed never clears; it can't because the AI has blocked the path to the crossover.

Dennis

[roeter]

 disc, on 02 May 2013 - 02:51 AM, said:

So how is that deadlock processing working? I saw a activity, where the creator made a mistake with the paths: at a passing loop he placed both train paths on same track, so it caused deadlock. But the game didn't solved it, by diverting the inbound train to the free track. Why? Or this feature needs new act editor?

The deadlock processing only uses the paths as defined - it does not search for any alternatives. It locates - from start to finish - those places where trains do not share the same track, and defines these as (possible) passing places. If player train and AI train from opposite direction have the same path (in reverse, obviously) for the full route length, a deadlock is unavoidable. A deadlock is also unavoidable if either train starts later, with a starting position located on the path of the earlier train, and there are no passing possibilities between the present position of the earlier train, and the starting position of the later train.
So, for the deadlock processing to work properly and regulate trains through passing points, the paths of the train must either always use different paths through possible loops, or the 'start passing path' option of the MSTS Activity Editor must be used to set locations where 'alternative' paths are available.

Regards,

Rob Roeterdink

[roeter]

 dennisat, on 02 May 2013 - 08:05 AM, said:

I've seen a similar deadlock in Open Rails with an activity that works in MSTS. The player train arrives at a station and is then required to reverse out to continue on its path. A reverse point is at the station. However, OR allowed an AI to follow the player train on the same track as far as the signal immediately behind the player train. Unfortunately, this blocks the crossover that the player train needs to reverse out of the station on its prescribed path. Result is deadlock, the signal to allow the player train to proceed never clears; it can't because the AI has blocked the path to the crossover.

Dennis

This seems to be a case of 'bad luck'. One thing you could try is to check which station stop is used. When a reversing point is in (or just beyond) a platform, that station will appear twice is the train's 'stop' list. If you 'tick' the first entry, the stop preceeds the reversal point, but if you 'tick' the second entry, the reversal point preceeds the station stop, so the train will first reverse and than have it's booked stop. That does not, however, garantuee this situation will work - it could well be that the AI train is so close behind the player train that it has reserved it's path right up to the signal you mention even before the player train has come to a stop. There is no way this can be prevented. Only thing to do in that case is to change the timing of the AI train, or change it's path so it can 'bypass' the player train (if possible).
That the activity works in MSTS could well be because of difference in AI train timing - just a small difference in AI timing can make the activity just work or just fail.
The deadlock processing does not work in this situation - it does not check beyond reversal points, but when the train reverses it determines all possible deadlocks for the next subpath. In this case, this cannot prevent the deadlock as at the moment of reversal it allready exists. If the AI train runs a little later - and has not yet reserved it's path beyond the cross-over, the deadlock prevention would keep the player's train path clear. Extending the deadlock processing beyond reversal points is just too complex - just imagine the complexity if both AI and player train have multiple reversal points.

Regards,

Rob Roeterdink

[dennisat]

 roeter, on 03 May 2013 - 03:51 AM, said:

...That the activity works in MSTS could well be because of difference in AI train timing - just a small difference in AI timing can make the activity just work or just fail...

As an experiment I'll alter the AI train timing until the act fails in MSTS as well. I'll also try changing the timing to make the act work in OR.

Dennis

[edwardk]

After reading through this post, how about being able to assign priorities to both player and AI trains. This of course is a wish list feature for OR's activity editor.

Edward K.