[disc]

I've found a solution for these deadlocks. I've played the same scenario, and the same happened. So i've pressed Ctrl-M and then the AI instantly got the correct path on switches, and green signal. Then i pressed it again, and wait for the AI train to get clear of the tracks. Then i get the green too. Same happened later on another station and the same solution worked again.
So if this deadlock happens, press Ctrl-M twice, and it will be solved. Probably because as i see, when press once it resets the track reservations.

update:

later on another station, another problem happened. Same situation, but everything went well, no Ctrl-M was needed, after the AI train's waiting point passed, it got green light, and started to accelerated. It passed the entry signal, but not far from it, it just stopped, until it stopped, for that train the game wrote "NODE" in Auth column. After it completely stopped in the middle of a switch, 900 metres from the next signal, the AI MODE started to randomly change between WTP (with ..:..:.. time), and STP. And the Ctrl-M doesn't help.

[Stefan PAITONI]

Hello,
Very interesting discussion,
If I am of agreement with Rob relating to certain points, I am surprised however that one considers all stopped trains as simple static train which one can approach.
In fact, OpenRail should manage AI trains in a more logical way. As soon as a train (AI or player) has a valid “TCRoute”, it cannot be considered as a static train. It occupies its track and this one cannot be used.
How to make so that one can approach a train for coupling ?
In the case of static train like such defined in MSTS, not problems. It does not have valid TCRoute.
In the case of an AI train. If we hope to approach it and be able to couple, we have to define its path finishing along a plateform or a siding. Such train can be transformed into static train. It has any more valid TCRoute and could be approached.
All AI train with a route path finishing outside of plateform or siding can be 'removed' when it arrives to its last node.

This behaviour is not an MSTS one but could be an OpenRail specific one.

Stef

[roeter]

 Stefan PAITONI, on 22 April 2013 - 02:09 AM, said:

In the case of static train like such defined in MSTS, not problems. It does not have valid TCRoute.
In the case of an AI train. If we hope to approach it and be able to couple, we have to define its path finishing along a plateform or a siding. Such train can be transformed into static train. It has any more valid TCRoute and could be approached.
All AI train with a route path finishing outside of plateform or siding can be 'removed' when it arrives to its last node.

This behaviour is not an MSTS one but could be an OpenRail specific one.

Stef

Yes - but that's one for the future. It is indeed the intention to define what should happen to an AI train when it reaches the end of it's route.
But that's not possible yet. I know there are users who run the player train as 'helper' services - they set up waiting points for AI trains so these are stopped, then attach the player engine to the end of the train, take over control and shove it up a hill etc. So, for the time being it must be possible to couple to an AI train while still AI.
There are also other points where one should be able to get onto a track with a stationary AI train.
First, there are the 'STOP_AND_PROCEED' aspects as used in North America, the other is 'permissive working' in platforms and sidings, i.e. two trains (front AI, rear player or reverse) share a platform in a station. In both cases, access must be possible to tracks occupied by AI trains. For 'permissive working' in terminal stations, even on AI trains which are to reverse direction!

Regards,

Rob Roeterdink

[roeter]

 disc, on 21 April 2013 - 01:19 PM, said:

later on another station, another problem happened. Same situation, but everything went well, no Ctrl-M was needed, after the AI train's waiting point passed, it got green light, and started to accelerated. It passed the entry signal, but not far from it, it just stopped, until it stopped, for that train the game wrote "NODE" in Auth column. After it completely stopped in the middle of a switch, 900 metres from the next signal, the AI MODE started to randomly change between WTP (with ..:..:.. time), and STP. And the Ctrl-M doesn't help.

Now - that is really a very unruly AI train.
There have been some changes today in the path processing for AI trains, including waiting point processing, so could you check if this still happens on the latest version?
If so - could you please report a bug for this will all details?

Regards,

Rob Roeterdink

[disc]

 roeter, on 22 April 2013 - 02:30 AM, said:

Now - that is really a very unruly AI train.
There have been some changes today in the path processing for AI trains, including waiting point processing, so could you check if this still happens on the latest version?
If so - could you please report a bug for this will all details?

Regards,

Rob Roeterdink

The problem is that the problematic crossing is two hours after the start of the activity ;) however i've made savegames, but those are invalid now.

[disc]

I've an idea: as i see, the tracks reservations are computed for the trains if the waiting time at passenger load/unload is below 2 minutes.
So it would be nice if this time could be changed per route (in config file or something), and later per activity (of course as there is no OR activity editor, it's not possible yet).
I think this isn't a big task, just instead of that 2 min constant, the time would be read from a file.

[roeter]

There are actually a lot more things we would like to add to the activity information. As soon as we can find the time, we will be looking into the possibilities of how these items can be defined, what syntax etc. Variable signal 'hold' times is one of the items on that list.

Regards,

Rob Roeterdink

[disc]

A support for signal light glows would be nice too. The msts signal light look a bit dull. Just a bigger quad around the signal light, with additive material just like in railworks/ts.

[Csantucci]

This is off topic, however here is a short reply: the signal glow problem was already addressed on MSTS by using a particular .ace file (I don't remember details), and the related solution works well also with ORTS; see green signal on image (pls. enlarge it by clicking).

[disc]

 Csantucci, on 22 April 2013 - 10:12 PM, said:

This is off topic, however here is a short reply: the signal glow problem was already addressed on MSTS by using a particular .ace file (I don't remember details), and the related solution works well also with ORTS; see green signal on image (pls. enlarge it by clicking).
Signalglow.jpg

That's very far from a real glow. That's just a bigger mip with the same solid color.